On 06/05/15 13:44, Martin Lucina wrote:
So, a thought experiment: Can we unify the different toolchains altogether?In order to do that, we need the extra information about the platform+board to come from somewhere. Inventing nonstandard compiler flags is not a good solution. The only logical channel remaining would appear to be an environment variable. So, how about this: 1) We unify the toolchain wrappers, dropping the platform from the names entirely. Therefore, the tools are named simply <cpu>-rumprun-netbsd*-{gcc,g++,...}. The autoconf tuple will be <cpu>-rumprun-netbsd*. (*) Can be "elf", etc. to mirror native NetBSD usage. 2) The user *must* set an environment variable, (say) RUMPRUN_TARGET to specify (say) "xen", "qemu", "rpi", ... We will need to think about that namespace. 3) If the environment variable is *not* set, the toolchain wrappers will complain loudly and fail.
Env variables are "meh", because they add out-of-band configuration information which is difficult to keep track of unless you put it the prompt. If you start modifying the prompt, you might as well go the ". xcompileenv.sh" route.
It's also difficult to remember what are the accepted values, unless we add some utility to print them, since ls or <tab> won't work. Ok, <tab> can be made to work in some shells, but I don't like the "install complex stuff to be able to do simple things" approach -- that's why I switched from vim to nvi so that I wouldn't have to keep copying .vimrc around to be able to do simple things.
$RUMPRUN_TARGET must also accurately identify the backing compiler. That's probably isomorphic to codifying it into the wrapper name, with the exception that the wrapper can already inherently *modularly* include that information. A global wrapper would probably have to sourcing files from some directory and try to map the $TARGET compiler to the right place. (unless, of course, RUMPRUN_TARGET contains the full information, in which case I assume even a worse usability nightmare than what I painted above)
