Place artifacts of the default target into a subdirectory of ./target

[huonw]

We currently have cargo build putting things in ./target and cargo build --release putting them in ./target/release. This leads to confusion, and could be improved by instead building everything to a subdirectory, e.g. ./target/debug for the default target.

(It occurs to me that the current scheme could fail catastrophically if a binary was called release.)

[alexcrichton]

Hm, the name would probably be dev to match the profile but no matter what I think this could lead to confusion. If all the output goes into dev, then why does --bench go in release and not bench? Also, why do examples go in examples instead of dev/examples?

I would also suspect that if you hit compile and nothing but folders appears in target that some may also get confused. It's useful knowing that your exact output is in target/ directly with a vanilla cargo build.

I do agree though that things will go real bad real fast if you call your project something like native, examples, release, x86_64-unknown-linux-gnu, etc.

[matthieu-m]

And what about generating a symlink/shortcut in the "target/" folder pointing to the latest binary/library generated?

This way, the output is consistent (always to its own profile), and the symlink/shortcut only fails if your artifact name happens to match an already existing directory which is not the end of the world since you can always get to the artifact itself rather than using the link.

[huonw]

What do other tools/projects do? I know that LLVM outputs binaries & libs to directories like Release+Asserts etc.

It's useful knowing that your exact output is in target/ directly with a vanilla cargo build.

Knowing that your exact output is in target/dev doesn't seem particularly different. shrug

If all the output goes into dev, then why does --bench go in release and not bench? Also, why do examples go in examples instead of dev/examples?

Why can't they be moved too?

[alexcrichton]

I know that LLVM outputs binaries & libs to directories like Release+Asserts etc.

Good point!

Why can't they be moved too?

Hm I suppose they could, I'm a little wary of burying them super deep in directories though.

@wycats, do you have any thoughts here?

And what about generating a symlink/shortcut in the "target/" folder pointing to the latest binary/library generated?

Windows, while supporting symlinks recently, is a reason in the past that we've avoided using symlinks for any sort of critical infrastructure for Cargo.

[wycats]

I think @carllerche wants release artifacts moved into a target-triple-namespaced directory in target to enable parallel builds using Vagrant.

[wycats]

Windows, while supporting symlinks recently, is a reason in the past that we've avoided using symlinks for any sort of critical infrastructure for Cargo.

We've gone through this recently in great detail in Ember CLI. @stefanpenner can possibly say more.

[stefanpenner]

our current solution + ideas -> broccolijs/node-symlink-or-copy#1

I can provide mode details if needed

/cc @rwjblue

[lahwran]

just wanted to point out that cargo could simply print the relative path of the binary it wrote, and then a whole class of confusion is avoided.