[OE-core] [PATCH V2] allarch.bbclass: Set FEED_ARCH to original value of BASE_PACKAGE_ARCH and then set BASE_PACKAGE_ARCH to 'all'

[Koen Kooi]

Op 15 jun 2011, om 12:07 heeft Richard Purdie het volgende geschreven:

> On Tue, 2011-06-14 at 23:32 +0200, Koen Kooi wrote:
>> Op 14 jun 2011, om 23:24 heeft Richard Purdie het volgende geschreven:
>> 
>>> On Tue, 2011-06-14 at 14:13 -0700, Khem Raj wrote:
>>>> Signed-off-by: Khem Raj <raj.khem at gmail.com>
>>>> ---
>>>> meta/classes/allarch.bbclass |    5 +++--
>>>> 1 files changed, 3 insertions(+), 2 deletions(-)
>>>> 
>>>> diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
>>>> index e3ac392..b9ba28b 100644
>>>> --- a/meta/classes/allarch.bbclass
>>>> +++ b/meta/classes/allarch.bbclass
>>>> @@ -2,9 +2,10 @@
>>>> # This class is used for architecture independent recipes/data files (usally scripts)
>>>> #
>>>> 
>>>> +# We need to pour the value of BASE_PACKAGE_ARCH into FEED_ARCH
>>>> +# before we reset it
>>>> +FEED_ARCH := ${BASE_PACKAGE_ARCH}
>>>> BASE_PACKAGE_ARCH = "all"
>>>> -PACKAGE_ARCH = "all"
>>>> -
>>>> # No need for virtual/libc or a cross compiler
>>>> INHIBIT_DEFAULT_DEPS = "1"
>>> 
>>> This is a *really* bad idea. An "all" package should have no need to set
>>> architecture specific values into FEED_ARCH.
>>> 
>>> Just for those not following IRC, the problem is Angstrom adds FEED_ARCH
>>> to OVERRIDES. Adding "all" to overrides turns out to do nasty things to
>>> classes like rm_work with "_all" in the function names.
>> 
>> So why don't we just set PACKAGE_ARCH = all in allarch.bbclass and not
>> touch BASE_PACKAGE_ARCH and FEED_ARCH?
> 
> Because then FEED_ARCH and BASE_PACKAGE_ARCH contain machine specific
> data, and the sstate packages become machine specific. When we're trying
> to create architecture independent packages, this isn't desirable and
> people complained about too much of the system rebuilding...
> 
> There is an underlying problem of why BASE_PACKAGE_ARCH and/or FEED_ARCH
> is being used but it did seem like one way to fix several of the
> problems people were seeing (not realising it would leak into OVERRIDES
> too).
> 
>>> I'd suggest that various machines should start adding things like armv7a
>>> to ${MACHINEOVERRIDES} which has a much more clearly defined scope and
>>> that FEED_ARCH should quietly die ;-).
>> 
>> And that's what I've start calling a 'yocto' type of solution.
> 
> Was it really necessary to add that? ;-)
> 
> I'm tempted to write some definitions of my own but I'll refrain.
> 
>> That just doesn't scale since it relies on fixing all the machines
>> out there instead of levering the knowledge provided by OE already.
>> I'd appreciate a solution is better thought out.
> 
> Well, I was trying to provide some hints as to how we might be able to
> improve this situation, not write the whole roadmap. From what I
> remember and the quick discussion we had offlist there are two things
> FEED_ARCH tries to do:
> 
> a) Provide an addition to overrides that represents the
> optimisation/tune profile being used (like armv7a).
> 
> b) Provide some info in BASE_PACKAGE_ARCH so that when PACKAGE_ARCH is
> overwritten, you can still find out what it would have been set to.
> 
> For a), we could update the common include files for the omap/armv7a
> platforms and append to MACHINEOVERRIDES there with the appropriate
> entries

It's not omap specific, you really need have access to the arch in overrides for *all* platforms. I'm using armv7a is an example since angstrom does TARGET_FPU_armv7a = "hard", but it also does that for various powerpc architectures.

And any change like this would need to get propagated to all the machine layers out there as well, unlike .dev where everything was in one place.