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