On Sat, 25 Jul 1998, Jonathan Stone wrote:

: Splitting $MACHINE_ARCH doesn't buy much except someone who can't
: write the sh code to figure out the internal GCC machine/arch
: identifier, or installing binary packages, or finding install sets.
: Those we'd have to change anyway.

It actually keeps configuration more uniform.  Paricularly if you can match
on "mips*" when endianness is not an issue (which is done in autoconf now, I
believe).

And, of course, no matter the outcome, the output of `uname -m` needs to be
separate between the two.  This is the long-standing traditional way of
selecting a set of binaries for a given platform that supports more than one
CPU architecture, and is well known outside of NetBSD.

: Having ${MACHINE_ARCH} == "mips" determines at least as many other
: things. Whatever way we jump breaks something, but I think this breaks
: less.

I think it may actually break the same amount, except that only changing the
MACHINE_ARCH for big-endian mips would break zero for the pmax, the existing
mips platform, and zero for future users of newsmips releases, since there
have been no newsmips formal releases yet.  `There's still time.'

I'm coming from the standpoint of the non-hack-level user here, who would
really rather not know two or three things about a system to identify a set
of binaries to download or how to identify binaries he has created.  And, to
avert the annoying "Why do I get `Exec format error' when I run this mips
binary?" whines.

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)