[cmake-developers] Experiments in CMake support for Clang (header & standard) modules
Stephen Kelly
steveire at gmail.com
Tue May 15 03:22:52 EDT 2018
Brad King 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 and are used only within a
> local build tree. Are modules even supposed to be first-class entities
> in the build system specification that users write?
The answer is probably both 'hopefully not' and 'sometimes'.
> 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?
Hopefully. However, in some cases, the step of 'extracting module
definitions and usages' might be very hard to do. This document is quite
concise about that:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1052r0.html
So, the answer for cmake might be that CMake can learn to extract that
stuff, but ignore certain cases like imports within ifdefs. Maybe CMake
could then also provide API for users to specify the usages/dependencies
explicitly in those cases. I don't know how convenient that would be (or
could be made through design).
Thanks,
Stephen.
More information about the cmake-developers
mailing list