[modules] Preprocessing requires compiled header unit modules

[Ben Boeckel]

On Mon, Apr 25, 2022 at 11:42:14 +0200, Boris Kolpackov wrote:
> 1. Firstly, this only applies to header units, not named modules.

Correct.

> 2. I am not sure what you mean by "active build executor" (but it
>    does sound ominous, I will grant you that ;-)).

One that does more than schedule builds, but is "actively" participating
in the build itself. Ninja's `dyndep` is about as close one can be to
the edge IMO. `make` is potentially active because of its behavior
around `include` of output files, but this is a niche feature.

> 3. I agree some build systems may require "major overhauls" to
>    support header units via the module mapper. I would like this
>    not to be the case, but so far nobody has implemented an
>    alternative (that I am aware of) that is correct and scalable
>    and I personally have doubts such a thing is achievable.

One the compilers can scan headers, CMake should be able to do it. MSVC
is the closest right now (though the name it wants for any given header
usage site is currently an issue).

> Ben Boeckel <ben.boeckel@kitware.com> writes:
> > Note that scanning each module TU only happens once. Header units might
> > just get *read* in the course of scanning other units.
> > 
> > And headers are read multiple times already over the lifetime of the
> > build, so we're not making things worse here.
> 
> I am not sure I follow. Say we have 10 TUs each include or import
> 10 headers each of which includes <functional>. If we use include,
> then when scanning each of these 10 TUs we have to scan <functional>
> once (since all the subsequent includes are suppressed by include
> guards). So total of 10x1=10 scans of <functional> for the entire
> build.
> 
> Now if instead of include we use import (which, during the scan, is
> treated as include with macro isolation), we are looking at 10 scans
> of <functional> for each TU (because the include guards are ignored).
> So total of 10x10=100 scans of <functional> for the build.
> 
> What am I missing?

Ew, indeed. I suppose a sufficiently smart compiler could just encode
headers as a "diff" to the preprocessor and symbol state and apply it
upon revisiting, but that seems like a high bar (re-reading if it
detects a difference in preprocessor state that "matters").

--Ben