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)

- Dave

On Thu, Jul 18, 2019 at 2:13 PM Olga Arkhipova via SG15 <
sg15_at_[hidden]> wrote:

> Hi all,
>
> This question came as a part of the discussion with Gerardo and Nathan
> (see attached).
>
>
>
> Geraldo and I assumed that compilers and build systems will be able to
> detect somehow that adding, say, a comment to a module source should not
> cause rebuild of all components which depend on this module. This is
> currently the case for other languages (like c# and java, which have
> declarations and implementation in one binary, so they had to figure out
> which changes affect the dependent components and which do not).
>
>
>
> Nathan and Gaby pointed out that currently built modules contain locations
> (line/pos I assume) of the declarations in the source file(s), so pretty
> much any change in the module sources and dependencies (except maybe very
> trivial ones) will produce a different CMI (CMI is new name for BMI).
>
>
>
> You can argue that module CMI change when source changes will cause the
> same rebuild of the dependent components as a header file before. This is
> probably true, but with header files we did not really have an option. With
> modules, it seems to be a possibility to do better. Also, when a header
> file changes, all source files which #include it (directly or indirectly)
> can potentially be built in parallel. With modules, we can only build
> dependent modules sequentially, and the sooner we realize that we don't
> really have to rebuild some components, the better we (users, actually) are.
>
>
>
> So I am wondering what people think about the following questions:
>
> 1. Is it worth investigating? If we do nothing, we’ll be rebuilding
> the same components as we’d do for a header file change. Which is often
> more that it really should be.
> 2. Is it actually feasible to detect that public/reachable surface of
> a built module has not changed for some source/dependencies changes? In
> other words, can compiler produce some sort of a hash only for the
> public/reachable surface of a built module (not the whole CMI)?
>
>
>
> Thanks,
>
> Olga
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/sg15
>