[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: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:
>>> 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.
> 
> I'm also using omap as an example. I'd imagine the powerpc bits would
> also work from a common small set of tune include files though? I
> suspect the Intel guys would love some way to say "x86" instead of
> "i386|i486|i586|i686" etc. so this is a general problem.
>> 
>> 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.
> 
> 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.

What I need for angstrom is a variable that:For 

1) *never* changes its value
2) holds the base arch (armv7a, ppc603e, etc)
3) Is set in *all* the tune include files
4) must be set to complete parsing when MACHINE is set

I don't care if it's in overrides by default or not since that's easy enough to do in distro configs.

regards,

Koen