[oe] Deprecating ixp4xx, nslu2 in favour of endian-specific machine settings (Was: RFC on MACHINE_ENDIAN)

[Rod Whitby]

Koen Kooi wrote:
> Rod Whitby schreef:
>>> Koen, with that extra information and context, is your input to the
>>> consensus still the same?
> 
> I think adding two machines adheres to the principle of least surprise and makes is
> possible to build for the 2 machines in parallel (/me hugs bitbake trunk + machine-via-env).
> Also take a look at the amount of python in ixp4xx.conf to translate endianness into
> various settings. With 2 machines, you can do without the python, which makes it for new
> OE users look less arcane, and easier for python n00bs like me to modify.

OK, based on a good IRC conversation with Koen this morning, we're going
to do the following:

1) Replace ARCH_BYTE_SEX with IXP4XX_MACHINE_ENDIAN throughout OE

2) Set IXP4XX_MACHINE_ENDIAN in conf/machine/{ixp4xx,nslu2}{be,le}.conf
and deprecate conf/machine/{ixp4xx,nslu2}.conf in favour of the
endian-specific machines.

2) Make sure that any ixp4xx-specific file that uses
IXP4XX_MACHINE_ENDIAN also has a COMPATIBLE_MACHINE setting to match.

3) Replace any usage of IXP4XX_MACHINE_ENDIAN in a non-ixp4xx-specific
file with autofoo stuff to determine the endianness.

4) Clean up conf/machine/include/ixp4xx to use tune-xscale and
tune-thumb, and remove other variables which already have global OE
equivalents.

5) Replace _ixp4xx overrides with _ixp4xxle and _ixp4xxbe overrides
instead.  Similarly for nslu2.  This will be done as a second step (in
the meantime, I'll just add ixp4xx directly to the overrides as well as
${MACHINE}).

*** Note that this means that "ixp4xx" or "nslu2" will no longer be
valid MACHINE settings - you must use "ixp4xxle", "ixp4xxbe", "nslu2le",
or "nslu2be" instead.


Last chance for objections .... commits will start in 6 hours.

-- Rod