>: You assume a tight identity between "will this run"?  and
>: $MACHINE_ARCH, but that just doesn't exist.

>It exists, and is being used in
>
>- GNU autoconf
No, it isn't.


>- pkgs (documented, and tightly used)

I grovelled to see just where.  I see seven lines where
${MACHINE_ARCH} is used -- six, excluding a comment.


1.  Check to see if ${MACHINE_ARCH} is in  ${ONLY_FOR_ARCHES}.
    This is my sense of ${MACHINE_ARCH}, not yours.
    (should be the same for all mips regardless of endian-ness)

2.  Sets build object dir. This would be sueful to split.
    But we could equally well use, say,  ${OBJ_ARCH},
    which is mipsel and mipseb where appropriate.


3. Build perl with static (.a) dynalib libraries instead of .so.
   AFAICT this is really a toolchain issue, not ${MACHINE_ARCH} at all,
   but it's my sense of ${MACHINE_ARCH}, not yours.
   (should be the same for all mips regardless of endian-ness)

4. print  warning for #2.
   (should be the same for all mips regardless of endian-ness)

5. Expand PLIST packing lists, doing substitution for ${MACHINE_ARCH}.
   
6. Same as 5, but without MANZ.

${MACHINE_ARCH} *is* used in some packing lists: all perl5 related, as
of today's sup. (i thought the .h files were actually
byteorder-independent, but the .so files clearly aren't.)
 

That's where i'd replace #5 and #6 with:

	a) define a new symbol, say ${OBJ_ARCH}, which does what
	   you want (mipsel or mipseb on mips)

	b) use ${OBJ_ARCH} for #5 and #6 above and in PLISTs, 
	   not ${MACHINE_ARCH};

	c) use ${OBJ_ARCH} wherever it makes sense -- e.g., setting
           BSDOBJDIR (or whatever it's called) obj.{$OBJ_ARCH},
	   rather than  obj.${MACHINE}?
	   (is it a bug that we still use ${MACHINE}??)

It could well be that some of the ${OBJ_ARCH} files are acutally
sharable across a ${MACHINE_ARCH}, but i'd punt on that for now (since
it requires educating perl to use a searchlist, or a symlink farm.)

			---------------


It could turn out that what we're disagreeing about is a databse
normalization issue.

Should we embed _all_ the attributes of a given platform (int/address
size, endian-ness, 64-bit vs 32-bit float, architecture level) in a
proliferation of uname -m/${MACHINE_ARCH} values?

Or should we learn that that makes for a hopeless update task as more
and more ``OBJ_ARCH'' variants proliferate (64-bit FP, 64-bit int,
powerpcle), And it's much better design to factor out the different
attributes?  We learnt that with a.out vs ELF, surely?


Which reminds me, todd: surely your rule says ${MACHINE_ARCH} has to
change when a port changes from a.out to ELF? :->