On 08/02/2019 16.59, Ben Boeckel wrote:
> On Fri, Feb 08, 2019 at 13:34:43 -0800, JF Bastien wrote:
> §2
>> It is no slower to determine the dependencies of a modular C++ file
>> than a normal C++ file today, and current proposals aimed at
>> restricting the preamble wouldn’t make a scanner any faster.
>
> Header dependencies are subtly, but crucially, different than module
> dependencies. One can determine header dependencies *while compiling*
> the file (though is not necessarily how it is implemented) and can be
> done at any time once the source file is up-to-date. The first run does
> not need this information because we already know we need to run the
> output; storing discovered dependency information is a nice side effect.
>
> Module dependencies must be present *during compile*, so must be
> determined at build time (since source files may not be available before
> the build has started) *before* compilation starts.

I think there might be some communication confusion here. "Determining
dependencies" can mean two things: determining the *identity* of
dependencies, or determining the *location* of dependencies. Determining
the *identity* is, indeed, as easy for modules as for includes. It's the
*location* that's a problem. For includes, the compiler already has a
set of include paths which it can scan (relatively quick; this is just
directory listing) to determine location.

For modules... I'm not sure how this is going to work. This actually
relates to the open question of how we "ship" modules. But ignore that
for a second.

Compared to includes, we have more trouble with finding the location of
modules provided by the project. To do that, we have to scan every
source file in the project (or at least, in every library of the project
that the current TU uses, including the TU's own component). This most
assuredly *is* slower. (Unless we use module maps...)

What about modules *external* to the project? If they are shipped
already built, then presumably things aren't much different than
includes; we expect them to just be there already.

Where I could see this getting *really* ugly is if a) we have no module
maps, and b) we have no solution for shipping already-built modules. If,
in order to use the module from some external library, I first need to
*build* that module for my own project... how do I do that? Scan every
source file *on the entire system*? That's not just slower, it's not
even feasible. Fortunately, I think we all want to not have to go there...

-- 
Matthew