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

[Richard Purdie]

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.

Cheers,

Richard