On Thu, Jul 18, 2019 at 14:22:57 -0700, David Blaikie via SG15 wrote:
> Seems this'd be QOI - finding ways to reuse modules as much as possible.
> (been touched on in a variety of ways in SG15 - like reusing them in
> different build modes (macros definitions that don't change anything in
> this translation unit), maybe between different compilers (challenging),
> comment changes (tricky if it changes lines/columns as you say - while
> anything downstream that /successfully/ built, would probably be fine - but
> if a downstream entity has failed to build pre-change, it'd make sense to
> rerun it so the error messages have the correct/up to date line numbers in
> diagnostics, etc (you should not show a user any cached diagnostics from
> the old build) - so the file can't be identical... which is going to be
> super tricky for the build system)

I agree here. Many build systems expect that outputs are updated if
the associated rule is run (make). Ninja does as well, but may
optionally check if it actually was updated after running the rule
(restat = 1). Other build tools may rely on content hashes rather than
mtime checks.

For an implementation intended to be used efficiently in many build
tools, I would say to always update the mtime (max(mtime(inputs)) is
good, now() is also sufficient). If the contents are hash-identical,
build tools may optionally improve performance by pruning a build graph
based on contents rather than mtimes (and eliding hashing based on
mtimes).

The QOI comes down to how much information is in the CMI files. If your
CMI format only stores declarations and other relevant information, your
warning quality may suffer, but your build performance increase.
Implementations wanting "perfect" warning fidelity may end up tagging
all of those bits with row/column offsets that are sensitive to
"non-semantic" changes. This is a decision of the implementation, not
the build tool (which ideally copes with either decision just fine).

--Ben