Skip to content
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

The cargo build --bins re-builds binaries again after cargo build --all-targets #13844

Open
achary opened this issue May 2, 2024 · 2 comments
Labels
A-features Area: features — conditional compilation A-workspaces Area: workspaces C-bug Category: bug S-needs-info Status: Needs more info, such as a reproduction or more background for a feature request.

Comments

@achary
Copy link

achary commented May 2, 2024

Problem

There seem to be unnecessary build happening in the following sequence.

cargo build --release --all-targets
cargo build --release --bins

Not sure that his matters, but my setup uses workspace.

Steps

  1. Run cargo build --release --all-targets
  2. Immediately after run cargo build --release --bins

At step 2. I would expect getting just a "Finished" message straight away, with no re-build happening in between steps 1. and 2., as the --all-targets conceptually include building full set of binary executables already.

Possible Solution(s)

No response

Notes

No response

Version

rustc 1.77.1
cargo 1.77.1 (e52e36006 2024-03-26)
@achary achary added C-bug Category: bug S-triage Status: This issue is waiting on initial triage. labels May 2, 2024
@epage
Copy link
Contributor

epage commented May 2, 2024

To know more, we'd need a reproduction case.

I'm assuming whats happening is --all-targets is causing your dev-dependencies to be included in the build graph. These dev-dependencies may be activating features on your dependencies that weren't activated otherwise, causing a rebuild. This is roughly the same issue as #11954 and related issues are #4463 and #8157.

@epage epage added A-features Area: features — conditional compilation A-workspaces Area: workspaces labels May 2, 2024
@weihanglo weihanglo added S-needs-info Status: Needs more info, such as a reproduction or more background for a feature request. and removed S-triage Status: This issue is waiting on initial triage. labels May 3, 2024
@ia0
Copy link

ia0 commented May 18, 2024

Is there a way to make cargo check --lib --tests behave the same as running cargo check --lib && cargo check --tests?

Context I used to run cargo check --all-targets thinking I would check all my targets with an implicit assumption that this would be equivalent to running cargo check <target> for each target. I realized today that this is not the case because of feature unification (even with resolver 2) and found this issue which seems to be exactly that. I'm wondering if I should simply run cargo check and cargo check --tests independently (the latter is subsumed by cargo test so maybe I should just defer it until I run cargo test) or if there is a way to invoke a single cargo execution to check both targets.

EDIT: This is probably more relevant with cargo clippy --all-targets, because it's not subsumed by cargo test.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-features Area: features — conditional compilation A-workspaces Area: workspaces C-bug Category: bug S-needs-info Status: Needs more info, such as a reproduction or more background for a feature request.
Projects
None yet
Development

No branches or pull requests

4 participants