<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:59 PM, Corentin wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CA+Om+Sgb4S_9B0Rqo=nF7Z4AP7NoWmOZfx97Ly-bAZwnsPoEaw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div><br>
        </div>
        I think the information _should_ be in the source file.
        <div>The goal should be to simplify the use of tools as much as
          we want to simplify (or make possible) their implementation.</div>
        <div>Asking people to manually maintain a module mapping for
          every project doesn't seem to be a reasonable stance given:</div>
        <div>
          <ul>
            <li><font size="2">The information would have to be encoded
                in the build system too anyway because build systems
                will have different requirements than these files</font></li>
            <li><font size="2">Each dependency would have to have a
                similar file which both compilers and tools would have
                to search for</font></li>
          </ul>
        </div>
      </div>
    </blockquote>
    <font size="2">Clang modules has demonstrated that 1) programmers
      are willing to author module map files, 2) build systems don't
      have to be aware of them, and 3) dependencies can still be
      inferred.</font><br>
    <blockquote type="cite"
cite="mid:CA+Om+Sgb4S_9B0Rqo=nF7Z4AP7NoWmOZfx97Ly-bAZwnsPoEaw@mail.gmail.com">
      <div dir="ltr">
        <div><font size="2">Module make compiling individual source
            files harder, however, it is not a new problem</font></div>
        <div><font size="2">Each source file already depends on a set of
            include paths and defines that may vary on a
            source-per-source and configuration-per configuration basis.</font></div>
        <div><font size="2"><br>
          </font></div>
        <div><font size="2">Any project beyond a simple Hello World has
            some of its state in a build system, and the only accurate
            way to build or parse a TU is to ask the build system for
            the relevant info.</font></div>
      </div>
    </blockquote>
    <font size="2">I don't agree with that.  It is common to configure
      tools with include paths and macro definitions gleaned from
      compilers without involving build systems.</font><br>
    <blockquote type="cite"
cite="mid:CA+Om+Sgb4S_9B0Rqo=nF7Z4AP7NoWmOZfx97Ly-bAZwnsPoEaw@mail.gmail.com">
      <div dir="ltr">
        <div><font size="2"><br>
          </font></div>
        <div><font size="2">It would be nice that the source code
            was the single source of truth. The preprocessor has been
            prohibiting that since forever (and it is not something we
            can fix any time soon)</font><span style="font-size:small">.</span></div>
        <div><span style="font-size:small">It would, therefore, be
            preferable not to introduce a third source of truth beyond
            the build system and the files.</span></div>
      </div>
    </blockquote>
    Module maps are (non-C++) source files.  They don't need to be
    redundant with respect to what is in other source files.  Clang
    module map files don't specify redundant information.<br>
    <blockquote type="cite"
cite="mid:CA+Om+Sgb4S_9B0Rqo=nF7Z4AP7NoWmOZfx97Ly-bAZwnsPoEaw@mail.gmail.com">
      <div dir="ltr">
        <div><span style="font-size:small"><br>
          </span></div>
        <div><span style="font-size:small"><br>
          </span></div>
        <div><span style="font-size:small">This is not to say such
            manifest should not exist, in fact, I would love if it did.</span></div>
        <div><span style="font-size:small">But I think it should be
            generated and maintained by a build system rather than be
            manually maintained.</span></div>
        <div><span style="font-size:small">Neither of these precludes
            that</span></div>
        <div>
          <ul>
            <li><font size="2">The file could be manually maintained if
                you really want to do so</font></li>
            <li><font size="2">The file could be committed - although I
                would strongly discourage that</font></li>
          </ul>
          <div><font size="2"><br>
            </font></div>
        </div>
        <div><font size="2">In such a scenario, the file would be
            updated by invoking the build system (which would *NOT* need
            to compile anything) to update the file, but a scan of
            modified files as well as potentially a configuration step</font></div>
        <div><font size="2"><br>
          </font></div>
        <div><font size="2"><br>
          </font></div>
        <div><font size="2">That would ensure the manifest you want
            describes a known build configuration ( which is relatively
            easy ) rather than describes how to set up a build ( which
            is akin as specifying a build system description format)</font></div>
      </div>
    </blockquote>
    <font size="2">If manifest files have to reflect a build
      configuration, then I think the problems we face have been made
      worse.</font><br>
    <blockquote type="cite"
cite="mid:CA+Om+Sgb4S_9B0Rqo=nF7Z4AP7NoWmOZfx97Ly-bAZwnsPoEaw@mail.gmail.com">
      <div dir="ltr">
        <div><font size="2"><br>
          </font></div>
        <div><font size="2"><br>
          </font></div>
        <div><font size="2">That generated manifest file could further
            be used by a compiler to build all the dependency of a TU,
            but doing so would start to turn compiler in a build system
            ( minus the configuration part), which I don't think many
            people would be comfortable with.</font></div>
      </div>
    </blockquote>
    <p><font size="2">This is what I like about Clang modules.  The
        compiler-as-a-build-system is optional.  It is QOI performance
        improvement.<br>
      </font></p>
    <p><font size="2">Tom.<br>
      </font></p>
    <blockquote type="cite"
cite="mid:CA+Om+Sgb4S_9B0Rqo=nF7Z4AP7NoWmOZfx97Ly-bAZwnsPoEaw@mail.gmail.com">
      <div dir="ltr">
        <div>
          <div><br>
          </div>
          <div><br>
          </div>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Fri, 8 Feb 2019 at 18:26
          Mathias Stearn &lt;<a href="mailto:redbeard0531@gmail.com"
            moz-do-not-send="true">redbeard0531@gmail.com</a>&gt; wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div dir="ltr">
            <div dir="ltr">
              <div dir="ltr">
                <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" target="_blank"
                      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>
              </div>
            </div>
          </div>
          <div dir="ltr">
            <div dir="ltr">
              <div dir="ltr">
                <div class="gmail_quote">
                  <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><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><br>
                  </div>
                  <div>
                    <div>[1] <a
href="https://github.com/ccache/ccache/blob/2753dafa38e14bfc5d4bb5c2b692edad964aaef6/src/compopt.c#L66"
                        target="_blank" 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="m_-3300381474572476085gmail-Apple-interchange-newline">
                  </div>
                </div>
              </div>
            </div>
          </div>
          _______________________________________________<br>
          Tooling mailing list<br>
          <a href="mailto:Tooling@isocpp.open-std.org" target="_blank"
            moz-do-not-send="true">Tooling@isocpp.open-std.org</a><br>
          <a href="http://www.open-std.org/mailman/listinfo/tooling"
            rel="noreferrer" target="_blank" moz-do-not-send="true">http://www.open-std.org/mailman/listinfo/tooling</a><br>
        </blockquote>
      </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>