Antti Kantee writes ("Re: Final call: app-tools toolchain naming / arch tuple
selection"):
> There were two ongoing discussions:
>
> 1) should the tuple contain the platform at all
Yes, it must.
> 2) can we think of a better platform name for "baremetal"
>
> If the answer to "1" is "yes", then we definitely shouldn't leave it
> empty in any case.
>
> The argument in favor of "yes" for "1" was that users can look at the
> tuple alone and decide where that particular toolchain can be used.
For the case of `posix' and `xen' it is clearly necessary. It is
sufficient to identify the toolchain.
> The argument in favor of "no" for "1" was that since the toolchain also
> implies everything about the platform (including how to boot it, where
> devices are located, etc), you need some sort of "platform+board"
> construct there for the rational for "yes" to apply. It's probably not
> sensible to fully enumerate every option in that space in the tuple.
> Therefore, it's better to supply no information than misleading information.
I don't understand why you couldn't have a tuple like this:
x86_64-rumprunbaremetalpc-netbsd
Since _ is permitted in names perhaps that could be
x86_64-rumprun_baremetal_pc-netbsd
The alternative is that it becomes impossible difficult to coinstall
toolchains for different targets. Consider the desirability of:
arm-rumprun_baremetal_rpi-netbsd
arm-rumprun_baremetal_arndale-netbsd
Although in principle the object files for some
arm-rumprun_baremetal_*-netbsd could be compatible - the "linkers"
which generate the ultimate images need to be different. That is,
you need to have both of
/usr/bin/arm-rumprun_baremetal_rpi-netbsd-ld
/usr/bin/arm-rumprun_baremetal_arndale-netbsd-ld
The alternative is to either (a) make the cross toolchains
non-coinstallable or (b) do something nightmarish to the portable
package's build system to try to bodge the link step (and maybe bodge
the compiler) (c) indicate via environment variables (or perhaps PATH)
what the target is. All of those are very undesirable and
nonstandard.
Ian.
