[cmake-developers] Experiments in CMake support for Clang (header & standard) modules

[David Blaikie]

On Mon, May 7, 2018 at 10:13 AM Brad King <brad.king at kitware.com> wrote:

> On 05/07/2018 12:01 PM, Stephen Kelly wrote:
> > Hopefully Brad or someone else can provide other input from research
> already done.
>
> I'm not particularly familiar with what compiler writers or the modules
> standard specification expects build systems to do w.r.t modules.
> However, IIUC at least at one time the expectation was that the module
> files would not be installed like headers


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


> and are used only within a local build tree.


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.


>   Are modules even supposed to be first-class entities
> in the build system specification that users write?
>
> In the Fortran world users just list all the sources and build systems are
> expected to figure it out.  CMake has very good support for Fortran
> modules.
> Our Ninja generator has rules to preprocess the translation units first,
> then parse the preprocessed output to extract module definitions and
> usages,
> then inject the added dependencies into the build graph, and then begin
> compilation of sources ordered by those dependencies (this requires a
> custom fork of Ninja pending upstream acceptance).
>
> Is that what is expected from C++ buildsystems for modules too?
>

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:

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

* 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

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

- Dave


>
> -Brad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake-developers/attachments/20180509/c2a77580/attachment.html>