<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>I've been recently claiming two properties of Clang Modules that
I believe have been central to their success.</p>
<ol>
<li>Clang modules are built on #include directives in such a way
that existing tools that have no knowledge of Clang modules
continue to work as they always have.</li>
<li>Modules are built implicitly on demand (by default) such that
build system updates are not required (other than to pass
'-fmodules' to enable the feature).<br>
</li>
</ol>
<p>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'd like to hear more
details from those that believe build system updates are required
to take advantage of Clang modules. What changes do you believe
build systems have required?</p>
<p>I ask this because I am concerned that the design proposed in
P1103 (specifically module and import declarations) combined with
current implementation direction (extrinsically managed module
artifacts) go directly against existing practice and, in
particular, the two key features I consider to have been
instrumental to the success of the only widely deployed C++ module
system. I believe we should be modeling standard modules more
closely on what has been shown to be deployable at scale and in
practice.<br>
</p>
<p>Tom.<br>
</p>
</body>
</html>