>> If the contents are hash-identical, build tools may optionally improve performance
That is the idea (and the question) - as built modules full content (and thus file hash) will be different for "add a comment" change, can another hash be created only for public surface?

Thanks,
Olga

-----Original Message-----
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Ben Boeckel via SG15
Sent: Wednesday, July 31, 2019 1:31 PM
To: David Blaikie via SG15 <sg15_at_[hidden]>
Cc: Ben Boeckel <ben.boeckel_at_[hidden]>; Hernandez, Gerardo <Gerardo.Hernandez_at_[hidden]>; blopes_at_[hidden]; Gor Nishanov <gorn_at_[hidden]>; Cameron DaCamara <Cameron.DaCamara_at_[hidden]>; nathan_at_[hidden]
Subject: Re: [SG15] Will any change in a module source or dependencies cause change in the public/reachable surface of the built module?

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
_______________________________________________
SG15 mailing list
SG15_at_[hidden]
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&amp;data=02%7C01%7Colgaark%40microsoft.com%7C07a9e1892a204249ac6b08d715f60e8b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002018878798928&amp;sdata=jtFJod7MPab9b5Dvh1No8UjdRSQix2%2BnmtlqOfYqhqk%3D&amp;reserved=0