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

Allow specifying a custom output directory #1657

Merged
merged 2 commits into from Jun 4, 2015

Conversation

alexcrichton
Copy link
Member

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 (Concurrent usage of cargo will generally 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

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 (rust-lang#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 rust-lang#482
@rust-highfive
Copy link

r? @huonw

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

@alexcrichton
Copy link
Member Author

r? @wycats

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

@rust-highfive rust-highfive assigned wycats and unassigned huonw May 28, 2015
@metajack
Copy link

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

@alexcrichton
Copy link
Member Author

@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
Copy link

@alexcrichton thank you very much!

@huonw
Copy link
Member

huonw commented May 29, 2015

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
Copy link
Member Author

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
Copy link
Member

huonw commented May 29, 2015

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

@huonw
Copy link
Member

huonw commented May 29, 2015

(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
Copy link
Member Author

r? @brson

@rust-highfive rust-highfive assigned brson and unassigned wycats Jun 4, 2015
@brson
Copy link
Contributor

brson commented Jun 4, 2015

@bors r+

@bors
Copy link
Collaborator

bors commented Jun 4, 2015

📌 Commit 014765f has been approved by brson

@bors
Copy link
Collaborator

bors commented Jun 4, 2015

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

bors added a commit that referenced this pull request Jun 4, 2015
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
@bors
Copy link
Collaborator

bors commented Jun 4, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Sharing target directories
9 participants