On Fri, Apr 22, 2022 at 16:08:00 +0200, Boris Kolpackov wrote:
> Ben Boeckel <ben.boec...@kitware.com> writes:
> > I agree that the header needs to be *found*, but scanning cannot require
> > a pre-existing BMI for that header.
>
> Well, if scanning cannot require a pre-existing BMI but a pre-existing
> BMI is required to get accurate dependency information, then something
> has to give.
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 not being able to perform `cl.exe *.cpp` anymore should be
the least of people's worries on the recent megathread because 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
I'm sure there are many more in use out there.
> In this example, if you treat import of header-unit.hpp as
> include, you will get incorrect dependency information.
>
> So to make this work correctly we will need to re-create the
> macro isolation semantics of import for include.
I'm aware. This is what I alluded to with "CPP state is probably not
easy".
> 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 wonder if we had had a modularized stdlib which landed with modules if
header units would have been a thing in the first place…
--Ben
