On Mon, Feb 11, 2019 at 11:56:23 -0500, Matthew Woehlke wrote:
> 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.

In CMake, the identity is output by the `scan` step. `collate` puts this
together with output paths to create full paths to locations of modules.

> 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...)

The `collate` step handles modules generated by other source files and
outputting the information required by the build tool to get the
dependency graph correct.

> 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.

I think there is consensus that compiled modules do *not* get shipped.
Some other format (possibly IPR[1]) would be provided. CMake would
likely implement this as something like an `INTERFACE_MODULES
foo=/path/to/foo.ipr;bar=/path/to/bar.ipr` property and write the
correct flags for the compiler in use.

> 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...

A module is what you need to consume the interface. You don't need the
source itself for that. The IPR would just say what symbols are provided
via that module (analogous to headers saying what symbols are available)
and the linker would do the same job it has always done and hook them up
when linking the providing library.

--Ben

[1]https://github.com/GabrielDosReis/ipr