On 30/03/15 10:45, Martin Lucina wrote:
Hi All,
Regarding the recent threads on app-tools naming, et al. I'd like to get
some advice from knowledgeable toolchain people before making a final
choice. I have written the following draft to send to the GCC mailing list
as that appears to be where most toolchain people hang out.
Antti, Justin, anyone else interested, can you please read through this and
let me know if its clear and if I have missed anything before I send it on
to the GCC folks?
I'm not too interested in getting involved with the details here, so I
won't comment on the content of your proposal, just do readability
nitpicking.
I'm working on improving the toolchain for the Rumprun stack, and need to
decide on a suitable architecture tuple to use both as a prefix for naming
the toolchain and to pass to autoconf/other build systems when building
applications.
Background: Rumprun[1] is a software stack built with Rump Kernels[2] which
enables running existing POSIX software without an operating system on
various platforms (Xen, bare metal/QEMU/KVM, POSIX userspace).
I'd somehow work these two paragraphs together, for the benefit of
readers not losing interest, e.g. "i'm working on selecting the right
architecture tuple for the rumprun toolchain. rumprun is [...].
[second half of the first paragraph]". Well, I don't know if my
proposal is any better, but just trying to read your version through the
mind of someone who has never heard about rumprun, the explanation for
rumprun comes too late.
a) come up with a tuple that is as backwards-compatible as possible with
*existing, unmodified* build systems. I.e. any software that has
existing support for cross-compiling in its build system should "just
build". Note that I'm not expecting all software thus built to "just
work", as that is out of the scope of the build system.
Is the last sentence necessary? It might preempt smartypants, but most
likely it will confuse everyone else.
c) if possible, facilitate installing several toolchains for different
platforms side by side without needing to use separate directory
hierarchies. This is primarily for end-user convenience once we provide
installable packages of the rumprun stack.
Even I had to think for some time what the second half of the last
sentence means. Just "for end-user convenience." is enough, IMHO.
d) there are some very specific software packages (Xen libraries, QEMU)
that may wish to use "private" interfaces provided by the underlying
platform rumprun is running on. It is unclear if this is best done by
compile-time testing for the presence of such interfaces, or if we
should provide information about the underlying platform to the
application build system, ie. make it visible in the chosen architecture
tuple.
I'm not sure that this paragraph is understandable to someone without
in-depth knowledge of rumprun.
I have the following two proposals:
1) Use the "Old form"[3] cpu-vendor-os:
'cpu' would be the target ISA (arm, i386, x86_64, ...).
'vendor' would be 'rumprun'.
'os' would be 'netbsd', as we provide a NetBSD-ish "userspace".
Note: we *currently* provide only a netbsd-ish rumprun stack. We may
provide ones based on other operating systems in the future.
One last thing I don't fully understand is whether or not we need to care
about ABI differences for embedded systems (eg. hard vs soft float) for the
purposes of the rumprun toolchain.
I'm not sure how you expect them to respond to this paragraph, but then
again I don't know much about the subject, so it might be ok.
Thanks for handling this important issue!
- antti
