On 06/05/15 13:20, Ian Jackson wrote:
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.
Ian,
"must" and "clearly necessary" are the bits we are discussing ... clearly ;)
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
Sure, we could.
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
Now that you've typed examples for us to see, they don't look too bad,
at least to my eye.
So, the proposal is:
<cpu>-rumprun_<platform>_<board>-netbsd{,elf}
?
And the rationale for the middle part is:
a) users can identify the compiler
b) toolchain can be coinstalled
Do we want it parseable, i.e. must all three elements be always present
and may not include underscores? What will it be for xen or posix?
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
Correct, there are two sets of toolchain wrappers:
1) the ones created by buildrump.sh, which produce the right type of
binary, depending on what backing $CC and what -F arguments were given
(e.g. -m32 or not)
2) the ones created by app-tools (at least currently known as
app-tools), which include platform/board link information, and which use
the wrappers created by "1"
("1" happened after you've last looked into the code, I assume)
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.
I'm not sure I see the fuss with coinstallation, given that it's just a
matter of $PATH; the backing files aren't coinstallable in any case.
Seems like someone has invented an arbitrary standard to bow down to.
That said, as much as I don't want us to be bowing to standards when it
doesn't make sense, I also don't want us not complying with them just
because we could invent our own arbitrary standard.
