<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, May 7, 2018 at 10:13 AM Brad King <<a href="mailto:brad.king@kitware.com">brad.king@kitware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 05/07/2018 12:01 PM, Stephen Kelly wrote:<br>
> Hopefully Brad or someone else can provide other input from research already done.<br>
<br>
I'm not particularly familiar with what compiler writers or the modules<br>
standard specification expects build systems to do w.r.t modules.<br>
However, IIUC at least at one time the expectation was that the module<br>
files would not be installed like headers </blockquote><div><br>The module interface source file is, to the best of my knowledge, intended to be installed like headers - and I'm currently advocating/leaning/pushing towards it being installed exactly that way (in the same directories, using the same include search path, etc).<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">and are used only within a local build tree.</blockquote><div><br></div><div>The /binary/ representation of the module interface is likely to be only local to a specific build tree - since it's not portable between compilers or different compiler flag sets, even.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  Are modules even supposed to be first-class entities<br>
in the build system specification that users write?<br>
<br>
In the Fortran world users just list all the sources and build systems are<br>
expected to figure it out.  CMake has very good support for Fortran modules.<br>
Our Ninja generator has rules to preprocess the translation units first,<br>
then parse the preprocessed output to extract module definitions and usages,<br>
then inject the added dependencies into the build graph, and then begin<br>
compilation of sources ordered by those dependencies (this requires a<br>
custom fork of Ninja pending upstream acceptance).<br>
<br>
Is that what is expected from C++ buildsystems for modules too?<br></blockquote><div><br>Yes, likely something along those lines - though I'm looking at a few different possible support models. A couple of major different ones (that may be both supported by GCC and Clang at least, if they work out/make sense) are:<br><br>* the wrapper-script approach, where, once the compiler determines the set of direct module dependencies, it would invoke a script to ask for the location of the binary module interface files for those modules. Build systems could use this to dynamically discover the module dependencies of a file as it is being compiled.<br><br>* tool-based parsing (more like what you've described Fortran+Ninja+CMake is doing). The goal is to limit the syntax of modules code enough that discovering the set of direct module dependencies is practical for an external (non-compiler) tool - much like just some preprocessing and looking for relatively simple keywords, etc. - then the tool/build system can find the dependencies ahead of time without running the compiler<br><br>(a 3rd scenario, is what I've been sort of calling the "hello world" example - where it's probably important that it's still practical for a new user to compile something simple like "hello world" that uses a modularized standard library, without having to use a build system for it (ie: just run the compiler & it goes off & builds the in-memory equivalent of BMIs without even writing them to disk/reusing them in any way))<br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-Brad<br>
</blockquote></div></div>