For example, you can now say:
configureFlags = "--prefix=${placeholder "out"} --includedir=${placeholder "dev"}";
The strings returned by the ‘placeholder’ builtin are replaced at
build time by the actual store paths corresponding to the specified
outputs.
Previously, you had to work around the inability to self-reference by doing stuff like:
preConfigure = ''
configureFlags+=" --prefix $out --includedir=$dev"
'';
or rely on ad-hoc variable interpolation semantics in Autoconf or Make
(e.g. --prefix=\$(out)), which doesn't always work.
This makes it easier to create a diverted store, i.e.
NIX_REMOTE="local?root=/tmp/root"
instead of
NIX_REMOTE="local?real=/tmp/root/nix/store&state=/tmp/root/nix/var/nix" NIX_LOG_DIR=/tmp/root/nix/var/log
* Dockerfile: add GNU tar native dependency
`builtins.fetchTarball` requires GNU tar to be available in the $PATH in
order to unpack the fetched tarball (there is a FIXME comment for this),
which Alpine does not ship by default (it ships BusyBox tar).
* Dockerfile: add GNU bash native dependency
`nix-shell` defaults to invoking `bash` from the $PATH for the subshell.
In theory this can be overriden with the NIX_BUILD_SHELL environment
variable, but this does not work properly. `nix-shell` generates and
passes a script (`$rcFile`) to be executed by the subshell which uses
bashisms (`source` and `shopt`). Additionally, in interactive mode,
`nix-shell` passes the `--rcfile` argument to the shell, which is
another bashism.
Because `bash` is thus de-facto required, add `bash` as a native package
dependency to make it available for `nix-shell`.
Currently, man has issues finding man pages for Nix-installed
application (also, `nix-env --help` doesn't work). The issue is caused
by custom `$MANPATH` set by my system. That makes man use it instead of
searching in default location.
Either of next lines workaround the issue:
```sh
unset MANPATH
export MANPATH=$HOME/.nix-profile/share/man:$MANPATH
```
This patch adds the later line to the `nix-profile.sh` if user has
`MANPATH` set. (Not clearing `MANPATH` as that would be disrespect of
user's preferences.)
As a side-effect, host's man might find man pages installed by Nix.
For one particular NixOS configuration, this cut the runtime of
"nix-store -r --dry-run" from 6m51s to 3.4s. It also fixes a bug in
the size calculation that was causing certain paths to be counted
twice, e.g. before:
these paths will be fetched (1249.98 MiB download, 2995.74 MiB unpacked):
and after:
these paths will be fetched (1219.56 MiB download, 2862.17 MiB unpacked):
Once upon a time, I wrote my bachelors thesis about functional
deployment mechanisms.
I had to evaluate several szenarios where package management and
deployment were relevant. One szenario was to do distributed builds
over several machines.
I told myself: Weee, nix can do this! And with nix, this is actually
save, as you do not have side effects when building!
So I started. I use a cloud to set up four virtual machines where I
wanted to do the build. A fifth machine was used as master to distribute
the builds. All was good.
I created the necessary SSH keys, made sure every machine was reachable
by the master and configured the build in my remotes.conf.
When I started to try to build weechat from source, the build failed. It
failed, telling me
error: unable to start any build; either increase ‘--max-jobs’ or enable distributed builds
And I started to dig around. I digged long and good. But I wasn't able
to find the issue.
I double and triple checked my environment variables, my settings, the
SSH key and everything.
I reached out to fellow Nixers by asking on the nixos IRC channel. And I
got help. But we weren't able to find the issue, either.
So I became frustrated. I re-did all the environment variables.
And suddenly,... it worked! What did I change? Well... I made the
environment variables which contained pathes contain absolute pathes
rather than relatives.
And because I like to share my knowledge, this should be put into the
documentation, so others do not bang their heads against the wall
because something is not documented somewhere.