Add -C <DIR> flag to cargo to change directory before invoking
#10098
Comments
lilyball
added
the
C-feature-request
|
This request was inspired by my surprised at |
|
Yeah, I hit this issue too. I think ideally |
ehuss
added
A-cli
|
I believe that @joshtriplett have brought this up at cargo meetings before, but I cannot find notes at this time. |
|
Ran into this today as well, let me just echo that it's pretty unfortunate that using Potentially this might not be breaking, because anyone depending on the current behavior would have to be building from the root of the project anyway. |
|
At this point, I think that the current behavior of |
This is contrary to the cargo config documentation, which says:
the per-package .cargo/config.toml checked into version control is being ignored when built via |
|
btw #2930 is the issue about the config being relative to CWD rather than
I could see there being some minor wording tweaks to the documentation. My guess is its written assuming auto-discovery of the manifest in which case, it is correct. That assumption should be made more clear though. |
Cargo documentation for configuration toml says that a .cargo/config checked into revision control in the project root should be picked up by cargo, but in fact cargo only searches relative to cwd. In order to achieve the documented result, cargo needs to be invoked with the current working directory already set to the directory containing the manifest file. see rust-lang/cargo#10098
This implements the suggestion in rust-lang#10098 to make cargo change cwd before completing config processing and starting the build. It is also an alternative to --manifest-path that resolves the issue described in rust-lang#2930.
This implements the suggestion in rust-lang#10098 to make cargo change cwd before completing config processing and starting the build. It is also an alternative to --manifest-path that resolves the issue described in rust-lang#2930.
This implements the suggestion in rust-lang#10098 to make cargo change cwd before completing config processing and starting the build. It is also an alternative to --manifest-path that resolves the issue described in rust-lang#2930.
This implements the suggestion in rust-lang#10098 to make cargo change cwd before completing config processing and starting the build. It is also an alternative to --manifest-path that resolves the issue described in rust-lang#2930.
This implements the suggestion in rust-lang#10098 to make cargo change cwd before completing config processing and starting the build. It is also an alternative to --manifest-path that resolves the issue described in rust-lang#2930.
This implements the suggestion in rust-lang#10098 to make cargo change cwd before completing config processing and starting the build. It is also an alternative to --manifest-path that resolves the issue described in rust-lang#2930.
This implements the suggestion in rust-lang#10098 to make cargo change cwd before completing config processing and starting the build. It is also an alternative to --manifest-path that resolves the issue described in rust-lang#2930.
This implements the suggestion in rust-lang#10098 to make cargo change cwd before completing config processing and starting the build. It is also an alternative to --manifest-path that resolves the issue described in rust-lang#2930.
This implements the suggestion in rust-lang#10098 to make cargo change cwd before completing config processing and starting the build. It is also an alternative to --manifest-path that resolves the issue described in rust-lang#2930.
This implements the suggestion in rust-lang#10098 to make cargo change cwd before completing config processing and starting the build. It is also an alternative to --manifest-path that resolves the issue described in rust-lang#2930.
This implements the suggestion in rust-lang#10098 to make cargo change cwd before completing config processing and starting the build. It is also an alternative to --manifest-path that resolves the issue described in rust-lang#2930.
This implements the suggestion in rust-lang#10098 to make cargo change cwd before completing config processing and starting the build. It is also an alternative to --manifest-path that resolves the issue described in rust-lang#2930.
This implements the suggestion in rust-lang#10098 to make cargo change cwd before completing config processing and starting the build. It is also an alternative to --manifest-path that resolves the issue described in rust-lang#2930.
|
Reopening since in #11960 we are planning to mark -C as unstable for now. |
Problem
Cargo infers the manifest path and reads config based on the current directory. Plugins may potentially locate other config this same way. Cargo commands offer a
--manifest-pathflag to override the manifest, but this doesn't override config.For example, given the following:
The resulting build will use the host platform instead of
wasm32-unknown-unknownand the build artifacts will end up inbin/foo/target. But were I to runcd bin/foo && cargo buildit would use the correct target and target dir.Proposed Solution
Cargo should have a flag
-C <DIR>(or--directory <DIR>) that exists at the top level rather than in the subcommands. This flag would causecargoto change its working directory to the specified one before processing any commands or loading any config. It would be roughly equivalent to( cd <DIR> && cargo … ).Besides fixing the issue of loading cargo config, this is also a simpler interface for end users than
--manifest-pathas it means they don't have to worry about where the specificCargo.tomlfile is, they can just runcargoas though it were in a specific directory.This flag is inspired by both
makeandgitwhich offer the same-C <DIR>(makehas the long--directoryform, I don't believegithas a long form). The desired behavior here should be based ongitas it also defines how multiple-Cflags interact (subsequent ones are interpreted relative to the earlier ones). Likegit, any other flags or parameters that take relative paths should then be interpreted relative to the working directory caused by the-Coption.Notes
Regarding rustup and
rust-toolchain.tomloverrides, I'm inclined to say rustup should honor this flag as well and interpret it prior to locating an override file. The idea here is that sayingcargo -C $path …should behave indistinguishably from runningcargowithin that path.The text was updated successfully, but these errors were encountered: