f7db612e8b
This is unrelated to this PR, but requested in https://github.com/NixOS/nix/pull/11224#discussion_r1715031841 Co-Authored-By: Robert Hensing <robert@roberthensing.nl>
2.1 KiB
| synopsis | prs | |
|---|---|---|
| The `build-hook` setting's default is less useful when using `libnixstore` as a library |
|
This is an obscure issue that only affects usage of the libnixstore library outside of the Nix executable.
As part the ongoing rewrite of the build system to use Meson, we are also switching to packaging individual Nix components separately (and building them in separate derivations).
This means that when building libnixstore we do not know where the Nix binaries will be installed --- libnixstore doesn't know about downstream consumers like the Nix binaries at all.
This is also unrelated to the post-build-hook, which is often used for pushing to a cache.*
This has a small adverse affect on remote building --- the build-remote executable that is specified from the build-hook setting will not be gotten from the (presumed) installation location, but instead looked up on the PATH.
This means that other applications linking libnixstore that wish to use remote building must arrange for the nix command to be on the PATH (or manually overriding build-hook) in order for that to work.
Long term we don't envision this being a downside, because we plan to get rid of build-remote and the build hook setting entirely.
There should simply be no need to have an extra, intermediate layer of remote-procedure-calling when we want to connect to a remote builder.
The build hook protocol did in principle support custom ways of remote building, but that can also be accomplished with a custom service for the ssh or daemon/ssh-ng protocols, or with a custom store type i.e. Store subclass.
The Perl bindings no longer expose getBinDir either, since the underlying C++ libraries those bindings wrap no longer know the location of installed binaries as described above.