Currently, the search path for .cargo/config files is dependent on the current working directory at the time when cargo is executed. I find this behavior very surprising: I would expect that cargo at least always reads the .cargo/config file at the root of the project it builds.
It is important to note though that for some applications, this is probably the right thing to do (for example, cargo new does not have any associated project root to work with).
$ cargo build --manifest-path foo/Cargo.toml # will not read foo/.cargo/config
$ cargo build -p foo # in a workspace with foo, will not read foo's .cargo/config
#[test]
fn search_config_relative_to_project_root() {
let foo = project("foo")
.file("Cargo.toml", r#"
[package]
name = "foo"
authors = []
version = "0.0.0"
build = "build.rs"
"#)
.file("src/lib.rs", "")
.file("build.rs", r#"
use std::env;
fn main() {
if env::var("NUM_JOBS").unwrap() == "5673" {
panic!("Config value `jobs` taken from config file located in working directory \
and not from the config file at foo's project root.");
}
if env::var("NUM_JOBS").unwrap() != "2423" {
panic!("Config value `jobs` not taken from config file located at foo's project root \
but config file in working directory was not read either.");
}
}
"#)
.file(".cargo/config", r#"
[build]
jobs = 2423
"#);
let bar = project("bar")
.file(".cargo/config", r#"
[build]
jobs = 5673
"#);
foo.build();
assert_that(bar.cargo_process("build")
.arg("--manifest-path").arg(foo.root().join("Cargo.toml")),
execs().with_status(0));
}
I agree, the config resolution should not be based on the current working directory, but starting at the project (where Cargo.toml is, i.e. manifest-path).
Most helpful comment
I agree, the config resolution should not be based on the current working directory, but starting at the project (where Cargo.toml is, i.e.
manifest-path).