Without trying to solve the general packaging problem, we are going to want
to be able to share BMI in controlled contexts. I don't want to build
thousands of interfaces external to my project, or have to communicate how
to build all of those deeply nested interfaces, for the same reasons that
building a compilation database for the world for implicit module
translation doesn't seem feasible.

On Mon, Feb 11, 2019, 14:05 Ben Boeckel <ben.boeckel_at_[hidden]> wrote:

> 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
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>