Cargo needlessly(?) rebuilds dependencies

[NfNitLoop]

Cargo seems to be having a problem with a few of my dependencies (error-chain, and its dependencies, backtrace and cpp_demangle). Every time I run cargo build or run, it rebuilds them.

$ cat Cargo.toml 
[package]
name = "sample_project"
version = "0.1.0"

[dependencies]
error-chain = "*"

$ cat src/main.rs 

fn main() {
    println!("Hello, world!");
}

$ cargo build
   Compiling cpp_demangle v0.2.1
   Compiling backtrace v0.3.1
   Compiling error-chain v0.10.0
   Compiling sample_project v0.1.0 (file:///Users/codyc/programs/rust/sample_project)
    Finished dev [unoptimized + debuginfo] target(s) in 6.68 secs

$ cargo build # Everything *should* be cached?
   Compiling cpp_demangle v0.2.1
   Compiling backtrace v0.3.1
   Compiling error-chain v0.10.0
   Compiling sample_project v0.1.0 (file:///Users/codyc/programs/rust/sample_project)
    Finished dev [unoptimized + debuginfo] target(s) in 6.61 secs

Hmm... I'm just realizing that if these the only libraries that that's happening for, it might be an issue with one of those libraries in particular, and not Cargo? I don't know enough about the cargo build process to know how to track that down, though.

[crumblingstatue]

If I comment out println!("cargo:rerun-if-changed=in/*"); in cpp_demangle, it doesn't rebuild every time anymore.

1. Are globs valid in this context? Answer: No
2. If they aren't, shouldn't cargo throw an error instead of behaving weirdly like this?

This is definitely a bug in cpp_demangle.

Whether it's also a Cargo bug is yet to be decided, but I suspect it shouldn't rerun if the dependency is consistently nonexistent.

[crumblingstatue]

Here is a test case for cargo always rerunning on a non-existent rerun dependency:

Cargo.toml:

[package]
name = "foo"
build = "build.rs"
version = "0.0.1"

build.rs:

fn main() {
	println!("cargo:rerun-if-changed=idontexist");
}

main.rs:

fn main() {}

[alexcrichton]

Ah yeah I believe that this basically boils down to gimli-rs/cpp_demangle#79 in the sense that it's not a bug in Carog, but rather a bug in the build script in question.

[crumblingstatue]

Ah yeah I believe that this basically boils down to gimli-rs/cpp_demangle#79 in the sense that it's not a bug in Carog, but rather a bug in the build script in question.

Just to make sure: You're saying it's acceptable behavior that Cargo always reruns for rerun-if-changed targets that don't exist.

[NfNitLoop]

@crumblingstatue That makes sense to me. (ex: If a file used to exist, and was deleted, it makes sense to redo the build. Maybe the build creates it?)

It's also unfortunate that * can be a valid character in a file name (if you're a masochist) so you can't unambiguously detect someone trying to use a glob and tell them that it's an error.

Maybe cargo check could have an extra check added to make sure that your build is cacheable? That's a separate issue/feature-request though, let's not go down that road here. 😄

Thanks for finding and linking the root cause, Alex!

[crumblingstatue]

@NfNitLoop Got it, thanks!

[inferiorhumanorgans]

@alexcrichton Double quotes are treated literally which means that cargo goes looking for filenames with quotes in them. While valid to use in a filename, I suspect it's extremely rare for this to happen intentionally in the wild.

[alexcrichton]

@inferiorhumanorgans true, but the quotes can be omitted?

[inferiorhumanorgans]

@alexcrichton Well, yes. But that's not intuitive behavior.

[chachi]

Old issue, but I just stumbled upon the "double quotes being considered part of the filename" behavior by doing println!("cargo:rerun-if-changed={:?}", &bindings_file); instead of using "...={}", &bindings_file); and it was rather surprising.

+1 for some sort of warning about missing files or strange filenames like this or unintentionally containing *.