[OE-core] [PATCH 1/1] kernel.bbclass: make external module compile

[Anders Darander]

On 5 jul 2011, at 15:09, "Richard Purdie" <richard.purdie at linuxfoundation.org> wrote:

> On Tue, 2011-07-05 at 14:54 +0200, Anders Darander wrote:
>> * Phil Blundell Phil Blundell <pb at pbcl.net> [07/05/11 02:44 PM]:
>>> On Tue, 2011-07-05 at 14:01 +0200, Anders Darander wrote:
>>>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>>>> index 943252a..26ee416 100644
>>>> --- a/meta/classes/kernel.bbclass
>>>> +++ b/meta/classes/kernel.bbclass
>>>> @@ -149,7 +149,6 @@ kernel_do_install() {
>>> 
>>>        #
>>>        # We don't want to leave host-arch binaries in /sysroots, so
>>>        # we clean the scripts dir while leaving the generated config
>>> 
>>>>    # and include files.
>>>>    #
>>>>    oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean
>>>> 
>>>> -    make -C $kerneldir _mrproper_scripts
>>>> 
>>>>    find $kerneldir -path $kerneldir/scripts -prune -o -name "*.[csS]"
>>>>    -exec rm '{}' \; find $kerneldir/Documentation -name "*.txt" -exec rm
>>>>    '{}' \;
>>> 
>>> Did you verify that this doesn't introduce any new QA warnings during
>>> packaging?  Presumably that line was originally added for a reason and
>>> it seems a bit surprising that just deleting it without any replacement
>>> is the right thing to do.
>> 
>> No, I didn't really verify that. Do I need to run with any specific options 
>> enabled, or should it be enough to just bitbake my modules recipe? (I can't 
>> test for the moment, as the latest pull from oe-core forces a rebuild of gcc 
>> etc).
>> 
>>> Also, if the scripts dir isn't being cleaned anymore, I guess the
>>> preceding comment should be adjusted to match the new reality.
>> 
>> That's true.
>> 
>> I'll wait to see if someone else has any comments, or if I find some QA 
>> warnings before I produce a version 2.
> 
> I'm cc'ing Darren as this is one of his favourite subjects :/.
> 
> Summary is that this works well in some kernel versions and not in
> others. We might have to start doing this conditionally based upon
> kernel version I guess...

Ah, well then it is worse than I thought. ( On the other hand, that would explain why no one has noticed the problem, until I tried using the wrong kernel version).

Do we have any idea at what point the kernel breaks? I guess that might be a question for Darren.

Cheers,
Anders