[OE-core] [PATCH 2/5] kernel.bbclass: copy .config instead of moving

[Markus Lehtonen]

On 18/12/15 16:18, "Richard Purdie" <richard.purdie at linuxfoundation.org> wrote:

>On Fri, 2015-12-18 at 14:39 +0200, Markus Lehtonen wrote:
>> On 18/12/15 14:22, "Richard Purdie" <
>> richard.purdie at linuxfoundation.org> wrote:
>> > On Fri, 2015-12-18 at 10:39 +0200, Markus Lehtonen wrote: 
>> > >  	if [ "${S}" != "${B}" ] && [ -f "${S}/.config" ] && [ ! 
>> > > -f
>> > > "${B}/.config" ]; then
>> > > -		mv "${S}/.config" "${B}/.config"
>> > > +		cp "${S}/.config" "${B}/.config"
>> > >  	fi
>> > >  
>> > >  	# Copy defconfig to .config if .config does not exist.
>> > > This
>> > > allows
>> > 
>> > I'm not sure about this, doesn't this trigger the kernel to see
>> > ${S} as
>> > being 'dirty' and cause other issues when you try and do out of
>> > tree
>> > builds with it?
>> 
>> That shouldn't be a problem as the kernel .gitignore ignores .config
>> (or '.*' to be more specific). There are other tasks that make
>> changes to the kernel source tree, as well, like do_kernel_metadata.
>> 
>> 
>> > It also means we have two copies of "config" around which can end
>> > up
>> > being different and confuse users no end :(.
>> 
>> Yes, I must agree. What do you think if ${B}/.config would be a
>> symlink to ${S}/.config? I.e.
>> +               ln -s "${S}/.config" "${B}/.config"
>> 
>
>I think I'd prefer we move the file over the ${B} and then symlink from
>${S} since that way if its modified, its mostly likely to be done from
>${B} at least by the automated code?

Hmm, what I suggested is not good (at least on its own) because menuconfig moves .config to .config.old.

Symlinking from ${S} to ${B} is also problematic for the intended devtool use case because removing/cleaning ${B} also removes our .config. Back to the drawing board, I guess...


Thanks,
  Markus