<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 2/8/19 12:58 AM, Mathias Stearn
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAH4rMhhfsOpqQ_BppVGEKhofCDa2bcwQCKMqR1UY0LzU1kRvzw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Feb 8, 2019 at 12:33
AM Tom Honermann <<a href="mailto:tom@honermann.net"
moz-do-not-send="true">tom@honermann.net</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
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). <br>
</div>
</blockquote>
<div><br>
</div>
<div>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.<br>
</div>
</div>
</div>
</blockquote>
<p>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:</p>
<p><tt>$ cat m.cpp </tt><tt><br>
</tt><tt>#include <cstdio></tt><tt><br>
</tt></p>
<p><tt>$ clang -c -M -fmodules m.cpp </tt><tt><br>
</tt><tt>m.o: m.cpp \</tt><tt><br>
</tt><tt> ...</tt><tt><br>
</tt><tt>
/home/tom/products/clang-7.0.0/lib/clang/7.0.0/include/module.modulemap
\</tt><tt><br>
</tt><tt> ...</tt><br>
</p>
<p>(I see from other responses that you already discovered this, but
I already wrote the above so I'm sending it anyway).<br>
</p>
<p>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.<br>
</p>
<p>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).<br>
</p>
<blockquote type="cite"
cite="mid:CAH4rMhhfsOpqQ_BppVGEKhofCDa2bcwQCKMqR1UY0LzU1kRvzw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>*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.</div>
</div>
</div>
</blockquote>
<p>Certainly not :)</p>
<p>Tom.<br>
</p>
</body>
</html>