Re: [Ltib] Adding building of kernel from SVN

[Peter Barada]

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...

> 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


-- 
Peter Barada
address@hidden