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

[Mark Hatle]

After reading the discussion, and some investigation I did on my own last week..
 I think there is a more fundamental problem then just a couple of variables
changing names and such.  (Perhaps this was eluded to in a previous conversation
that I missed.. but)

I don't see a -clear- definition of a machine, soc, cpu, etc layed out in
oe-core.  What I mean by this is, we have various tune files, we have a few
machine files.. but how do these all fit together?  I wasn't able to just go in
and say "Ohh these are the paremeters for armv7a", I had to dig around and guess
how things got constructed.

What I've done in the past (commerical product, no OE based) is have a series of
configuration files.  Note, the names below are mine, not OE terms!  Keep this
in mind.  The definitions are arranged in a pseudo-hierarchy that allows each
level to add additional information, until the level of information is properly
determined.

arch <- define basic characteristics about an architecture, such as ARM, Power,
SH, MIPS, etc..

ABI <- define basic characteristics about a specific ABI (multilib), living
inside of an arch.  This defines characteristics for gcc, glibc, and "base"
definitions for CFLAGS, CPU instruction sets, etc.. to produce a minimal
compatible set of binaries.   This SHOULD be enough to build a system..

CPU <- tuning files to enable additional CPU features, optimizations, etc.. the
CPU file is not allowed to change the ABI however.  (For instance, it can't
suddenly enable hard-float on a soft-float multilib.)

BSP (machine) <- final tunings specific to a given machine.


The inclusion order is:

arch can only include the 'all' (no arch)
ABI must include one and only one arch
CPU must include one and only one ABI, or may include another CPU
BSP (machine) must include one or more CPUs (this enables multilibs)

So each BSP (machine) configuration defines what CPU tunings, and thus ABIs are
available on it.  It also defines the default ABI, and may override the CPU
tunings if there is something more precise needed for a given board -- such as a
errata workaround.

While the above has worked for me, I'm sure it would need tailoring in oe-core..
 I'm not advocating changing huge sections of variable namings, just putting in
some sanity to each of these levels....  bringing that into play, we can then
expand to what was mentioned below with package feeds and similar.

The "allarch" is inherited from the special no-arch.  This starts the process of
specifying what packaging is available.

Each ABI specifies a "base" package arch for it's settings and ABI.  This gets
added to "any existing items", i.e. the 'all' arch

Each CPU tune gets more and more specific.  Package feed compatibility is
defined here..  For instance an i686 CPU would include the i586, which could
include i486, which could include i386..  This would result in a feed capability
of i686 being the "preferred", and compatible with i586, i486, i386, all.

The BSP (machine) then would do it's final tunings.  That would define the
machine arch as the highest level, things only setup for that machine.

Anyway, something to consider.  I haven't had the time to really dig into OE and
see if any of this makes sense with what we have -- but it might help resolve
some of these issues, and make it easier to manage the arch, tuning, and related
variables in a single hierarchy so we can see what does and doesn't work -- and
what needs improvement.

--Mark

On 6/15/11 6:52 AM, Koen Kooi wrote:
> 
> 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 :)
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core