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

[Darren Hart]

On 03/04/2011 02:30 PM, Koen Kooi wrote:
>
> 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.

You could be right, I'm not terribly familiar with how the "inheritance"
model works. It seems to me the "addtask" method would work regardless
as you suggest, and I have no objection to taking that route.

Richard, do you have a preference? Can you clear up the inheritance
question?


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