When specifying the `builder` attribute in `stdenv.mkDerivation`, this
will be effectively transformed into
builtins.derivation {
builder = stdenv.shell;
args = [ "-e" builder ];
}
This also means that `default-builder.sh` is never sourced and as a
result it's not guaranteed that `$NIX_ATTRS_SH_FILE` is set to a correct
location[1].
Also, we need to source `.attrs.sh` to source `$stdenv`. So, the
following is done now:
* If `$NIX_ATTRS_SH_FILE` points to a correct location, then use it.
Directly using `.attrs.sh` is problematic for `nix-shell(1)` usage
(see previous commit for more context), so prefer the environment
variable if possible.
* Otherwise, if `.attrs.sh` exists, then use it. See [1] for when this
can happen.
* If neither applies, it can be assumed that `__structuredAttrs` is
turned off and thus nothing needs to be done.
[1] It's possible that it doesn't exist at all - in case of Nix 2.3 or
it can point to a wrong location on older Nix versions with a bug in
`__structuredAttrs`.
had to move the installFlagsArray in preInstallPhases so that ${!outputX} work because they're set by the multiple-output hook
unar before:
closure size 1.4G
unar after:
closure size 138.9M
There is a bug in this feature: It allows extra arguments to leak in
from the environment. For example:
$ export extraFlagsArray=date
$ man ls
Note that you get the man page for date rather than for ls. This happens
because 'man' happens to use a wrapper (to add groff to its PATH).
An attempt to fix this was made in 5ae18574fc in PR #19328 for
issue #2537, but 1. That change didn't actually fix the problem because
it addressed makeWrapper's environment during the build process, not the
constructed wrapper script's environment after installation, and 2. That
change was apparently accidentally lost when merged with 7ff6eec5fd.
Rather than trying to fix the bug again, we remove the extraFlagsArray
feature, since it has never been used in the public repo in the ten
years it has been available.
wrapAclocal continues to use its own, separate flavor of extraFlagsArray
in a more limited context. The analogous bug there was fixed in
4d7d10da6b in 2011.
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- ran `/nix/store/9bilynlmzsc8z4wv6qjpgz983r434yad-gnustep-make-2.7.0/bin/gnustep-tests -h` got 0 exit code
- ran `/nix/store/9bilynlmzsc8z4wv6qjpgz983r434yad-gnustep-make-2.7.0/bin/gnustep-tests --help` got 0 exit code
- ran `/nix/store/9bilynlmzsc8z4wv6qjpgz983r434yad-gnustep-make-2.7.0/bin/gnustep-tests -h` and found version 2.7.0
- ran `/nix/store/9bilynlmzsc8z4wv6qjpgz983r434yad-gnustep-make-2.7.0/bin/gnustep-tests --help` and found version 2.7.0
- ran `/nix/store/9bilynlmzsc8z4wv6qjpgz983r434yad-gnustep-make-2.7.0/bin/openapp --help` got 0 exit code
- ran `/nix/store/9bilynlmzsc8z4wv6qjpgz983r434yad-gnustep-make-2.7.0/bin/opentool --help` got 0 exit code
- ran `/nix/store/9bilynlmzsc8z4wv6qjpgz983r434yad-gnustep-make-2.7.0/bin/gnustep-config --help` got 0 exit code
- found 2.7.0 with grep in /nix/store/9bilynlmzsc8z4wv6qjpgz983r434yad-gnustep-make-2.7.0
- directory tree listing: https://gist.github.com/30c82119c95760404469e4a1fcfa0d8d
