You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## What does this PR try to resolve?
This PR adds a new `build.build-dir` configuration option that was
proposed in
#14125 (comment)
This new config option allows the user to specify a directory where
intermediate build artifacts should be stored.
I have shortened it to just `build-dir` from `target-build-dir`,
although naming is still subject to change.
### What is a final artifact vs an intermediate build artifact
#### Final artifacts
These are the files that end users will typically want to access
directly or indirectly via a third party tool.
* binary executable for bin crates
* binary executable for examples
* `.crate` files output from `cargo package`
* [depinfo
files](https://doc.rust-lang.org/cargo/reference/build-cache.html#dep-info-files)
(`.d` files) for third party build-system integrations (see
https://github.com/rust-lang/cargo/blob/master/src/cargo/core/compiler/fingerprint/mod.rs#L194)
* `cargo doc` output (html/css/js/etc)
* Cargo's
[`--timings`](https://doc.rust-lang.org/cargo/reference/timings.html)
HTML report
#### Intermediate build artifact, caches, and state
These are files that are used internally by Cargo/Rustc during the build
process
* other depinfo files (generated by rustc, fingerprint, etc. See
https://github.com/rust-lang/cargo/blob/master/src/cargo/core/compiler/fingerprint/mod.rs#L164)
* rlibs and debug info from dependencies
* build script `OUT_DIR`
* output from proc macros (previously stored in `target/build`)
* [incremental
build](https://doc.rust-lang.org/rustc/codegen-options/index.html#incremental)
output from rustc
* fingerprint files used by Cargo for rebuild detection
* scratchpad used for `cargo package` verify step
* Cache of rustc invocations (`.rustc_info.json`)
* "pre and non uplifted" binary executables. (ie. bins for `examples`
that contain the hash in the name, bins for `benches`, proc macros,
build scripts)
* `CARGO_TARGET_TMPDIR` files (see rational for this
[here](#14125 (comment)))
*
[future-incompat-report](https://doc.rust-lang.org/cargo/reference/future-incompat-report.html)'s
`.future-incompat-report.json` file
## Feature Gating Strategy
We are following the "Ignore the feature that is used without a gate"
approach as described
[here](https://doc.rust-lang.org/nightly/nightly-rustc/cargo/core/features/index.html).
The rational for this is:
The `build.build-dir` is likely going to be set by by users "globally"
(ie. `$CARGO_HOME/config.toml`) to set a shared build directory to
reduce rebuilding dependencies. For users that multiple cargo versions
having having an error would be disrupted.
The fallback behavior is to revert to the behavior of the current stable
release (building in `$CARGO_TARGET_DIR`)
## Testing Strategy
* We have the existing Cargo testsuite to be sure we do not introduce
regressions.
* I have also run the testsuite locally with the cli flag remove to
verify all tests pass with the default build dir (which falls back to
the target dir)
* For testing thus far, I have been using small hello world project with
a few dependencies like `rand` to verify files are being output to the
correct directory.
* When this PR is closer to merging, I plan to test with some larger
projects with more dependencies, build scripts, ect.
* Other testing recommendations are welcome 🙇
## How should we test and review this PR?
This is probably best reviewed commit by commit. I documented each
commit.
I tied to follow the atomic commits recommendation in the Cargo
contributors guide, but I split out some commits for ease of review.
(Otherwise I think this would have ended up being 1 or 2 large commits
😅)
## Questions
- [x] What is the expected behavior of `cargo clean`?
* At the time of writing it only cleans `target` and does not impact the
build-dir but this is easily changable.
* Answer: See
#15104 (comment)
- [x] When using `cargo package` are was expecting just the `.crate`
file to be in `target` while all other output be stored in
`build.build-dir`? Not sure if we consider things like `Cargo.toml`, `
Cargo.toml.orig`, `.cargo_vcs_info.json` part of the user facing
interface.
* Current consensus is that only `.crate` is considered a final artifact
- [x] Where should `cargo doc` output go? HTML/JS for many crates can be
pretty large. Moving to the build-dir would help reduce duplication if
we find the that acceptable. For `cargo doc --open` this is not a
problem but may be problematic for other use cases?
* Answer:
#15104 (comment)
- [x] Are bins generated from `benches` considered final artifacts?
* Since bins from `examples` are considered final artifacts, it seems
natural that `benches` should also be considered final artifacts.
However, unlike `examples` the `benches` bins are stored in
`target/{profile}/deps` instead of a dedicated directory (like
`target/{profile}/examples`). We could move them into a dedicated
directory (`target/{profile}/benches`) but that mean would also be
changing the structure of the `target` directory which feels out of
scope for this change. If we decide that `benches` are final artifacts,
it would probably be better to consider that changes as part of
#6790
* Answer:
#15104 (comment)
- [ ] [Do we want to include a `CARGO_BUILD_DIR` shortcut env
var?](#15104 (comment))
* The current commit (2af0c91) has
included the `CARGO_BUILD_DIR` shortcut. This can be removed before
merging if there a good reason to.
## TODO
- Implementation
- [x] Add support in `cargo clean`
- [ ] ~~Implement templating for `build.build-dir`~~
* Will implement in a follow up PR [as
suggested](#15104 (comment))
- [x] Fix issue with `target/examples` still containing "pre-uplifted"
binaries
- [x] Verify `build-dir` with non-bin crate types
- Prepare for review
- [x] Clean up/improve docs
- [x] Review tests and add more as needed
- [x] Fix tests in CI (Windows is currently failing)
- [x] Clean up commits
- [ ] Resolve remaining questions
- [x] Request review
0 commit comments