My only request: whatever gets decided on MUST BE CLEARLY DOCUMENTED.

.pm

Todd Vierling writes:
> In the interest of trying on another's shoes, I'll propose Jonathan's own
> alternate solution, OBJ_ARCH, with all extra bases covered.  Please respond
> with any comments.  Yes, this means I'm volunteering to do a significant
> chunk of said work, but it's really not as difficult as it looks.
> 
> Define OBJ_ARCH as an identifier that specifies a unique set of CPU,
> architecture, and toolchain criteria:
> 
> - the processor architecture, such as mips or m68k
> - the basic object file format (a.out, ELF32, ELF64, ECOFF) that is the
>   _default_ output of the toolchain for that OBJ_ARCH
> - the least common denominator processor, which is also the default output
>   of the toolchain (for example, m68k = MC68020)
> - the endianness of the processor, if it supports multiple endiannesses
> - the basic set of integer and pointer sizes uniform across the OBJ_ARCH
> 
> =====
> 
> With that defined, here's how I propose OBJ_ARCH be implemented:
> 
> - Unless otherwise changed, it will be equal to the current value of
>   MACHINE_ARCH.  This is in the interest of simplicity.
>   Exceptions:  mips splits into mipseb and mipsel, and the sparc64 port
>   becomes sparc64 if it changes to a native 64-bit object format.
> 
> - A change in the OBJ_ARCH will happen when a new architecture intrinsic
>   (endianness, integer/pointer size) is introduced in a new port.
> 
> - When a new OBJ_ARCH is created, the new port will use a new OBJ_ARCH but
>   the old OBJ_ARCH will _not_ change its name to match aesthetically.
> 
> - The value will be available for scripts to choose the proper architecture
>   via "sysctl hw.obj_arch".  (This is the reason for the previous
>   condition.)
> 
> - NetBSD's make (Pmake) program will include a definition of OBJ_ARCH such
>   that NetBSD builds may use it in Makefiles directly.
> 
> - All machines in the same OBJ_ARCH will use an identical toolchain, even
>   though alternate object format targets may be available for kernel or
>   other special purpose builds on some ports in an OBJ_ARCH.
> 
> - GNU autoconf scripts will be modified such that:
>   * Each OBJ_ARCH has a one-to-one mapped MACHINE_GNU_ARCH which can be used
>     in configuration as MACHINE_GNU_ARCH-unknown-netbsd.  No script will
>     depend on filling in the "manufacturer" field.  (Already have
>     MACHINE_GNU_ARCH, but it's not unique for mips.)
>   * GNU autoconf scripts will remap mips-dec-netbsd to mipsel-unknown-netbsd
>     and mips-sony-netbsd to mipseb-unknown-netbsd for compatibility.
>   * These GNU autoconf changes will be applied to the NetBSD source in-tree
>     (src/gnu/dist) as well as GNU pkgs, and appropriate code changes for
>     autoconf will be sent back to the FSF for inclusion in the next autoconf
>     release.
> 
> - Release sets and binary packages will use OBJ_ARCH to identify a set of
>   compatible binaries.  Released binaries bearing the OBJ_ARCH tag will
>   conform to the least common denominator processor, though anyone is of
>   course free to make binaries that are customized for a "higher" processor.
> 
> - If a toolchain change happens to only _part_ of an OBJ_ARCH between full
>   formal releases, such as a.out->ELF, the new toolchain becomes a new
>   OBJ_ARCH (and again, the old name stays the same).  HOWEVER, if the entire
>   OBJ_ARCH changes toolchains between full formal releases, the OBJ_ARCH
>   need not change, as it is still unique combined with the NetBSD version.
> 
> - For pkg system compatibility, OBJ_ARCH will be the same as MACHINE_ARCH
>   for 1.3.x systems by checking whether or not Pmake sets the OBJ_ARCH
>   variable; except for "mips", which will become the new "mipsel", as only
>   little-endian mips platforms had 1.3.x releases.
> 
> -- 
> -- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)
>