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
I'd like to suggest that we should add --output-path option 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=json and 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:
Cargo should still put all stuff into target as usual, --output-path is only a copy at the end
The flag works only when the build produces a single artifact. That is, you'll need --bin name sort flags for disambiguation.
The flag definitely should work for cdylib, clib and bin crate types. Not sure if we'd want to support rlibs.
It's not clear what to do with extensions. Do we add .exe on windows automatically? Or do we use the path as-is? I think the letter is preferable.
It's not clear what to do if the artifact consists of several files (i.e, debug info on Macs is in a separate file). Should we just place it alongside? Should we add more config?
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
Hi!
I'd like to suggest that we should add
--output-path
option 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=json
and 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:
target
as usual,--output-path
is only a copy at the end--bin name
sort flags for disambiguation.cdylib
,clib
andbin
crate types. Not sure if we'd want to support rlibs..exe
on 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: