>Why are we still having this discussion?  MACHINE_ARCH == mips is clearly
>wrong, and should be fixed ASAP.

Jason,

It's not ``clearly wrong''.  We're still having the discussion because
the same issue was discussed elsewhere on April 2. (We even reached
closure on that in April, when discussing CPP predefines, and you
stipulated that ${MACHINE_ARCH} on mips systems should be "mips", as
far as I can see.)

There was explicit suggestion that CPP should be  defining

	__NetBSD__
	__${MACHINE_ARCH}__
	__${ENDIANNESS}__	/* or __${ENDIANESS} */

cgd said that he didn't consider endian-ness issues when defining
${MACHINE_ARCH}, didn't recall it coming up, and that leaving
${MACHINE_ARCH} as "mips" on mips systems is a reasonable choice.


But _whatever_ happens we need two well-defined Make symbols which,
 on mips, expand to

	a) coarse-graind architecture: "mips" on all mips platforms

	b) fine-grained architecture: 
	      "mipsel" or "mipseb" or "mipsn32el" or "mipsn32eb"
		or "mips64el" or "mips64eb"

and we need a CPP predefines for "__mips__", too, for code that wants
to be compiled on any mips machine but which doesn't care about the
programming model or the endian-ness.

Whatever happens, we have two conceptually separate levels of
description, and we need two make variables.  (we cant get by with
just the fine-grained: the combinatoric explosion isnt scalable, and
we cant use wildcards in either CPP or in Makefiles or for
architecture subdirs).

Obviously we can't call _both_ sense of ``architecture'' ${MACHINE_ARCH}.

Saying one choice is "clearly wrong," when even the person who came up
with ${MACHINE_ARCH} said it's reasonable, is a bit silly, dontcha
think?