<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:26 PM, Mathias Stearn
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAH4rMhhosTWQ2DGkXSAhmNa1jtyqw6uBChs-5wCqfAQ2idCdyQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">
          <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">
                  <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).</li>
                  </ol>
                </div>
              </blockquote>
              <div><br>
              </div>
              <div>Unfortunately that design of "compiler handles
                everything, build systems are oblivious" means that
                clang modules break several important
                build-system-adjacent tools, such as ccache[1] and
                icecream[2]. distcc is likely also affected since it
                originally worked the same as icecream. It is possible
                that the new "pump" mode makes it work in distcc, but I
                don't have a cluster to test that on.</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    I'd like to understand more why ccache is impacted.  I don't have
    experience with the other tools, so can't comment on them.<br>
    <blockquote type="cite"
cite="mid:CAH4rMhhosTWQ2DGkXSAhmNa1jtyqw6uBChs-5wCqfAQ2idCdyQ@mail.gmail.com">
      <div dir="ltr">
        <div dir="ltr">
          <div dir="ltr">
            <div class="gmail_quote">
              <div><br>
              </div>
              <div>I think the clang modules design makes it somewhere
                between hard and impossible for these kinds of tools to
                work well with them. Support for distributed builds is
                one of my major concerns with modules. Almost any form
                of modules that isn't just "better scoping in headers
                with no caching" will make distributed builds more
                complicated than today. I want to hope that this problem
                is solvable though. Having the machinery hidden in the
                compiler rather than explicitly managed makes it
                substantially harder (while admittedly making simple
                builds simpler).</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <p>Given that Clang does have options to allow explicit control of
      module artifacts when desired, does that help to address your
      concerns here?  E.g., use explicit module artifact management only
      when beneficial.<br>
    </p>
    <p>Tom.<br>
    </p>
    <blockquote type="cite"
cite="mid:CAH4rMhhosTWQ2DGkXSAhmNa1jtyqw6uBChs-5wCqfAQ2idCdyQ@mail.gmail.com">
      <div dir="ltr">
        <div dir="ltr">
          <div dir="ltr">
            <div class="gmail_quote">
              <div><br>
              </div>
              <div>
                <div>[1] <a
href="https://github.com/ccache/ccache/blob/2753dafa38e14bfc5d4bb5c2b692edad964aaef6/src/compopt.c#L66"
                    moz-do-not-send="true">https://github.com/ccache/ccache/blob/2753dafa38e14bfc5d4bb5c2b692edad964aaef6/src/compopt.c#L66</a></div>
                <div>[2] This is how I tested. It also fails with remote
                  cpp enabled. If there is a better way, I'd be happy to
                  try it.</div>
                <div>&gt; ICECC_REMOTE_CPP=0
                  ICECC_PREFERRED_HOST=remote_host
                  /usr/lib/icecream/bin/icecc clang++ -fmodules -c
                  test.cpp</div>
                <div>
                  <div>test.cpp:1:29: fatal error: module 'Header' not
                    found</div>
                  <div>#pragma clang module import Header /* clang -E:
                    implicit import for #include "header.h" */</div>
                </div>
                <br class="gmail-Apple-interchange-newline">
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Tooling mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Tooling@isocpp.open-std.org">Tooling@isocpp.open-std.org</a>
<a class="moz-txt-link-freetext" href="http://www.open-std.org/mailman/listinfo/tooling">http://www.open-std.org/mailman/listinfo/tooling</a>
</pre>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>