New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rust: Fix build flags #93128
rust: Fix build flags #93128
Conversation
This reverts commit deb7815. Mixing up two distinct phases of a derivation's build is not a good idea. See also NixOS#91689 (comment).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can confirm that this fixes the rustup issue.
Some packages I tested with nixpkgs-review, all succeeded: rustup
, rls
, alacritty
, mdbook
, ripgrep
, rustfmt
, sd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Tested with tokei
, which also exhibited problems (#91298 (comment)) -- now it shows yaml serialization in tokei --help
!
While the artifacts from `buildPhase` should be used for testing as well, it should be avoided that those are modified during `checkPhase`. This can happen if a package is built e.g. with special `cargoBuildFlags` that don't apply to the `checkPhase`. In that case, a binary would be installed into `$out` without those flags since `checkPhase` overrides the binary in the `target`-directory. This patch copies the state of `target/release` into a temporary location at the end of the `buildPhase` and installs the results from that temporary directory into `$out` while `checkPhase` can continue using the configured build-dir. cc NixOS#91689 Closes NixOS#93119 Closes NixOS#91191
ce73480
to
d2694d9
Compare
Sorry this turned into a mess and that I wasn't able to resolve it before it landed in master. Thanks for fixing it @Ma27. Hydra is quiet, might be worthwhile merging this to master so we aren't waiting for the next staging cycle? |
I don't think that it's a good idea to merge something with ~1000 rebuilds into @vcunat would it be possible to merge this into |
#91090 has been approved 2 days ago - I assume |
It's already in master, the PR has been recycled a couple of times. Currently |
Uh, in that case, If staging-next is empty, and this PR causes a big rebuild, shouldn't we merge it into staging, and then staging into staging-next? |
Let's let this cook a bit in staging, and spot breakages there. |
Motivation for this change
This PR fixes a bug originally described in #91191: if a package has a special
cargoBuildFlags
-declaration, the binaries in$out
aren't built with those since the artifacts intarget/release
get modified duringcheckPhase
which doesn't usecargoBuildFlags
.This change copies the artifacts after
buildPhase
into a temporary location, so that the proper binaries get installed into$out
andcargo test
can resume the build-process in thecheckPhase
.cc #91689
Closes #93119
Closes #91191
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)