Hi all, this is hopefully the final thread regarding app-tools toolchain naming.
For those who have not been following, the upstream "Selecting an architecture tuple for the rumprun toolchain" thread with my original proposal can be found here: http://thread.gmane.org/gmane.comp.gcc.devel/139324 Summary: Both Ian Jackson and myself have proposed an essentially identical naming scheme. This scheme, while not entirely compliant with upstream's view of how architecture tuples are *traditionally* used (emphasis mine), fulfills all the goals in my original proposal and is future-proof. Ian summarized the argument for not following the traditional scheme best, so I'm quoting him here: > The problem we are having here is that rumprun doesn't fit in the nice > tidy scheme of these arch tuples. I think the right thing to do is to > consider how these tuples are usually used, to try to understand how > best to express reality within the existing framework. Therefore, I'd like to propose that we the following scheme for naming both the filesystem "arch prefix" and "arch tuple" passed to configure: <cpu>-rumprun{posix,xen,baremetal}-<kernel+userland> Where <kernel+userland> is currently "netbsd", i.e. the existing "native" value is re-used for this field. So, the current rumprun app-tools wrappers will be named, for example: x86_64-rumprunxen-netbsd-gcc x86_64-rumprunbaremetal-netbsd-gcc The corresponding arch tuples used for configuring autoconf applications will be: x86_64-rumprunxen-netbsd x86_64-rumprunbaremetal-netbsd Examples of hypothetical *future* naming: Rumprun on xen, with a Linux rump kernel and glibc: x86_64-rumprunxen-linux-gnu Rumprun on ARM baremetal, with a Linux rump kernel and musl libc: arm-rumprunbaremetal-linux-musl etc. I'd like to get the renaming done ASAP, so if anyone has objections to the proposed scheme please speak up now! Final call :-) Martin
