ltib
[Top][All Lists]
Advanced

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

Re: [Ltib] PKG_KERNEL_PRECONFIG[.dev] handling


From: Peter Barada
Subject: Re: [Ltib] PKG_KERNEL_PRECONFIG[.dev] handling
Date: Mon, 29 Jul 2013 15:39:19 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7

On 07/29/2013 03:03 PM, Mike Goins wrote:
> On Mon, Jul 29, 2013 at 2:18 PM, Peter Barada <address@hidden> wrote:
>> On 07/29/2013 02:03 PM, Mike Goins wrote:
>>> I'm having an issue in kernel-common.tmpl with the preconfig and the
>>> existence of the .dev file.
>>>
>>> If the .dev file exists then it gets set as the CFG:
>>>
>>> for CFG in "$PLATFORM_PATH/${PKG_KERNEL_PRECONFIG}.dev"
>>> "$PLATFORM_PATH/$PKG_KERNEL_PRECONFIG"
>>> do
>>>    if [ -f $CFG ]
>>>    then
>>>        CFG_PATH=$CFG
>>>        break
>>>    fi
>>> done
>>> <snip>
>>> cp -f $CFG_PATH $KBOUT/.config
>>> <snip>
>>> yes "" | make ARCH=$LINTARCH HOSTCC="$BUILDCC" oldconfig
>>>
>>> This ends up rebuilding the kernel based on the .dev file and not the
>>> PRECONFIG since the .dev file exists. We are not tracking .dev files
>>> in version control, so this process is not using an updated PRECONFIG
>>> that may arrive in version control.  Continuous integration systems
>>> noticeably are being affected.
>>>
>>> Has anyone else run into this?  Tracking the .dev file looks like it
>>> may fix this, but I'd prefer that as a last resort. Anything wrong
>>> with testing the time-stamps of the PRECONFIG and .dev file and using
>>> the PRECONFIG if it is newer?  What if I changed the order in the "for
>>> CFG in"?
>> Don't change the order, or any user configuration changes (made by
>> "./ltib -c") won't take effect...
>>
>> You best bet for continuous integration is to first remove any *.dev
>> files from the platform directory and then force the selection of a
>> preconfig file.  I.E. run the following script to do a CIS build:
>>
>> #/bin/sh
>> PLATFORM="<platform>"
>> rm -rf config/platform/$platform/*.dev
>> ./ltib -b --preconfig config/platform/$platform/defconfig
>>
> Nice simple solution.  And it works.  Thanks
>
>
>> Better would be modify the ltib script to add a "--remove_dev_files"
>> option that removes the platform *.dev files near the start of its
>> processing after identifying the platform.
>
> What about making "--remove_dev_files" implicit in "--preconfig"?
The underlying issue is that the .dev files are used both for the
platform configuration and kernel packages.  Sometimes I want to use a
kernel with local configuration changes but with different package mix
for testing (i.e. I have multiple defconfigs to cover different package
mixes, all referring to one common kernel/kernel config).  I can use
--preconfig to build the different package/configuration mixes from the
command line.

On my CIS system I've modified the ltib script to add
"--remove_dev_files" and use it to do what I need there (i.e. forcibly
build a SCM revision point from a known configuration).  attached is a
patch to current CVS ltib (I pulled the changes from my CIS ltib script
that a bunch of other local changes in it), so give it a whirl
(preferably in a test tree you don't mind trashing if I made a mistake)...


-- 
Peter Barada
address@hidden

Attachment: ltib-remove_dev_files.patch
Description: Text Data


reply via email to

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