[email protected] said: > Therefore, I propose to rename the tools yet again (hopefully for good) to > be correctly prefixed with the full autoconf target architecture, just like > any other cross-compilation toolchain.
Antti pointed out to me on IRC that the above paragraph is a bit terse in specifying exactly what I'm proposing, so here goes: The autoconf system type is defined as a 'target triplet', which has the form 'cpu-vendor-os', OR the newer form 'cpu-vendor-kernel-os' (see below). 'cpu' will be the target architecture (arm, i386, x86_64, ...), and vendor will be 'rumprun', nothing controversial there. 'os' should be set to 'netbsd' as that is the closest match to the userland interfaces we are providing, and will be picked up by existing software that has special casing for building on NetBSD. Following from the above, tools would be named, for example: arm-rumprun-netbsd-gcc, x86_64-rumprun-netbsd-gcc, i386-rumprun-netbsd-ld, etc. Now, we could also use the newer form. This has the advantage that we can use the either the 'kernel' or the 'os' portion to specify the hypervisor/platform we are running on (xen, bmk, posix, frankenlibc). However, using the newer form brings a different set of problems with it: 1) The autoconf documentation is unclear on what the conventions for the new form is. Do we use x86_64-rumprun-xen-netbsd or x86_64-rumprun-netbsd-xen? How does that map to existing build scripts that check for 'os' == 'netbsd' and do something special? 2) All the new forms are actually hardcoded (!!) in config.sub [1], which means they won't work (I tried) with existing autoconf-based software unless they get around to updating config.sub in their build system. Martin [1] http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=blob;f=build-aux/config.sub;h=8b612ab89df97769d827a8b7f64e1dad21ac0b71;hb=HEAD#l114
