On 18/03/15 17:25, Martin Lucina wrote:
Hi,having dealt with some more build systems (CMake for one), I have realised that the naming we agreed on for the app-tools toolchain back in January [1] is wrong, and should be fixed. Mea culpa. The current scheme names the tools as rumprun-{xen,bmk}-cc, ... This causes several problems: 1) "rumprun-bmk" or "rumprun-xen" are not a valid target architecture for autoconf. This causes configure to print warnings when CC is set to one of our tools. Warnings are not good, as they will confuse users and CI systems.
I think that's a valid problem.
2) Our current implementation of rumprun-xen-configure uses an obsolete interface [2] to tell autoconf that the package is being cross-compiled by overriding CC. What we should be doing instead is supplying --host=TARGET_ARCH to configure, however that will only work with TARGET_ARCH being a valid target architecture.
"obsolete" is a dangerous term when it comes to autoconf. decade-old configure scripts are not rare in the real world.
3) We should be providing prefixed wrappers for all the standard tools in the toolchain (ar, nm, ld, strip, ...). Notably, I had to ad an "ar" wrapper to get CMake to build any library at all as if you tell it to cross-compile it will insist on using prefixed tools (unlike autoconf, which falls back to host tools by default). 4) With the current names it is not possible to distinguish cases where e.g. one wishes to build an app-tools toolchain targeted for i386 on x86_64. Therefore, I propose to rename the tools yet again (hopefully for good) to be correctly prefixed with the full autoconf target architecture, just like any other cross-compilation toolchain.
On irc I managed to extract from mato that this means e.g. arm-rumprun-netbsd-gcc. Then mato shot to dinner; I'm not sure if that's lacking "xen" and "baremetal" by design or accident. I'm a big fan of not exposing information where it's not necessary, but I didn't think his proposal through, so not sure if they absolutely should be there or not.
Yes, having standard naming is good, as long as everyone understands which standard we're talking about ;)
Anyway, the vibe I'm guessing is that the description matches the tool wrappers already created by buildrump.sh. If at all possible, I think we should enhance buildrump.sh wrapper creation instead of having two sets of subtly different cross compilers. That would also unify the "kernel" and "userland" build, which is a direction I'd like to see us going into, i.e. fixing the dichotomies which were created when "userland" was invented ...
