Ability to specify output artifact name #4875
Labels
C-feature-request
Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`
Comments
alexcrichton
added
the
C-feature-request
Merged
bors
added a commit
that referenced
this issue
Apr 3, 2018
cargo build --out-dir This is intended to fix #4875. Very much work in progress, just to figure out how exactly `--out-dir` should work :) The path of least resistance for implementing `out-dir` would be to just link everything from `target/debug` to the `out-dir`. However, the problem with this approach is that we link *too much* to the `target/debug`. For example, if you run `cargo build --bin foo`, you'll find not only the `foo` itself there, but also rlibs from the same workspace. I think it's rather important not to copy extra stuff to out-dir, so it is implemented as a completely new parameter, which is threaded through various config structs and applies *only* to the top-level units (i.e, to the stuff user explicitly requested to compile on the command line). I also plan to add platform specific tests here, to check that we get .pdb on windows and .dSYM on macs for various crate-types. Because, in general, a single target may produce multiple files, `out-dir` has to be a directory, you can't directly specify the output *file*. Note that artifacts are still generated to the `target` dir as well. Also cc @nirbheek, I hope that this might be useful for Meson integration, because `--out-dir` should be more straightforward to use than `--message-format=json`. The end result, for `cargo build --bin rustraytracer --out-dir out` on windows looks like this:  Note how we have fewer files in the `out` :) r? @alexcrichton
10 tasks
bors
added a commit
that referenced
this issue
Jun 7, 2024
Rename --out-dir to --artifact-dir Progress towards unblocking #6790. Renames the experimental `--out-dir` argument to `--artifact-dir`, both to reflect that it's where the final build *artifacts* will be copied to, and to avoid confusion with the `OUT_DIR` environment variable which serves an entirely different purpose. For transition purposes, `--out-dir` argument and `out-dir` config key will still work with a deprecation message encouraging the use of the new arg and config key. ### Rationale A lot of people seem to be confused by the naming of the `--out-dir` argument, and are misled into thinking it serves the same purpose as the `OUT_DIR` environment variable: > [However, it doesn't seem that OUT_DIR environment variable is set to the value of --out-dir when build.rs is executed.](#6790 (comment)) > [I understand that the worry is that there could be confusion between --out-dir for cargo and the environment variable OUT_DIR for build.rs, but doesn't it mean exactly the same in both cases?](#6790 (comment)) > [--out-dir: Things will be built into $PWD/target as normal, but copies some of the artifacts into the directory specified by out-dir (not a profile specific subdirectory). Unstable flag, added in March 2018. cargo build --out-dir #5203 Ability to specify output artifact name #4875. **Mimicks the behavior of OUT_DIR.**](#6100 (comment)) > [I recently had a couple of people express an interest in --out-dir being stabilized and from my initial digging it seems like what they may actually want is to switch to OUT_DIR, which is already stable.](#6100 (comment))
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi!
I'd like to suggest that we should add
--output-pathoption to certain Cargo commands, to make it easier to use Cargo as a part of the larger build system.Currently, the way to get output artifacts location is to run
cargo build --message-format=jsonand parse the resulting JSON. This is very convenient if you want to "enhance" the stuff that Cargo does. For example, IntelliJ Rust uses this feature to learn what binaries it should launch via debugger.However, this does not work well for the case where you use Cargo as a part of larger build, and are interested only in the artifact. The main drawback here is that parsing the JSON is not that easy.
Here some implementation considerations:
targetas usual,--output-pathis only a copy at the end--bin namesort flags for disambiguation.cdylib,clibandbincrate types. Not sure if we'd want to support rlibs..exeon windows automatically? Or do we use the path as-is? I think the letter is preferable.Issue inspired by this discussion on Gitter: https://gitter.im/rust-lang/rust?at=5a468c4b0163b028108fe9b6
The text was updated successfully, but these errors were encountered: