cargo build --out-dir

[matklad]

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

[alexcrichton]

Looks good to me! Technically new features start unstable but I'd be ok having this start out as a stable option

[bors]

☔ The latest upstream changes (presumably #5232) made this pull request unmergeable. Please resolve the merge conflicts.

[matklad]

cc @sfackler, I think this should allow you to avoid --message-format=json.

[matklad]

Featuregated, cleanedup and added more tests! Should be ready for review now, although mac tests would probably fail because I don't have a mac machine nearby :-)

[matklad]

Hopefully the mac tests should be fixed now as well!

[alexcrichton]

@bors: r+

Nice!

[bors]

📌 Commit c919118 has been approved by alexcrichton

[bors]

⌛ Testing commit c919118 with merge f082805...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing f082805 to master...

[epage]

Is this flag made available to build scripts so that we can get completions and other generated files into this directory? I'm coming at this from the packaging angle.

[matklad]

No, it is not exposed to build scripts. Moreover, it seems to me that it is wrong for build scripts to do anything packaging related, because packaging should happen after the code is build, and not before.

Regarding packaging in general, I think we need a more elaborate solution here. I expect that packaging is an open-ended task: you want completions for linux, you want to sign your binaries for mac and windows, and you might want to run some kind of assets managing pipeline for complex web/multimedia applications.

So, at this moment, I would say that packaging should be done completely outside of Cargo. I.e, a Makefile could be written, which calls cargo with --output-dir to build the raw binaries, and then does arbitrary stuff to "package" an application, whatever it means. If you don't want to write platform-specific makefiles/shell scripts, you kinda can use arbitrary rust code for that: create a package-app binary at src/bin/package-app.rs, write packaging logic in Rust, and invoke it as cargo run --bin package-app. The latter hack would probably become more official with workflows.

[epage]

Sorry, I wasn't clear. Packaging is happening outside of cargo. I was more referring to making all build artifacts intended to be packaged in an easily identifiable location.

[matklad]

So, --output-dir is indeed intended to make all build artifacts, produced by Cargo, available to the outside world. However, the set of artifacts, produced by Cargo, is determined by the crate type and is not extensible.

In particular, it is not possible (in theory) to make a build script, which produces some additional artifacts, like man pages and completions, and puts them somewhere in the target/output dir. In practice of course you can do anything in the build scripts, it just may not work in some circumstances, and might break if we change implementation details of Cargo :-)

So, sure, --output-dir is intended for packaging as well, but generating completions via build.rs is probably not what you want to do, and it is orthogonal to --output-dir I would think.