[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 13:36 heeft Richard Purdie het volgende geschreven:

> On Wed, 2011-06-15 at 12:37 +0200, Koen Kooi wrote:
>> Op 15 jun 2011, om 12:22 heeft Richard Purdie het volgende geschreven:
>> 
>>> On Wed, 2011-06-15 at 12:15 +0200, Koen Kooi wrote:
>>>> Op 15 jun 2011, om 12:07 heeft Richard Purdie het volgende geschreven:
>>> I know, but we have two choices:
>>> 
>>> a) Continue this spiral of confusing variable names, conflict and wacky 
>>>  bugs
>>> 
>>> b) Come up with a plan to address it and roll it out
>>> 
>>> I'm favouring b), particularly since this would help several different
>>> architectures with a variety of issues. If we need to better document
>>> that and have a process fine, but that is not a good argument for not
>>> doing it at all.
>> 
>> I agree on that, put previous efforts in the yocto universe were
>> rushed through (like the machine-name -> machine_name change I keep
>> going on about), so I have a knee jerk reaction to such things
>> nowadays. For various reasons yocto and later oe-core have not been
>> friendly to distros having package feeds out there. Sometimes the
>> changes made things better, but they were still painfull. It seems to
>> be getting better nowadays, which is good, but everyone still needs to
>> be carefull. Pet peeve: missing PR bumps.
> 
> Well, I think everyone is trying to improve, trying to do better and
> hopefully we are learning from any mistakes made.
> 
>> What I need for angstrom is a variable that:For 
>> 
>> 1) *never* changes its value
> 
> As I've mentioned several times, I think it is reasonable to allarch to
> clear or otherwise invalidate such a variable. That is a very special
> case though and setting it to "all" was perhaps a poor choice of value.

>> 2) holds the base arch (armv7a, ppc603e, etc)
> 
> Sounds like BASE_PACKAGE_ARCH
> 
>> 3) Is set in *all* the tune include files
> 
> Again sounds like BASE_PACKAGE_ARCH. Can it not default to TARGET_ARCH?

Defaulting to TARGET_ARCH would break 4)

> Grepping the tune files in OE-Core we seem to be pretty good about this
> right now.

In OE-core yes, not sure about the other layers.

>> 4) must be set to complete parsing when MACHINE is set
> 
> I suspect this doesn't give as much value as you'd think but I'm
> indifferent.

It's an early warning system :)