-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Closed
Labels
C-bugCategory: bugCategory: bug
Description
Problem
cargo rebuilds things if I switch between cargo build
and cargo build --workspace
.
Steps
git clone https://salsa.debian.org/iwj/otter
cd otter
git checkout c9b5a88d7a33a6e1eac22736be0a38c6815e1706
cargo build --workspace
cargo build
To repeat, restarting from after step 4 or 5:
touch src/updates.rs
- as above
- as above
Expected behaviour
The whole workspace including the toplevel package otter
was built in step 4, so step 5 should not build anything and should be very quick.
Actual behaviour
cargo rebuilds otter
(including library and binaries) in step 5 (about six seconds on my laptop in a repeated test)
Notes
Output of cargo version
:
cargo 1.51.0-nightly (783bc43c6 2021-01-20)
Metadata
Metadata
Assignees
Labels
C-bugCategory: bugCategory: bug
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
ijackson commentedon Jan 30, 2021
@rustbot modify labels +A-rebuild-detection +A-workspaces
rustbot commentedon Jan 30, 2021
Error: The feature
relabel
is not enabled in this repository.To enable it add its section in the
triagebot.toml
in the root of the repository.Please let
@rust-lang/release
know if you're having trouble with this bot.ijackson commentedon Jan 30, 2021
I have been attempting to work around this and the behaviours I'm seeing make me think it may be related to #4463.
ijackson commentedon Jan 30, 2021
A workaround in my environment is to always pass
--workspace
(plus, usually, suitable-p
options) to cargo.ehuss commentedon Jan 31, 2021
Yea, this is expected behavior in that the features chosen depend on which packages are being built. Closing as a duplicate of #4463.
There are other workarounds such as a common package that forces the same features (see rustc-workspace-hack as an example).
Auto merge of #11498 - dtolnay-contrib:relabel, r=ehuss