In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
The previously used pattern was introduced in #318614, but technically
leaked the default flags into the global scope. While this would
probably not make much of a practical difference, making concatTo
support default values is a much cleaner approach.
The test fails without 64eaa63181
("stdenv: concatStringsSep: quote ${sep}")
Co-authored-by: Ivan Trubach <mr.trubach@icloud.com>
Co-authored-by: Wolfgang Walther <walther@technowledgy.de>
'command -v builtin' returns 'builtin', which doesn't suit us since
we're looking for program in the given PATH. This could give us shebangs
like this:
#!builtin
which is surprising.
Switch to 'type -P command' which always returns a path, even if command
is both a builtin and an executable (for example 'test'), or fail is
'command' is just a builtin.
This fixes using inputDerivation on derivations that are fixed-output.
Previously:
```
nix-repl> drv = runCommand "huh" { outputHash = "sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU="; outputHashAlgo = "sha256"; outputHashType = "flat"; } "touch $out"
nix-repl> drv.inputDerivation
«derivation /nix/store/d8mjs6cmmvsr1fv7psm6imis5pmh9bcs-huh.drv»
nix-repl> :b drv.inputDerivation
error: fixed output derivation 'huh' is not allowed to refer to other store paths.
You may need to use the 'unsafeDiscardReferences' derivation attribute, see the manual for more details.
```
Fixes: https://github.com/NixOS/nixpkgs/issues/304209
This fixes a bug where `patchShebangs` crashes when trying to patch
files that contain only a shebang (e.g. `#!/bin/bash`) (and nothing
else) and do not end with a newline.
Such file can be produced using `printf "#!/bin/bash" > example` or
`echo -n "#!/bin/bash" > example`.
I don't understand why one would want to create such files, as they do
literally nothing, but the chromium tarball we are using started
shipping some 🫠
Full reproducer:
```nix
with import <nixpkgs> { };
stdenv.mkDerivation {
dontUnpack = true;
name = "patch-shebangs-no-trailing-newline-reproducer";
postPatch = ''
printf "#!/bin/bash" > reproducer
chmod +x reproducer
patchShebangs reproducer
'';
}
```
```
❯ nix-build reproducer.nix
this derivation will be built:
/nix/store/vmbshdkdk4a0bayw3wi21wvxyhzpcsy2-patch-shebangs-no-trailing-newline-reproducer.drv
building '/nix/store/vmbshdkdk4a0bayw3wi21wvxyhzpcsy2-patch-shebangs-no-trailing-newline-reproducer.drv'...
patching sources
patching script interpreter paths in reproducer
/nix/store/vr6wwdxkmyy44sg0gwxi10b8fc5zhwz0-stdenv-linux/setup: line 144: pop_var_context: head of shell_variables not a function context
error: builder for '/nix/store/vmbshdkdk4a0bayw3wi21wvxyhzpcsy2-patch-shebangs-no-trailing-newline-reproducer.drv' failed with exit code 1;
last 3 log lines:
> patching sources
> patching script interpreter paths in reproducer
> /nix/store/vr6wwdxkmyy44sg0gwxi10b8fc5zhwz0-stdenv-linux/setup: line 144: pop_var_context: head of shell_variables not a function context
For full logs, run 'nix log /nix/store/vmbshdkdk4a0bayw3wi21wvxyhzpcsy2-patch-shebangs-no-trailing-newline-reproducer.drv'.
```
This change adds a flag to update shebang paths that point to the Nix
store. This is particularly useful when a cross-compiled package uses
same script at compile-time and run-time, but the interpreter must be
changed since hostPlatform != buildPlatform.
This commit adds a derivation `gcc-stageCompare` to
`pkgs/test/stdenv/default.nix`.
It is important to always build this derivation whenever building
`stdenv`! Because we are using a Nix-driven bootstrap instead of
gcc's built-in `--enable-bootstrap`, the `gcc` derivation no longer
performs the post-self-compilation sanity check. You must build
this derivation in order to perform that sanity check.
The major benefit of this new approach is that the sanity check
(which involves a third compilation of gcc) can be performed
*concurrently* with all packages that depend on `stdenv`, rather
than serially. Since `stdenv` has very little derivation-level
parallelism it cannot take advantage of more than one or perhaps two
builders. If you have three or more builders this commit will
reduce the time-to-rebuild-stdenv by around 20% (one of three gcc
rebuilds is removed from the critical path, and stdenv's build time
is dominated by roughly 3*gcc + 1*binutils + 1*bison-test-suite).
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
Closes#16182
This improves the error message
Error: _assignFirst found no valid variant!
which occurred when the set of outputs was not sufficient to set
the various outputDev, outputBin, etc variables. Specifically, this
would mean that "out" is not among the outputs, which is valid for
a derivation.
This changes the message to something like
error: _assignFirst: could not find a non-empty variable to assign to outputDev. The following variables were all unset or empty: dev out.
If you did not define an "out" output, make sure to define all the specific required outputs: define an output for one of the unset variables.
While this isn't a full explanation of what stdenv can and can not do,
I think it's vast improvement over the 0 bits of information that it
used to provide. This at least gives a clue as to what's going on, and
even suggests a fix, although probably multiple such fixes are required
in an instance where someone starts with a no-out derivation from scratch
(and decide to persist).
Derivations not using `__structuredAttrs` should not attempt to set
environment variables from `env`.
Derivations using `__structuredAttrs` should fail if `env` is not
exportable.
