<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 &lt;<a href="mailto:tom@honermann.net"
              moz-do-not-send="true">tom@honermann.net</a>&gt; 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 &lt;cstdio&gt;</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>