Build Script rerun determination not transitive.

[Parakleta]

Without the rerun-if-changed setting a build script will automatically be rerun if anything in the crate tree has changed. However, this test is not performed by crates that depend on this crate.

The situation I have is an application that depends on a library where I am developing both together. If I change a file used by the build.rs in the library the application will not automatically rebuild unless I also touch the build.rs file. If I add the rerun-if-changed output in the library build script then the rebuild occurs in the application as desired, but this triggers issue #2261.

[alexcrichton]

Do you have an example repo I could poke around in? If you modify a file outside the project root (e.g. in a separate folder from the crate source) then Cargo doesn't currently pick that up and won't rerun the build script, but this is partly why return-if-changed exists.

[Parakleta]

My computer wont turn on this morning, and I leave for two weeks holiday this afternoon.

If from a single directory you run:

cargo new lib
cargo new --bin app
echo 'lib = { path = "../lib" }' >> app/Cargo.toml

as the starting point, and then setup the hello.c and build script from the build script tutorial inside the lib crate and have it export the hello() function.

Then have the app crate use the lib crate and call the hello() function.

From this point if you change the file hello.c and run cargo build in the app crate, nothing happens.

[alexcrichton]

Ah this actually has to do with how the project is structured, the two crates don't share the root of the original project, so they're not taken into account automatically for modification time checks.

[Parakleta]

You do however get the appearance that the modification time checks are done because dependency rules are added for all of the .rs files in the library so it appeared magical that it would rebuild when some files changed and others did not.

I don't know what the best situation is here, you have two different behaviours which in isolation each seem to be sensible things to do in their own context (i.e. rebuild a project if anything in its tree has changed, and keep a dependency graph of consumed .rs files for a project that spans its dependencies).

Thinking about it a little more, I think the automatically rebuilding if anything in the tree has changed is where the problem lies. This is convenient for small projects, but could be expensive for large ones and is quite probably unfeasible if it was made transitive. You already track all of the .rs files explicitly (I think, I haven't checked this properly) so maybe the solution is to require people use the rerun-if-changed rule in their build.rs for dependencies not discoverable through the Cargo.toml directly, and then drop support for rebuilding on any change in the tree.

[alexcrichton]

Yeah long-term we may want to deprecate that behavior, but for now I think that it well suits the behavior of build scripts by default. I would rather have spurious rebuilds than not have rebuilds when I should as that could be mega-confusing.

Looking back I think that this is just a known limitation of the old logic for re-running a build script, which the rerun-if-changed rule was targeted to fix, so I'm going to close this. Thanks again for the report though!