* On the contrary, the existing proposal and implementation direction will require major and complicated build system modifications if more than a handful of modules are to be used (statically encoding additional compiler invocations can be reasonable, but doesn't scale).

Citation needed.
Ben Boeckel et al’s paper might be relevant here.

From: tooling-bounces_at_[hidden] <tooling-bounces_at_[hidden]> On Behalf Of Tom Honermann
Sent: Friday, February 8, 2019 10:14 AM
To: WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
Subject: Re: [Tooling] Clang Modules and build system requirements

On 2/8/19 12:58 AM, Mathias Stearn wrote:


On Fri, Feb 8, 2019 at 12:33 AM Tom Honermann <tom_at_[hidden]<mailto:tom_at_[hidden]>> wrote:
A couple of people have countered that build system updates are required (presumably in excess of just adding '-fmodules' to Clang invocations) in order to enable support for Clang Modules. This seems trivially incorrect to me, so long as one does not consider Clang's module.modulemap files to be part of the build system (I don't; they are tool specific configuration files that the build system does not need to be aware of).

I would hope you are marking the module.modulemap as an input dependency of every compilation that uses -fmodules. If you don't then you are risking silent miscompilation which is about the worst thing a build system can do. And if you are, that means that you have either manually added it as an input edge to every compile (unlikely), or you modified your build system to teach it to do that automatically*. I assume you are primarily referring to deeper structural changes, but your implication that you can just add -fmodules to CXXFLAGS and walk away seems trivially incorrect to me.

Build systems that rely on the compiler to provide per-TU input dependencies are likely already covered here. For example, Clang's '-M' output includes referenced module map files:

$ cat m.cpp
#include <cstdio>

$ clang -c -M -fmodules m.cpp
m.o: m.cpp \
  ...
  /home/tom/products/clang-7.0.0/lib/clang/7.0.0/include/module.modulemap \
  ...

(I see from other responses that you already discovered this, but I already wrote the above so I'm sending it anyway).

It does look like build systems that rely on #line scanning for dependencies will currently miss the dependency as no #line indicators are emitted for module maps. Perhaps there is a reasonable enhancement request to be made to Clang here.

You are correct that a missed dependency on a module map file can result in a miscompilation, but the changes are low (I think the only way that can happen is if the set of exported sub-modules is changed). Missed dependencies are bad, but also something that can be improved as QOI in the build system (I've never yet had the pleasure of working with a build system that wasn't missing some dependency edges). The point I was trying to make is that Clang modules don't require build system updates (other than to pass '-fmodules') to continue to work more-or-less as well as they already do. On the contrary, the existing proposal and implementation direction will require major and complicated build system modifications if more than a handful of modules are to be used (statically encoding additional compiler invocations can be reasonable, but doesn't scale).
*Technically there is an additional option: your build system monitors for every file that the compiler opens (eg by LDPRELOAD) and automatically adds the modulemap file as an input edge. But I don't think you are intending to require every build system to do that.

Certainly not :)

Tom.