Re: [Ltib] Adding building of kernel from SVN

[Stuart Hughes]

On 31/01/11 15:38, Peter Barada wrote:
> On 01/31/2011 04:42 AM, Stuart Hughes wrote:
>> Hi Peter,
>>
>> I can certainly see why this could be convenient for you, however
>> unfortunately I can't merge this.  I went down this patch a couple of
>> years ago with git and in the end you end up with these issues:
>>
>>   * LTIB has to understand the SCP and becomes a front end for the tool
>>   * The floodgate open for SCM system x, y,x (mecurial, cvs, git ......)
>>
>> After a lot of thought I concluded that the best approach was for LTIB
>> to be ignorant and agnostic of the underlying SCM being used for
>> development.  The idea is that for this activity you should use
>> directory build mechanism and handle any SCM work in the .spec file you
>> are using.  This turns out to work quite well, you can put all the SCM
>> handling in the %prep (checkout) and %build (update) sections (I have
>> some examples for git somewhere.
> 
> The reason I used %prep to do both the checkout/update instead of splitting 
> checkout/build across %prep/%build is that in normal development you need to 
> %build your changes to test them and only after it works correctly would you 
> check them back into the SCM for others to get.  If you have %build do an SCM 
> update, then while you're trying to test your changes you'll pull in any 
> changes other developers have made that can conflict with your changes...
> 
> I admit my approach is blunt and solves my problem.  If I finessed things to 
> hide all the SCM handling inside of a shell script invoked from the 
> %prep/%build section ("scm-prep" and "scm-build" perhaps?)  would that be 
> more acceptable?  Then the decision where the update is doe (either in %prep 
> or %build) can be handled in one spot for all packages using an SCM build...
> 

Fundamentally, LTIB cannot be aware of SCM systems, it's a can of worms
(there's too many potentially in used to handle).  So the only thing on
offer is directory builds.  Whatever you implement within a non-shared
.spec file is fine though.

Regards, Stuart



>> Regards, Stuart
>>
>> On 28/01/11 16:32, Peter Barada wrote:
>>> Stuart,
>>> My company uses SVN as its SCM, and I've added support to build a kernel 
>>> using SVN instead of the tarball/patches to make it much easier for more 
>>> than one developer to hack up kernel code.
>>>
>>> To support this (and make it properly work with Buildbot) I've modified the 
>>> ltib script to:
>>>
>>> 1) Ignore .svn files
>>> 2) If the package version is "svn" then we force a build (but not a 
>>> $dir_bld) to have ltib go throught he package %prep step
>>> 3) Export KERNEL_RESPOITORY (the SVN URL to access the kernel source)
>>> 4) Export KERNEL_SCM_SKIP_UPDATE (to allow skipping "svn update" for a 
>>> previously unpacked package)
>>>
>>> Note that ltib-svn-kernel-build.patch works in conjunction with my previous 
>>> ltib-clobber.patch as it uses $svn_bld to set $r (which causes a build) 
>>> instead of $dir_bld which prevents --clobber from affecting the unpacked 
>>> source.
>>>
>>> I've also attached:
>>> 1) kernel26-svn-build.spec.in which will checkout/update kernel source (in 
>>> rpm/BUILD/kernel-svn) from an SVN repository.
>>> 2) kernel_dir_build.lkc.patch which adds 
>>> KERNEL_REPOSITORY/KERNEL_SCM_SKIP_UPDATE if KERNEL_SVN_BUILD is enabled 
>>> (assumed this is done in a platform main.lkc where once can select 
>>> KERNEL_DIR_BUILD)
>>> 3) kernel-common.tmpl.patch to use tar to copy over the kernel header files 
>>> (as cp fails with "permission denied" on .svn files in the headers)
>>>
>>> I'm sure with a minor additions this approach can be extended to support 
>>> CVS and git to allow kernel building from any of the common SCMs.  
>>> Ultimately it would be nice to extend this to support building any package 
>>> from an SCM...
>>>
>>> Hope others finds this useful!
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> LTIB home page: http://ltib.org
>>>
>>> Ltib mailing list
>>> address@hidden
>>> http://lists.nongnu.org/mailman/listinfo/ltib
> 
>