Ben Boeckel <ben.boec...@kitware.com> writes: > If we need to know and have dependencies prepared before we can figure > out the dependencies for a TU, modules are unsolvable (without an active > build executor). If C++ implementations are really going to require > that, then [...] the following tools are all unsuitable for C++ with > header units without major overhauls (alphabetical): > > - autoconf/automake > - cmake > - gn > - gyp > - make (not GNU make, though even that requires some active > involvement via the socket communications) > - meson > - ninja
A couple of points: 1. Firstly, this only applies to header units, not named modules. 2. I am not sure what you mean by "active build executor" (but it does sound ominous, I will grant you that ;-)). 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. > > Even if we manage to do this, there are some implications I > > am not sure we will like: the isolated macros will contain > > inclusion guards, which means we will keep re-scanning the > > same files potentially many many time. Here is an example, > > assume each header-unitN.hpp includes or imports <functional>: > > 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?
