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