Move target_dir to Workspace and fix #2848
#2912
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
While it is generally terrible to silently ignore errors in the configuration files, it is acceptable in this case. Verbosity and color config have reasonable defaults, and we don't want to fail for simple commands like `cargo --version` just because of the garbage in the config file. fixed rust-lang#2848
|
(rust_highfive has picked a reviewer for you, use r? to override) |
bors
added a commit
that referenced
this pull request
Jul 25, 2016
Move `target_dir` to Workspace and fix #2848 Target dir is now an API of Workspace. It is still initialized eagerly, just later. I also had to errors in the config file when retrieving `verbose` and `color` config. Seems fishy, but is probably OK.
|
☀️ Test successful - cargo-cross-linux, cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64 |
github-merge-queue bot
pushed a commit
that referenced
this pull request
Aug 12, 2025
### What does this PR try to resolve? While preparing to stabilize `build-dir`, [it was discovered](#14125 (comment)) that `cargo package` will sometimes use the build cache for dependency crates if `CARGO_TARGET_DIR` is explicitly set. If target-dir is not set, the build will be preformed in an "inner target dir" at `target/package/{name}-{version}/target` and rebuild everything. This PR changes the default behavior to always use the build cache, matching the behavior of having `target-dir` set. ### How to test and review this PR? Added a dedicated test to verify the previous behavior (cargo recompiled non-workspace crates) in the first commit. Then updated it to verify the new behavior. ### Related links/notes * I did some Git archaeology and I _think_ this behavior was introduced in #2912 * While searching through the commit/pr history was never able to find any explicit reason why the behavior is the way it is. * Even if it was intentional, it has been 9 years since and Cargo's fingerprinting/rebuild detection is much more mature now so I believe its worth revisiting if this is still the desired behavior. * Would help mitigate #14941
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Target dir is now an API of Workspace. It is still initialized eagerly, just later.
I also had to errors in the config file when retrieving
verboseandcolorconfig. Seems fishy, but is probably OK.