Allow specifying a custom output directory

[alexcrichton]

This commit adds support to allow specifying a custom output directory to Cargo.
First, the build.target-dir configuration key is checked, and failing that the
CARGO_TARGET_DIR environment variable is checked, and failing that the root
package's directory joined with the directory name "target" is used.

There are a few caveats to switching target directories, however:

• If the target directory is in the current source tree, and the folder name is
  not called "target", then Cargo may walk the output directory when determining
  whether a tree is fresh.
• If the target directory is not called "target", then Cargo may look inside it
  currently for Cargo.toml files to learn about local packages.
• Concurrent usage of Cargo will still result in badness (#354), and this is now
  exascerbated because many Cargo projects can share the same output directory.
• The top-level crate is not cached for future compilations, so if a crate is
  built into directory foo and then that crate is later used as a dependency,
  it will be recompiled.

The naming limitations can be overcome in time, but for now it greatly
simplifies the crawling routines and shouldn't have much of a negative impact
other than some Cargo runtimes (which can in turn be negated by following the
"target" name convention).

Closes #482

[rust-highfive]

r? @huonw

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

r? @wycats

cc @larsbergstrom, @metajack, I believe you guys have wanted this in Servo for some time now

[metajack]

Am I correct that this is a solution for target directory sharing?

[alexcrichton]

@metajack yeah, I would expect Servo to check in a top-level .cargo/config which specifies the target directory, and then all sub-projects will share that target directory.

Alternatively Servo's build system would set the CARGO_TARGET_DIR environment variable for all Cargo invocations.

[larsbergstrom]

@alexcrichton thank you very much!

[huonw]

yeah, I would expect Servo to check in a top-level .cargo/config which specifies the target directory, and then all sub-projects will share that target directory.

Hm, doesn't checking in .cargo/config play slightly badly with overrides? (i.e. one would very rarely want to check in/publish a local override.)

[alexcrichton]

Right, but .cargo/config can be located at any point in a project hierarchy, so I would expect that overrides wouldn't be placed in servo/.cargo/config but rather a more specific location.

[huonw]

For servo it's probably OK, I'm more thinking about this as a general footgun.

[huonw]

(I don't really have anything concrete to offer to fix/mitigate it, and have no idea if it'll be a problem in practice.)

[alexcrichton]

r? @brson

[brson]

@bors r+

[bors]

📌 Commit 014765f has been approved by brson

[bors]

⌛️ Testing commit 014765f with merge 3b16446...

[bors]

☀️ Test successful - cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64

[gentoo90]

@alexcrichton, could you add 0.3.0 tag to this commit in git?