On 2016-08-06 05:34, Patrick Mahoney wrote:
I'll hopefully have time to work on this in the coming days. Not sure what best
to call the option. --enable-nix seems too specific. The Guix packager may not
realize it yet, but Guix needs this option as well (it is based on Nix).
"Naming is hard" + "What's in a name?"
Call the option whatever you like; if we come up with a better name before
the patch is applied, we'll change it.
The important thing is to make sure the semantics are right. I'm not sure
exactly which of the slashpackage things in config.h the new option should
enable: I'll have to make a complete grep in skalibs in particular to check
whether slashpackage influences anything else than just the prefixes.
Or possibly provide options to set --binprefix and related directly, though
that is a bit cumbersome, and there may not be a use case to set them
individually (rather than to set them as a group to satisy Nix or
slashpackage).
Either a package is installed with absolute path guarantees or it's not;
I think mixing both approaches would be very confusing and error-prone.
Patching the config.h is also a possibility, but you'd need to patch the
config.mak too. Maybe it's still the simplest way of doing it; however,
the patching step would also need to be duplicated in Guix, whereas a
configure option could be reused as is in Guix. Maybe Eric Le Bihan could
tell us how he handled the Guix packaging?
Each package in Nix lives in its own directory. To "install" a package is to
symlink its directories into a tree of symlinks called a "profile". Typically
one sets one's PATH to include ~/.nix-profile/bin. Any package's libexec dir
would be linked to ~/.nix-profile/libexec, but not present in PATH. A package
that isn't "installed" in any profile may still be present as a dependency of
another package. In most cases then, the correct way to invoke binaries is via
the immutable path directly into that package's dir (e.g.
/nix/store/${somehash}-somepackage/libexec/command).
Yeah, a package's unexported binaries should be accessible from any other
component from the same package, independently from profiles. So the right
solution would be to have a specific libexec subdirectory for the package
and hardcode the full path to it. "~/.nix-profile/libexec" is nonsensical.
hardcoded absolute rpaths at compile-time (maybe a tiny bit less brrrr).
This one. They even provide the patchelf[1] command to force this for binaries
whose source is not available.
That's the least ugly solution, I guess. Apart from making things as static
as possible.
Nix's default is actually to configure with --disable-static, though I have
disabled that for skarnet packages.
That's a weird default to have when your whole system is based on the idea
that your dependency graph is immutable! In order to gain benefits from
shared libraries, the builder has to ensure that most packages are built
against the exact same version of common libraries - and that's a pretty
tough requirement to meet.
As far as skarnet.org packages are concerned, --enable-static will be the
easiest solution by far.
I've not looked into what it takes to build against musl, but would be an
interesting option.
You just need musl, with the musl-gcc wrapper. Cross-building is another
story (you need a musl cross-toolchain, which are easily created nowadays
with Rich's musl-cross-make tool), but if you're sticking to native
builds, building against musl has never been easier (at least for skarnet.org
packages).
--
Laurent
