If multiple files with the same build id were found, we silently randomly
overwrote one with the other.
Change the order to make the output deterministic, and emit a
warning when overwriting.
When I authored the nix file in
335a9083b0,
`makeSetupHook` didn't know about `passthru` or `meta`.
So I foisted these attributes on the
derivation with `.overrideAttrs`.
Commits ba895a7da8 and
48034046bf enabled
`makeSetupHook` to receive these attributes directly.
It seems advisable to use that instead of `.overrideAttrs`.
AFAIK this doesn't have a noticable effect for typical
Linux executables, but will avoid setting the timestamp
inside the file for Windows executables to the build
date.
This fixes multiple entries being returned from getDesktopParam, e.g. in the
case of localized key names: 'Name', 'Name[de]', and makes this function to
match this key exactly instead of a pattern for the same reason.
Currently, separate-debug-info adds a debug output, and the build fail when it is
not created. the output is only created when at least one elf file is
stripped.
As a result, adding separateDebugInfo = true on a lib will break the
static build (unless the lib also contains an executable). In order to
not have to remember to add an exception every time, let's just create
the debug output unconditionally.
For reproducibility, nixpkgs sets `-frandom-seed` to the first 10
characters of the outpath of the derivation being built.
This PR allows to manually select from which outpath the
10-character prefix is taken, by setting
`NIX_OUTPATH_USED_AS_RANDOM_SEED` as a derivation attribute (or
directly as an environment variable).
For an example use of this functionality, see:
https://github.com/NixOS/nixpkgs/pull/209870
checkInputs used to be added to nativeBuildInputs. Now we have
nativeCheckInputs to do that instead. Doing this treewide change allows
to keep hashes identical to before the introduction of
nativeCheckInputs.
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).
