Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to specify output artifact name #4875

Closed
matklad opened this issue Dec 29, 2017 · 0 comments · Fixed by #5203
Closed

Ability to specify output artifact name #4875

matklad opened this issue Dec 29, 2017 · 0 comments · Fixed by #5203
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`

Comments

@matklad
Copy link
Member

matklad commented Dec 29, 2017

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:

  • 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?

Issue inspired by this discussion on Gitter: https://gitter.im/rust-lang/rust?at=5a468c4b0163b028108fe9b6

@alexcrichton alexcrichton added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label Jan 2, 2018
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:

![image](https://user-images.githubusercontent.com/1711539/37605115-941c0b22-2ba3-11e8-9685-9756a10fdfac.png)

Note how we have fewer files in the `out` :)

r? @alexcrichton
@bors bors closed this as completed in #5203 Apr 3, 2018
@ehuss ehuss mentioned this issue Mar 28, 2019
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants