Build Script Support - input dirty checking

[mark-buer]

There appears to be no mechanism within cargo for a build script to signal that it's dependencies, i.e. input files to the build script, have changed.

This fact makes build script code-generation scenarios, amongst others, awkward in those situations where the build script input files change regularly as part of the normal software development process.

A possible solution, modify the dirty detection logic of cargo thusly:

1. in the case where cargo has made the determination that no recompilation is required,
2. and cargo has determined that a build script exists and that the build script supports dirty checking ("opt-in" via a Cargo.toml configuration setting),
3. cargo will invoke the build script with a flag (an environment variable or perhaps a command line argument) that indicates to the build script that it should check and report on the dirty state of it's inputs as compared to some aspect of files within the output directory (modified time or similar),
4. the build script will then return the dirty state back to cargo (an environment variable or perhaps an exit status),
5. which conditionally forces cargo to perform a recompilation.

Thoughts?

As an immediate workaround for this shortcoming of cargo, I'll need to hack together a shell script (or maybe a make file) that conditionally touches Cargo.toml based on the modified times of the build script inputs as compared to some output file, and then ensure I always run said shell script prior to running cargo.

Other workarounds?

[alexcrichton]

Oddly enough I've actually started working on this recently! My current idea of how to implement this is actually more along the lines of #1162 where a build script simply prints its dependencies as part of its normal execution. That way Cargo knows the exact set of inputs to a build script if a build script opts in to that behavior.

Today, however, Cargo considers all files in a repo as inputs to a build script, so if you're changing files and a build script isn't running it's either a bug in Cargo or it's because the inputs are outside the crate root. These use cases should be handled by #1162 though!

For now, I'm going to close in favor of that issue, but thanks for the report!

[mark-buer]

or it's because the inputs are outside the crate root

That explains the behaviour I observe :-)

#1162 looks good!