ltib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltib] building multiple platforms, rpm cache


From: Mike Goins
Subject: Re: [Ltib] building multiple platforms, rpm cache
Date: Wed, 20 Mar 2013 14:48:48 -0400

On Mon, Mar 18, 2013 at 2:21 PM, Stuart Hughes <address@hidden> wrote:
> Hi Mike,
>
> That may be useful for other people.  Would you like to send a patch, or
> check in your changes to CVS?


The tweak is not quite complete as it does not deal with all ltib
handling such as distclean/release.I'll attach a patch of what I have
for anyone else to try until I get these working (or some beats me to
it).
It's a fairly small change so far.



> Regards, Stuart
>
> On 11/03/13 16:58, Mike Goins wrote:
>> On Tue, Feb 26, 2013 at 3:30 PM, Mike Goins
>> <address@hidden> wrote:
>>> I am trying to build specific configurations in ltib under continous
>>> integration system using the command:
>>> ./ltib --batch --clobber --preconfig config/platform/iolite/defconfig-Iolite
>>> (I know that platform does not exist in ltib yet, but bear with me)
>>>
>>> Then I may have to build for another platform, so I argue another
>>> platform after that:
>>> ./ltib --batch --clobber --preconfig config/platform/mpc8377/defconfig-8377
>>>
>>> The first step I see that it removes all the rpms, caches those in a
>>> directory, looks a time-stamp, and builds the new platform.
>>>
>>> So far so good, it seems.  But when I switch back to the original platform:
>>> ./ltib --batch --clobber --preconfig config/platform/iolite/defconfig-Iolite
>>>
>>> The rpm removal does not take place and the cached rpms are not used.
>>> I can't quire figure out what I am missing.  Is --preconfig the
>>> correct argument for this?
>>>
>>> I looked at bin/autobuild_ltib to see how it does it, but it appear
>>> that it expects a separate copy of ltib for each platform config.  I
>>> just can't find a good way to integrate that method into a ci system.
>>>
>>> Thanks
>>
>>
>> I wrote a fix for this by allowing rpmdir and rootfs to be argued in
>> on the command line.  This allows multiple platforms to be in the same
>> project.
>>
>> ls -1 ltib/
>> ....
>> README
>> RELEASE_INFO
>> rootfs
>> rootfs_sapphire
>> rpm
>> rpm_sapphire
>> tmp
>>
>>
>> It takes a long time for our large ltib to build the exact same rpms
>> (developer time).   This is fixed by using bfiles extension to
>> mercurial and putting the rpm/RPMS folders under binary control.  When
>> a developer checks out the upper level project, bfiles auto pulls [my
>> pre-built] binary rpms.  When ltib gets run, the rootfs gets populated
>> directly from the rpms which takes just a couple of minutes.
>>
>> # normal behavior
>> ./ltib --batch --clobber --preconfig config/platform/iolite/defconfig-Iolite
>>
>> # separate rpm and rootfs
>> ./ltib --batch --clobber --preconfig
>> config/platform/mpc8377_Sapphire/defconfig-8377_Sapphire --rpmdir
>> rpm_sapphire --rootfs rootfs_sapphire
>>
>>
>> Now it fits nicely into continuous integration.
>>
>> _______________________________________________
>> LTIB home page: http://ltib.org
>>
>> Ltib mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/ltib
>>

Attachment: rpmdir_rootfs.patch
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]