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: Stuart Hughes
Subject: Re: [Ltib] PKG_KERNEL_PRECONFIG[.dev] handling
Date: Tue, 30 Jul 2013 19:11:49 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6

Hi Mike,

The idea of the .dev files is that they get used during development.
Once you're done you should move them to their corresponding config
files and put those back into your SCM.

I think it's best to leave things this way, I would not bother adding an
option, if you want to move the .dev files, put it in your continuous
integration scripts or use the -m distclean.

One slightly subtle point to bear in mind is that the .dev is copied
back from your kernel config session into your project and then back the
the kernel sources (once unpacked if neccessary).  The point is that the
original kernel config file in your project is left alone.  The purpose
is to let you apply patches, or even upgrade the kernel and have the new
sources re-munge the .dev config file.  That way you can decide what to
keep once you've finished your kernel development.

Regards, Stuart

On 29/07/13 19:03, 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"?
> 
> Thanks
> 
> _______________________________________________
> LTIB home page: http://ltib.org
> 
> Ltib mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/ltib
> 



reply via email to

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