Hi all,
the long discussion regarding app-tools toolchain naming has finally borne
fruit (and code!).
1) rumpbake
As of today, we have introduced a new `rumpbake' tool for baking your
freshly built unikernels. This allows us to split the notion of `target
board' from the compiler toolchain used to build applications. It also
brings the benefit of the user being able to define their own `targets',
and specify exactly which rump kernel components are linked into the
final unikernel image.
The user-visible change is that `rumprun-*-cc' will no longer produce a
unikernel image, but instead produce an intermediate file that must be
"bakend" into the final unikernel image with `rumpbake'. "Hello, world"
example:
$ rumprun-bmk-cc -o hello hello.c
(produces an intermediate "hello")
$ rumpbake -T hw_generic -o hello.bin hello
(produces the final unikernel as "hello.bin", targeted for the "hw_generic"
configuration)
$ rumprun qemu ./hello.bin
(boots the unikernel)
Note that the `rumpbake' syntax is (as for `rumprun') still being developed
and may change. Thus, the best way to check the current syntax is to run
`rumpbake' with no options.
2) Toolchain renaming
With `rumpbake', we are hopefully now in a position to unify and rename the
app-tools toolchain, using the following scheme:
<CPU>-rumprun-netbsd{elf}
Examples:
i686-rumprun-netbsdelf (32-bit Intel compiler targeted for i686)
x86_64-rumprun-netbsd (64-bit Intel compiler targeted for x86_64)
arm<SUBARCH>-rumprun-netbsd (32-bit ARM compiler targeted for <SUBARCH>)
This means we will NOT need to put the `board' or `platform' in either the
toolchain name or autoconf tuple. Applications can be built once using the
toolchain appropriate for the target CPU.
If anyone has any last-minute input on the above scheme, please speak up
now!
This second step will take a few days to complete, please bear with the
inevitable churn until it is done, documentation and wiki is updated, etc.
Martin
