> > I don't think I understand this.  My take is that if you configre a
> > NetBSD cross-compiler for mips, it MUST be able to produce either
> > mipsel or mipseb code. (because that's what the native mips toolchains do.)
>
>Fine, but on a mipseb machine, the toolchain must produce mipseb by default,
>and vice versa for mipsel.

Jason,

Nobody ever, ever disagreed with that.


>Todd's "mipsel" and "mipseb" is the Right Answer.  Period.

Nope.  There are just as many problems with that, too.

Whatever we do we need a name that means ``is this a MIPS cpu of any
flavour'', for Makefile tests and CPP tests where we cant get by with
wildcarding.  On mips, that means six choices:
		el vs be
		o32, n32, lp64	models

Whatever we do, we need predefined names for _both_ concepts of
``architecture'', coarse-grain (all mips) fine-grain (all six combos)
so can test for them.

The only choice I see is which one we keep for ${MACHINE_ARCH} and
which one gets a new name. (I seem to recall both you and CGD agreeing
in April that MACHINE_ARCH was the ``right thing'' for the
coarser-grain, but whatever).

If you want ${MACHINE_ARCH} to be the fine-grain one, can you suggest
a new name (MACHINE_ARCH_FAMILY, maybe?)  and I'll write up a proposal
to change eacn and every use of $MACHINE_ARCH in Makefiles and for
subdir recursion, to use ${MACHINE_ARCH_FAMILY}.