<div dir="ltr">Without trying to solve the general packaging problem, we are going to want to be able to share BMI in controlled contexts. I don&#39;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&#39;t seem feasible. <br><br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 11, 2019, 14:05 Ben Boeckel &lt;<a href="mailto:ben.boeckel@kitware.com" target="_blank">ben.boeckel@kitware.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Feb 11, 2019 at 11:56:23 -0500, Matthew Woehlke wrote:<br>
&gt; I think there might be some communication confusion here. &quot;Determining<br>
&gt; dependencies&quot; can mean two things: determining the *identity* of<br>
&gt; dependencies, or determining the *location* of dependencies. Determining<br>
&gt; the *identity* is, indeed, as easy for modules as for includes. It&#39;s the<br>
&gt; *location* that&#39;s a problem. For includes, the compiler already has a<br>
&gt; set of include paths which it can scan (relatively quick; this is just<br>
&gt; directory listing) to determine location.<br>
&gt; <br>
&gt; For modules... I&#39;m not sure how this is going to work. This actually<br>
&gt; relates to the open question of how we &quot;ship&quot; modules. But ignore that<br>
&gt; for a second.<br>
<br>
In CMake, the identity is output by the `scan` step. `collate` puts this<br>
together with output paths to create full paths to locations of modules.<br>
<br>
&gt; Compared to includes, we have more trouble with finding the location of<br>
&gt; modules provided by the project. To do that, we have to scan every<br>
&gt; source file in the project (or at least, in every library of the project<br>
&gt; that the current TU uses, including the TU&#39;s own component). This most<br>
&gt; assuredly *is* slower. (Unless we use module maps...)<br>
<br>
The `collate` step handles modules generated by other source files and<br>
outputting the information required by the build tool to get the<br>
dependency graph correct.<br>
<br>
&gt; What about modules *external* to the project? If they are shipped<br>
&gt; already built, then presumably things aren&#39;t much different than<br>
&gt; includes; we expect them to just be there already.<br>
<br>
I think there is consensus that compiled modules do *not* get shipped.<br>
Some other format (possibly IPR[1]) would be provided. CMake would<br>
likely implement this as something like an `INTERFACE_MODULES<br>
foo=/path/to/foo.ipr;bar=/path/to/bar.ipr` property and write the<br>
correct flags for the compiler in use.<br>
<br>
&gt; Where I could see this getting *really* ugly is if a) we have no module<br>
&gt; maps, and b) we have no solution for shipping already-built modules. If,<br>
&gt; in order to use the module from some external library, I first need to<br>
&gt; *build* that module for my own project... how do I do that? Scan every<br>
&gt; source file *on the entire system*? That&#39;s not just slower, it&#39;s not<br>
&gt; even feasible. Fortunately, I think we all want to not have to go there...<br>
<br>
A module is what you need to consume the interface. You don&#39;t need the<br>
source itself for that. The IPR would just say what symbols are provided<br>
via that module (analogous to headers saying what symbols are available)<br>
and the linker would do the same job it has always done and hook them up<br>
when linking the providing library.<br>
<br>
--Ben<br>
<br>
[1]<a href="https://github.com/GabrielDosReis/ipr" rel="noreferrer" target="_blank">https://github.com/GabrielDosReis/ipr</a><br>
_______________________________________________<br>
Tooling mailing list<br>
<a href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/tooling" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a><br>
</blockquote></div>
</div>