On Mon, Mar 04, 2019 at 18:37:58 -0500, Mathias Stearn wrote:
> It would also be nice to have something like "rebuild_hash": "opaque
> string", such that if the hash is the same as a prior run, downstream nodes
> don't need to be rebuilt. This would allow compilers to stuff information
> in the BMI that shouldn't propagate rebuilds, such as comments that may
> show up in warnings, but can't effect the compiled output. It may even be
> worth having that as a per-output hash, to support cases using split-dwarf
> (or other platform equivalents) when the debug info changes in a way that
> would require re-running dwp, but not relinking downstream libraries or
> binaries.

Personally, my gut reaction is that this belongs at the build executor
level, not the compiler. Currently, most of these do mtime-based
detection. Easy to implement at the expense of potential excess work.
Also easy to force the executor to redo something. Smarter executors might do
content hashing detection of changes (I believe that bazel and similar
tools effectively do this). Really smart ones might support a
`content_hash = somecmd` to compute it for any output rule (possibly
with some built-in). This would also potentially work with things like
abidiff for object files and shared libraries too. I don't know how one
would implement `rebuild_hash` semantics without backdating mtimes in
existing executors which seems really finicky.

I don't know that we can shoehorn this information into the output of
the scan step and expect it to actually be implemented before we know
what actually affects BMI output (cf. Clang assuming all flags affect
BMI output and not even "trying" to guess).

--Ben