`--artifact-dir` (nee `--out-dir`) Tracking Issue

[ehuss]

Note: this was renamed from --out-dir to --artifact-dir in #13809

Original issue: #4875
Implementation PR: #5203
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#artifact-dir
Issues: Z-out-dir Nightly: --out-dir

Summary
Adds --artifact-dir=PATH flag to cargo build to specify a directory to place final artifacts.

Tasks:

• cargo build --out-dir #5203
• Rename --out-dir to --artifact-dir #13809
• Remove --out-dir

Unresolved questions

• Multi-target builds (--target <one> --target <two>)
• MSVC examples cannot be exported with out-dir #7493
• Is --out-dir justified or can we find another way of accomplishing it? #6100 — concern about similarity with --target-dir, proliferation of flags
• Duplicate artifact tracking issue. #6313 — concern about name collisions in workspaces or with examples
• What exactly is the use case for this? In what scenario would it be used where you don't already have an outer build system or script that can copy the files into the correct location?
• Confusion with rustc's --out-dir (Rename --out-dir to --artifact-dir #13809)
• Discrepancy or confusion with build.rss OUT_DIR (depends on if build.rs is generating intermediate or final artifacts) (Rename --out-dir to --artifact-dir #13809)

[ultrasaurus]

I find this feature very helpful, since I get output in a directory named like this ./target/debug/build/mylib-79d5eadf36eadf53 and with a build.rs file there are two similarly named directories.

However, it doesn't seem that OUT_DIR environment variable is set to the value of --out-dir when build.rs is executed. Is that intentional? is there some other way to discover the value of --out-dir?

[haze]

+1 on this issue. I have a program that uses a template directory for rust compilation and would like to now have to recompile everything. Yes I could symlink all the folders within target, but it would be nicer to be able to specify the binary output path. I'm not sure why this is such an overlooked issue.

[robinbudd]

When will this feature be available in the stable release? It would greatly simplify my build/CI pipeline.

[Chris--B]

+1 on this. This greatly improves the workflow on our CI, and we'd like to avoid using a nightly compiler just for this.

What needs to happen for this to move forward?

[lf-]

This issue makes nmattia/naersk unusable on stable rust. (another build system issue)

[golddranks]

This would streamline some of my Dockerfiles and build scripts quite nicely.

[Diggsey]

Is there a reason this doesn't work with cargo rustc?

[benesch]

I just published a crate called cargo-out-dir to crates.io, which can ease some of the frustration while we wait for this to stabilize. All it does is print out the current' crate's out directory, as determined by running cargo check --metadata-format=json:

$ cargo install cargo-out-dir
$ cargo out-dir
/home/benesch/path/to/crate/target/debug/build/foo-9d9f15d3d084bc3a/out

[simonbuchan]

Another potential use case for out-dir is making cargo run work nicely with building MacOS apps, which expect a structure like:

My App.app/Contents/
  Info.plist
  MacOS/actual-binary
  Resources/foo.png

in order for native APIs like (the moral equivalent of) [NSImage imageNamed: @"foo"] to work.

But in this case it would be more helpful to be able to put out-dir = "dist/My App.app/Contents/MacOS" in Cargo.toml somewhere, presumably in the [bin] section. Not sure if that makes anyone more or less happy?