Re: [poky] [PATCH 04/13] module: build hostprogs for each module

[Darren Hart <dvhart@linux.intel.com>]

On 03/04/2011 03:20 PM, Darren Hart wrote:
> 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@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@linux.intel.com>
>>>>>> CC: Gary Thomas<gary@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?
>

Had a chat with Richard. His suggestion was to use a new function, ie 
do_hostprogs, which do_compile() calls. If a recipe overrides 
do_compile() it can call do_hostprogs() or manage it on its own. I'll do 
some testing and send out a follow-on patch.

Thanks,

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