[OE-core] [poky] [PATCH 04/13] module: build hostprogs for each module

Koen Kooi koen at dominion.thruhere.net
Fri Mar 4 22:30:30 UTC 2011


Op 4 mrt 2011, om 23:28 heeft Koen Kooi het volgende geschreven:

> 
> Op 4 mrt 2011, om 22:44 heeft Darren Hart het volgende geschreven:
> 
>> On 03/04/2011 12:04 PM, Koen Kooi wrote:
>>> 
>>> Op 4 mrt 2011, om 20:42 heeft Saul Wold het volgende geschreven:
>>> 
>>>> From: Darren Hart<dvhart at linux.intel.com>
>>>> 
>>>> This fixes [BUGID #241]
>>>> 
>>>> The kernel hostprogs are built for the host architecture. They should not be
>>>> deployed to the target, and they should not be included in an sstate package
>>>> which might get reused on a host of a different architecture.
>>>> 
>>>> As we don't build many out-of-tree modules, this patch takes the approach of
>>>> building the hostprogs as part of the module compile process with a
>>>> do_compile_prepend() routine in module.bbclass.
>>>> 
>>>> We don't have to clean the hostprogs as modules depend on the kernel being
>>>> populate_staging, so its done with the staging directory by the time we run.
>>>> 
>>>> Signed-off-by: Darren Hart<dvhart at linux.intel.com>
>>>> CC: Gary Thomas<gary at mlbassoc.com>
>>>> ---
>>>> meta/classes/module.bbclass |   12 +++++++++++-
>>>> 1 files changed, 11 insertions(+), 1 deletions(-)
>>>> 
>>>> diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
>>>> index d16d462..bbceaf7 100644
>>>> --- a/meta/classes/module.bbclass
>>>> +++ b/meta/classes/module.bbclass
>>>> @@ -3,6 +3,13 @@ DEPENDS += "virtual/kernel"
>>>> 
>>>> inherit module-base
>>>> 
>>>> +# Ensure the hostprogs are available for module compilation
>>>> +module_do_compile_prepend() {
>>>> +	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
>>>> +	oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
>>>> +	           -C ${STAGING_KERNEL_DIR} scripts
>>>> +}
>>>> +
>>>> module_do_compile() {
>>>> 	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
>>>> 	oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR}   \
>>>> @@ -15,7 +22,10 @@ module_do_compile() {
>>> 
>>> Why not put it in do_compile itself?
>> 
>> My rationale was that a module recipe may override do_compile for one reason or another, but they will still need the hostprogs which we stripped in kernel.bbclass. This way, even if they override do_compile, the _prepend will still get run and prepare the hostprogs.
> 
> Are you sure that actually works? AIUI bitbake will fold the compile and prepend into one when you try to override it.

What I actually meant to say is: If you need to prepend it to do_compile, even when someone will override it, use addtask to insert it between configure and compile. That makes the intention a lot clearer and isn't depending on faulty bitbake behaviour.

regards,

Koen



More information about the Openembedded-core mailing list