Automatically rebuild if Cargo.toml or git changes

[tylerhawkes]

Of all the things that are recorded by built, Cargo.toml and git can change without triggering a rebuild the next time cargo build is run. If those options are enabled, built should emit cargo:rerun-if-changed=<file> for the Cargo.toml and any files in .git. That way cargo can automatically determine if the build.sh script needs to rerun or not.
I ran into this issue trying to do a manual release (we're working on CI) of an internal project and had to manually change the build.rs file to get cargo to rerun built and get a new git hash.

[lukaslueg]

Thanks for the report.

That would mean we had to scan the git-root for all the files and cause cargo to fingerprint them?!

[tylerhawkes]

Or just HEAD and whatever contains the tags.
I'll try to get a pull request together for this.

[jayvdb]

Note due to workspaces, this feature would need to also check the Cargo.toml at the root.

But I guess it would be sufficient, and probably more desirable, to check if the Cargo.lock has been modified.

And IIRC, cargo:rerun-if-changed=<root>/.git/ will suffice to re-run if anything under .git has been modified. But I recommend that be an optional feature as it will trigger a rebuild for all sorts of things that do not effect the built data, such as creating a new branch locally.

[jayvdb]

Note according to https://doc.rust-lang.org/cargo/reference/build-scripts.html#change-detection , built must not emit cargo:rerun-if... unless the user explicitly opts-in.

Emitting one of these replaces the default behaviour, which is to "always re-running the build script if any file within the package is changed". i.e. built emitting this can break existing code which relied on that default behaviour.

[jayvdb]

The change needed to rerun if lockfile is modified is at jayvdb@c584bbd

However I cant help but wonder if cargo already rebuilds built.rs on lock file changes.

When I manually change Cargo.lock by removing the comment header at the top - i.e. not changing any lock entry, I see the following when using cargo build -vvv in a project using build.rs without any rerun

       Dirty foo v0.1.0 (/home/jayvdb//rust/foo): the local fingerprint type changed

[lukaslueg]

I'm hesitant to implement this unless somebody comes up with a case which fits into the pattern mentioned below. As far as I can see:

• Cargo will, unless told otherwise, re-run the build-script if any files it tracks changes.
  • This might include files not tracked by git (e.g. autogenerated source files)
  • otoh git might track files that Cargo doesn't track and neither has to (e.g. README)
• The lockfile may or may not be tracked by git; this doesn't affect Cargo's logic.
• If we emit rerun-if-changed for any files at all, Cargo will only re-run the build-script if those files change. built has no way to tell which files / directories that should be.
• We can force Cargo to track the entire MANIFEST_PATH, which is probably undesirable for a lot of users.
• The build script might contain other code, unrelated to built, which has it's own rerun-logic.

The way I see this, since users have to have at least a one-line build script in place anyway, we're better off with a documentation fix on how users might want to emit rerun-rules themselves, depending on their use case.

[epage]

If we emit rerun-if-changed for any files at all, Cargo will only re-run the build-script if those files change. built has no way to tell which files / directories that should be.

Lukas has seen this but for cross-referencing purposes: rust-lang/cargo#4587

Also, if a package needs a build script for multiple purposes, they can negatively impact each other. rust-lang/cargo#14903 (comment) proposes Cargo support multiple build scripts for a package (and eventually allow delegating to a package like built for it, rather than hand writing it).