Re: RFC: Adding a new global MACHINE_ENDIAN variable

[Rod Whitby <rod@whitby.id.au>]

Koen Kooi wrote:
> Rod Whitby schreef:
>>> There exist machines (like the ixp4xx range of processors) which can be
>>> run in either little-endian or big-endian mode, and both modes are
>>> supported by OE.
>>>
>>> I propose a new "MACHINE_ENDIAN" (naming courtesy of RP) variable to do
>>> this selection (i.e. for machines that support both, the build can be
>>> selected in local.conf).
> 
> No, that's just needles confusion, just make a .inc file (like ixp4xx.inc) that has the
> common bits and 2 machine files that set up the appropriate endiannes stuff. That way you
> can use machine overrides to configure stuff instead of putting more anonymous python
> functions in the metadata.

There currently is an ARCH_BYTE_SEX "magic" variable (which nslu2-linux
added), which is used 77 times in OE as it stands today (mostly in
SlugOS files).  First thing I will do is replace that with
MACHINE_ENDIAN (as it's a better name).

As for MACHINE_ENDIAN as a magic variable, to do as you suggest requires
that there be an easy way to have a "machine architecture" override
(i.e. ixp4xx) as well as the usual "actual machine/board" override (i.e.
nslu2le).  Currently there is only one such override in place, which
means that in *every* place that there currently is an _ixp4xx override
in the metadata, that needs to have 2 other duplicates of that line (one
for _nslu2le and one for _nslu2be) added in each of those .bb files.

I'm happy to go down that path instead of the MACHINE_ENDIAN path (if
that's the consensus of all the OE core team members - RP and koen
currently have diametrically opposed opinions on this - what do others
think?).  But I will need a way of inserting "ixp4xxle/be" and "ixp4xx"
in the set of overrides for both nslu2le and nslu2be machines.  I expect
this will need to be done in the ixp4xx.conf file by some hacky python
which looks for ${MACHINE} in the override list and adds "ixp4xxle/be"
and "ixp4xx" after it.

Koen, with that extra information and context, is your input to the
consensus still the same?

RP, does Koen's reply change your recommendation (to use MACHINE_ENDIAN)?

[Note that I'll be changing ARCH_BYTE_SEX to MACHINE_ENDIAN first
everywhere it exists, for clarity sake, as a first step.]

-- Rod (just looking for consensus before acting ...)