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

[Koen Kooi]

Op 7 mrt 2011, om 17:30 heeft Darren Hart het volgende geschreven:

> 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 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?
>> 
> 
> 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.

Any news on this? I just hit the issue:

|   CC [M]  /OE/tentacle/build/tmp-angstrom_2010_x/work/beagleboard-angstrom-linux-gnueabi/ti-dsplink-1_1_65_00_03-r99i/dsplink_linux_1_65_00_03/dsplink/gpp/src/../../gpp/src/arch/CFG_map.o
| /bin/sh: scripts/basic/fixdep: No such file or directory


regards,

Koen