On Thu, 23 Jul 1998, Jonathan Stone wrote:

: >Not quite.  You forgot to address how binary pkgs are known to be useable
: >across a given ${MACHINE_ARCH} 
: 
: Really? As it stands, they aren't.  (Nor are install sets.)
: Isn't that what we're disagreeing about?

This is part of it.

: And at least for release(7), I think we want all three of
: mipsel/mipseb/mips, so that mips-arch headers and manages can be
: shared.

The mips-arch headers can be shared without a common definition for
MACHINE_ARCH:  it's our main tree build system that doesn't currently cope
with it.

The problem is that the same definition of MACHINE_ARCH breaks too much
stuff *NOT* in the NetBSD src tree.  I could give a [insert four letter
here] less whether it makes our build system a trifle easier to find the
include files.  The arch-specific files already include <mips/...> and the
makefiles and kernel makefile templates would just have to be modified to
cope, that's all.

We use MACHINE_ARCH to determine a set of compatible binaries.  We've used
it before, we're using it now, and we probably will continue to be using it
that way.  The existing state is breaking that promise that MACHINE_ARCH
gives.

: >- or how ${MACHINE_ARCH} could be used to
: >uniquely identify a given binary.    ``Historical precedent'' or not, it's
: >_actively_ used for that.
: 
: Where, though?  Can you give me some examples?  How do we fix it so
: they aren't? If it's toolchain programs, then should be _the same_
: program for both mipseb and mipsel (on any given CPU) with runtime
: flags to select the endian-ness.

: Can you give some examples of what this breaks? I still dont get it.

- Toolchain.
- Pkg system.  All of it, particularly in the realm of binary pkgs.
- make(1).
- uname(1).
- Third-party software that needs uname(1) for configuration.

Patching all of this is the Wrong Way to do it.  If the only argument in
support of keeping the MACHINE_ARCH same is the sharing of include files,
fix the way include files are used in the src tree.  That's ~trivial.

There's a reason GNU autoconf treats mipsel and mipseb as different
architectures - it _is_ a different software architecture, because the
binary format and data storage (and probably opcodes too, I don't know) are
not the same, be it through byte order or not.

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