On Monday, 26.10.2015 at 16:04, Antti Kantee wrote:
> The hw and Xen platforms can now peacefully coexist side by side in the same
> destdir. This is done by installing libs to
> lib/rumprun-platform-machine_arch and lib/librumprun-machine_arch. There's
> still some tuning left with the build process (isn't there always?), but I
> think now the best way to move forward is to find a collaborator who's
> willing to turn Rumprun builds into packages, and hone out the rest of the
> details with that person. Any suggestions on who to pair with?
Unfortunately, the latest round of changes to destdir support which puts
things into subdirectories in an attempt to make things installable with
DESTDIR == /usr has broken rumprun-packages. To summarize the problem:
Using hw/x86_64 as an example, previously we had:
"Standard" convention:
DESTDIR/
bin/
include/ <--- "user" include files
lib/ <--- ALL libraries, "kernel" and "user"
(...)
"kernel" in this context means private to rumprun, not visible to
"userspace". "user" means "public" (libc, SSL, ...)
"Subdirectory" convention:
DESTDIR/
bin/
include/rumprun/ <--- "user" include files
lib/rumprun-x86_64/ <--- "user" libraries
lib/rumprun-x86_64-hw/ <--- "kernel" libraries
(...)
Several packages and their build systems *depend* on the "standard"
convention, since that is how things are normally done. Notably:
1) PHP does things like --with-openssl=DESTDIR --with-zlib=DESTDIR. This
expects the "standard" convention.
2) MySQL (and possibly others using CMake) have the same problem. CMake
wants to treat DESTDIR as a "sysroot" which again expects the "standard"
convention in order to be able to find things.
3) A cursory grep of rumprun-packages for other users of RUMPRUN_SYSROOT
reveals at least Erlang. No idea of the impact of the changes, but I'm
assuming the worst :-)
Rather than trying to sort out this mess, which I'm not even sure is
possible without "nonstandard" changes to upstream build systems, I think
we should follow the principle of least surprise and revert back to the
"Standard" convention for now.
Antti, your objections to the "Standard" convention are (please correct if
I'm wrong):
1) The need to add DESTDIR to $PATH.
2) Does not support installing hw and xen in the same DESTDIR.
3) Does not support DESTDIR == /usr (i.e. installing the toolchain to
"system" directories).
We've had to do 1) since app-tools was invented, so I don't think it's
really a problem.
Regarding 2), I think that's a "worst case", which we should just document
and say "please use a separate DESTDIR for now". If all that 2) needs is
that "kernel" libraries live in a subdirectory, that's also fine (can be
done with the "standard" convention, since the "userspace" build system
doesn't care about these).
Regarding 3), this is a **hard** and distribution-specific problem to get
right. (Ian: feel free to point at Debian threads about how long multiarch
took to get sorted.) I don't think we have the time or resources to try and
figure this out ourselves.
Thoughts?
-mato
