On Sat, 25 Jul 1998, Todd Vierling writes:

: OK... Either everyone went on vacation, or the only _dissenter_ that I can
: see to my proposal to modify the valuse of "mips" for LE and BE machines
: that I see thinks the problem has been `solved' and I went away.

>Here's the more formalized proposal, suggested one of several ways:

>- Change the big-endian MIPS (the newcomer) to "mipseb".  Leave "mips" as-is
>  on the existing platforms which have had a 1.3.x release (newsmips has not
>  had a public release yet).

Ummm, the invariants I want to preserve are that:

	* CPP predefines __${MACHINE_ARCH}__ and __NetBSD__,
	  and nothing else except on bi-endian machines.
	  On mips we define one of __MIPSEL or __MIPSEB
	  (or whatever the latest SGI standard is.)

	* ${MACHINE_ARCH} describes the ``cpu architecture''
	  (in this case, "mips").  This gets used:
	   o in Makefiles, for mips-specific tests;
	   o in source code (via __${MACHINE_ARCH}__) to test
	     for mips-specific things;
	   o in shell scripts (e.g, when building sets) to pull
	     in all the mips-CPU-architecture specific files;

	* In the few places where we do need an endian-specific test
	  in source code, it's done via __MIPSEB or __MIPSEL.

	* This is how mips-specific source code has been done ``forever'',
	  since that' how the mipsco compilers did it (modulo underscores)
	  since day 1, and gcc copied it.

Why break any of that by introducing two ${MACHINE_ARCH}es (or having
two conventions, one for cpp and one for scripts?)

Worse, what happens when we go to 64-bit mips and have four arches to
support, instead of two?  ``it doesn't make sense to me''.


>- Change both platforms to "mipsel" and "mipseb".  Less desirable because of
>  the existing "mips" releases.

And as above.

Sure, we need a way to have "mipsel" or "mipseb" in a release(7)
hierarchy.  But it's not clear (to me, anyway) that release(7) clients
need to know about that: isn't it all hidden in symlink forests on
m68k?  In installing binary packages, yes, we'd like to know, and we
can update the pkgsrc README appropriately. (and when sysinst handles
binary packages, we add machinery to do it.)

That leaves two places which need to know about "mipsel" vs "mipseb":
sysinst, and the GNU autoconfigure scripts.  There we can test if
${MACHINE_ARCH} == mips, and if it is, check for hw.byteorder, and
DTRT appropriately.

Or we could create a new Make variable, if you think it's justified.
What I'm saying is I think it's better to create a new variable for
that purpose, and leave ${MACHINE_ARCH} as-is.

Hm. cgd actually suggested mips_be and mips_le for release(7).
If we went with that, it wouldn't be automatic anyway.