Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Darren Hart <dvhart@linux.intel.com>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Cc: Anders Darander <anders@chargestorm.se>
Subject: Re: [PATCH 1/1] kernel.bbclass: make external module compile
Date: Wed, 06 Jul 2011 09:37:48 -0700	[thread overview]
Message-ID: <4E148F5C.4020902@linux.intel.com> (raw)
In-Reply-To: <ECF13383-E711-4CE2-8E50-222852DC392D@chargestorm.se>



On 07/05/2011 08:04 AM, Anders Darander wrote:
> 
> 
> On 5 jul 2011, at 15:09, "Richard Purdie"
> <richard.purdie@linuxfoundation.org> wrote:
> 
>> On Tue, 2011-07-05 at 14:54 +0200, Anders Darander wrote:
>>> * Phil Blundell Phil Blundell <pb@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.

Hi Anders,

Please see the following commit log:

commit 3b49416fc7a7ee9bfe722f2e6089aa18df41dc58
Author: Darren Hart <dvhart@linux.intel.com>
Date:   Tue Mar 8 17:09:10 2011 -0800

    kernel/bbclass: rework kernel and module classes to allow for building out-of-tree modul
  

In particular, the following:

    Care is also taken to clean the hostprogs in scripts, and the modules are
    responsible for building them as needed. Although it is unclear to me if this is
    really necessary, especially considering that modules put these bits back as
    soon as they compile. If we are not generating an sstate package, I suspect we
    can ignore these.
    
The scripts are recreated during the build of module.bbclass derived recipes.
Are you trying to build modules independently of this method? Richard expressed
concerns about not including host specific binaries in the sstate, which was
part of the reason this approach was taken.

--
Darren

> 
> Cheers, Anders _______________________________________________ 
> Openembedded-core mailing list 
> Openembedded-core@lists.openembedded.org 
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

--
> 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel



  reply	other threads:[~2011-07-06 16:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-05 12:01 [PATCH 0/1] Fix external module compilations Anders Darander
2011-07-05 12:01 ` [PATCH 1/1] kernel.bbclass: make external module compile Anders Darander
2011-07-05 12:44   ` Phil Blundell
2011-07-05 12:54     ` Anders Darander
2011-07-05 13:09       ` Richard Purdie
2011-07-05 15:04         ` Anders Darander
2011-07-06 16:37           ` Darren Hart [this message]
2011-07-06 17:31             ` Anders Darander
2011-07-06 18:22               ` Darren Hart
2011-07-08 13:31                 ` Anders Darander

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E148F5C.4020902@linux.intel.com \
    --to=dvhart@linux.intel.com \
    --cc=anders@chargestorm.se \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox