Open 12101111 opened 2 years ago
The fingerprint that determines a rebuild is affected by several things. I guess at least the version info of invoked rustc
changed when switching to a super user, due to PATH
changed. That behaviour is expected because when across different version of rustc, we need to recompile.
The Cargo Book contains a whole paragraph about knowing the reason why a rebuild occurs. It's not comprehensive but usable for now. You could test it to help verify my assumption.
If I do want to avoid recompilation when sudo cargo
, I might set CARGO_HOME=/path/to/my/cargo/bin/dir
and then invoke cargo in order to control which rustc to be called. (I haven't tried it, though)
I find that the exa
case is not a fingerprint bug, but (maybe) a old bug of feature resolver v1.
I hack cargo
to print build plan when run cargo install
subcommand, and compare this output with build plan from cargo build -Z unstable-options --build-plan
The different is, in build plan of cargo install
, --cfg feature="extra_traits"
is enabled for libc
and --cfg feature="full"
is enabled for syn
, both of them is pulled by a dev-dependency ( nix
need extra_traits
feature of libc
, serial_test_derive
need full
feature of syn
)
So the rebuild is caused by behavior mismatch between cargo install
and cargo build
in feature resolver v1.
Hmm… interesting. Haven't tried out your new discovery, but I can reproduce the steps in the PR description and the example has no dependency, so these two might be different issues.
If you can set identical CARGO_HOME
or PATH
for the superuser account, the build should be fresh and won't trigger any re-build I guess (for the example in PR description).
It looks like this is using cargo install
without the --locked
option. cargo install
will by default ignore Cargo.lock, which is probably what you are seeing here.
For someone who encountered the same problem, here's a quick solution.
sudo env "CARGO_HOME=$HOME/.cargo" cargo build # or run or install
Problem
Users may want to install a rust binary crate to
/usr/local/bin
, not to$HOME/.cargo/bin
, and this can be archived by--root
flag ofcargo install
.And normal users don't have the permission to write
/usr/local/bin
directly, so they have to runsudo cargo install --root /usr/local
instead.The bug is here: when cargo is running as another user, it will recompile everything due to the environment change.
Steps
( Don't use
sudo cargo
directly when there is another system wide rust installation )Possible Solution(s)
cargo should detect this situation.
A fallback solution is adding a new flags like "install-only" that don't recompile no matter the environment is changed or not.
Notes
cmake & ninja won't recompile everything when run as root, so you can use
to install any cmake based project.
I first notice this issue when I compile some rust packages using Portage (gentoo's package manager).
Note that only a few crates is recompiled.
Version