Rerun-if-changed without disabling other heuristics as a side-effect

[kornelski]

Currently any use rerun-if-changed opts in entire build into a completely "manual" tracking, disabling all built-in rules as a side effect. This means it's not possible to safely just add one file/env var check to the build without understanding all the dependencies of the entire build script.

In order to use rerun-if-changed features in build-time libraries without potentially breaking rest of the build, it's necessary to be able to use rerun-if-changed-like functionality without disabling the built-in heuristic (i.e. rerun if a var/file has changed in addition to all the other/default conditions that cause the build to be rebuilt).

rust-lang/pkg-config-rs#45 (comment)

bikeshed syntax: cargo:rerun-if-also-changed=file, cargo:rerun-if-changed+=file, cargo:rerun-if-changed;keep-defaults=file

[lukaslueg]

The current semantics of rerun-if-changed and rerun-if-changed-env are confusing and a new key rerun-if-changed+ might just add to this confusion. Notice that

rerun-if-changed+=foo
rerun-if-changed+=bar
rerun-if-changed=foobar

is effectively the same as without the +-key.

rerun-if-changed+=foo
rerun-if-changed+=bar
rerun-if-change-env=CC

causes Cargo to still ignore the package sources due to a reference to an env-var and use foo, bar, [CC] as the only fingerprints.

IMHO rerun-if-changed+ in addition to the current system is inferior to changing rerun-if-changed and rerun-if-changed-env to add fingerprints to the then already-considered package sources.

The current implementation calls for the build-script to walkdir() it's sources, including those that might be out-of-tree. The rationale is that the user has already opted in to do dependency selection himself and a walkdir('./src') is easily implemented.
Another approach might be to selectively opt-out of package-sources and let rerun-if-changed work as rerun-if-changed+ would. The user can then escalate an "also consider this" to "just consider this".

[kornelski]

I'm also OK with changing the existing behavior to be additive without side effects, and adding another explicit option like cargo:disable-built-in-heuristics.

[kornelski]

Can disabling of built-in heuristics as a side effect be fixed (i.e. side-effect removed)?

Does building more than necessary count as a breaking change? If so, can it be done as part of 2018 edition?

[alexcrichton]

Yes changing the default behavior would be a breaking change, but we could always add a new option for build scripts (or something like that) to say "use the default heuristics". Either that or a crate could be published to crates.io which is a one-liner to do what Cargo currently does.