<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 08/31/2018 03:35 PM, Tom Honermann
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:c65545d4-9dd6-c4e8-99ef-cda2407e8915@honermann.net">On
      08/31/2018 03:09 PM, Ben Craig wrote:
      <br>
      <blockquote type="cite">Maybe it's too soon for this, but can I
        see a Tony table for the build process?  I can even start...
        <br>
      </blockquote>
      <br>
      I think that might be useful and I can produce something like
      that. I think what might be more informative though is inclusion
      of examples for tools that don't (can't) use the typical compiler
      and build system approach.  I'll try and add that too.
      <br>
    </blockquote>
    <br>
    The following example illustrates minimum compiler invocations for
    compiling and linking a TU that includes a header vs a TU that
    imports a module interface unit for each of the Microsoft, Clang,
    and Gcc compilers as currently implemented.  The example assumes
    that foo.cpp was previously compiled and will be linked in via a
    library.  <br>
    <br>
    <table width="100%" border="1" cellspacing="2" cellpadding="2">
      <tbody>
        <tr>
          <td valign="top"><b>Implementation</b><br>
          </td>
          <td valign="top"><b>Header style</b><br>
          </td>
          <td valign="top"><b>Module style</b><br>
          </td>
        </tr>
        <tr>
          <td valign="top"><br>
          </td>
          <td valign="top"><tt>// foo.h</tt><br>
            <tt><tt><tt>#include &lt;foo/detail.h&gt;<br>
                  ...<br>
                </tt></tt>void foo();<br>
              ...<br>
              <br>
              // foo.cpp</tt><tt><tt><br>
                void foo() { ... }<br>
                <br>
              </tt>// t.cpp<br>
              #include &lt;foo.h&gt;
            </tt><tt><br>
            </tt><tt>int main() { foo(); }
            </tt></td>
          <td valign="top"><tt>// foo.cpp<br>
              module;<br>
              #include &lt;foo/detail.h&gt;<br>
              export module foo;<br>
              ...<br>
              export void foo() { ... }<br>
              ...<br>
              <br>
              <br>
              // t.cpp<br>
              import foo;</tt><tt><br>
            </tt><tt>int main() { foo(); }</tt></td>
        </tr>
        <tr>
          <td valign="top">Microsoft<br>
          </td>
          <td valign="top"><tt>$ cl /Ifoo/include t.cpp foo.lib </tt><tt>/Fet.exe</tt><br>
          </td>
          <td valign="top"><tt>$ cl /experimental:module
              /module:interface /c </tt><tt><tt>/Ifoo/include </tt>foo.cpp
              <font color="#999999"># generates foo.ifc</font><br>
              $ cl </tt><tt>/experimental:module /module:reference
              m.ifc t.cpp foo.lib /Fet.exe</tt><br>
          </td>
        </tr>
        <tr>
          <td valign="top">Clang<br>
          </td>
          <td valign="top"><tt>$ clang -Ifoo/include </tt><tt>t.cpp</tt><tt>
              -lfoo -o t<br>
            </tt></td>
          <td valign="top"><tt>$ clang -fmodules-ts --precompile </tt><tt><tt>-Ifoo/include
              </tt>foo.cpp -o foo.pcm</tt><tt> <font color="#999999">#
                generates foo.pcm</font><br>
            </tt><tt>$ clang -fmodules-ts -fmodule-file=foo.pcm t.cpp</tt><tt>
              -lfoo -o t<br>
            </tt></td>
        </tr>
        <tr>
          <td valign="top">Gcc<br>
          </td>
          <td valign="top"><tt>$ gcc -Ifoo/include t.cpp -lfoo -o t<br>
            </tt></td>
          <td valign="top"><tt>$ gcc -fmodules-ts -c </tt><tt><tt><tt>Ifoo/include
                </tt></tt>foo.cpp <font color="#999999"># generates
                foo.nms (and unused foo.o)</font><br>
              $ gcc -fmodules-ts t.cpp -lfoo -o t        <font
                color="#999999"># implicitly searches for foo.nms</font><br>
            </tt></td>
        </tr>
      </tbody>
    </table>
    <br>
    Now assume the existence of a module description file similar to:<br>
    <br>
    <table width="100%" border="1" cellspacing="2" cellpadding="2">
      <tbody>
        <tr>
          <td valign="top"><b>Hypothetical minimal module description
              file (module.desc)</b><br>
          </td>
        </tr>
        <tr>
          <td valign="top"><tt>[</tt><tt><br>
                {<br>
                  "module" : "foo",<br>
                  "source" : "foo.cpp",<br>
                  "include_paths" : [<br>
                    "foo/include",<br>
                  ],<br>
                },<br>
            </tt><tt>]</tt><br>
          </td>
        </tr>
      </tbody>
    </table>
    <br>
    This would allow compilers to determine on their own how to
    translate module interface units to resolve module import
    declarations:<br>
    <br>
    <table width="100%" border="1" cellspacing="2" cellpadding="2">
      <tbody>
        <tr>
          <td valign="top"><b>Implementor</b></td>
          <td valign="top"><b>Module style with module description file<br>
            </b></td>
        </tr>
        <tr>
          <td valign="top">Microsoft</td>
          <td valign="top"><tt>$ cl /experimental:module /module:desc module.desc
              t.cpp</tt><tt> foo.lib /FEt.exe<br>
            </tt></td>
        </tr>
        <tr>
          <td valign="top">Clang</td>
          <td valign="top"><tt>$ clang -fmodules-ts -fmodule-desc
              module.desc t.cpp</tt><tt> -lfoo -o t<br>
            </tt></td>
        </tr>
        <tr>
          <td valign="top">Gcc</td>
          <td valign="top"><tt>$ gcc -fmodules-ts</tt><tt><tt>
                -fmodule-desc module.desc </tt> t.cpp</tt><tt> -lfoo -o
              t<br>
            </tt></td>
        </tr>
      </tbody>
    </table>
    <br>
    To be clear, this simplification for compiler invocations is <b>not</b>
    the goal.  In this mode, the compiler would be required to either
    translate the module interface unit directly, identify a previously
    cached module artifact, or produce and consume (and possibly cache)
    a module artifact.  For compilers, it is desirable to be able to
    explicitly control the production and consumption of module
    artifacts for performance reasons.  Note that a build system could
    use the module description and knowledge of a specific compiler to
    generate the compiler invocations needed to produce and consume
    module artifacts (assuming it knows, or can construct, the module
    dependency topology).<br>
    <br>
    The goal is to enable tools that don't require the performance
    advantages (and additional complexity) of module artifacts to be
    able to function at least as well as they traditionally have without
    having to individually configure each tool with the details of every
    module.  The minimal differences between the invocations in the
    "header style" and "module style with module description file"
    examples above is what I want to enable for non-compiler tools
    (particularly, those that are not integrated with "the" build
    system).<br>
    <br>
    Tom.<br>
    <br>
    <blockquote type="cite"
      cite="mid:c65545d4-9dd6-c4e8-99ef-cda2407e8915@honermann.net">
      <br>
      <br>
      <blockquote type="cite">
        <br>
        Code in question...
        <br>
        * Before
        <br>
        #include &lt;iostream&gt;
        <br>
        int main() {std::cout&lt;&lt;"Hello World\n";}
        <br>
        * After
        <br>
        import std.io
        <br>
        int main() {std::cout&lt;&lt;"Hello World\n";}
        <br>
        <br>
        Minimal build process before...
        <br>
        * MSVC
        <br>
        vcvars64.bat
        <br>
        cl /EHs HelloWorld.cpp
        <br>
        HelloWorld.exe
        <br>
        * GCC
        <br>
        g++ HelloWorld.cpp
        <br>
        ./a.out
        <br>
        * Clang
        <br>
        clang HelloWorld.cpp
        <br>
        ./a.out
        <br>
        <br>
        Minimal build process after...
        <br>
        ???
        <br>
        <br>
        <br>
        <blockquote type="cite">-----Original Message-----
          <br>
          From: Ext <a class="moz-txt-link-rfc2396E" href="mailto:ext-bounces@lists.isocpp.org">&lt;ext-bounces@lists.isocpp.org&gt;</a> On Behalf Of
          Tom Honermann
          <br>
          Sent: Friday, August 31, 2018 1:44 PM
          <br>
          To: Nathan Sidwell <a class="moz-txt-link-rfc2396E" href="mailto:nathan@acm.org">&lt;nathan@acm.org&gt;</a>; Evolution Working
          Group mailing list
          <br>
          <a class="moz-txt-link-rfc2396E" href="mailto:ext@lists.isocpp.org">&lt;ext@lists.isocpp.org&gt;</a>; WG21 Tooling Study Group SG15
          &lt;tooling@open-
          <br>
          std.org&gt;
          <br>
          Cc: C++ Library Evolution Working Group
          <a class="moz-txt-link-rfc2396E" href="mailto:lib-ext@lists.isocpp.org">&lt;lib-ext@lists.isocpp.org&gt;</a>
          <br>
          Subject: Re: [Ext] [Tooling] Modules and tooling: Resolving
          module import
          <br>
          declarations
          <br>
          <br>
          On 08/31/2018 01:25 PM, Nathan Sidwell wrote:
          <br>
          <blockquote type="cite">On 08/31/2018 12:05 PM, Tom Honermann
            wrote:
            <br>
            <br>
            <blockquote type="cite">Are you referring to the module
              mapper approach documented at
              <br>
<a class="moz-txt-link-freetext" href="https://urldefense.proofpoint.com/v2/url?u=https-3A__gcc.gnu.org_wiki">https://urldefense.proofpoint.com/v2/url?u=https-3A__gcc.gnu.org_wiki</a>
              <br>
              _cxx-2Dmodules-
              <br>
            </blockquote>
          </blockquote>
          3F&amp;d=DwIGaQ&amp;c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSj
          <br>
          <blockquote type="cite">
            <blockquote type="cite">ixA&amp;r=y8mub81SfUi-UCZRX0Vl1g&amp;m=b-ZgaER9j5-_3U9ipw-k24_LU-
              <br>
            </blockquote>
          </blockquote>
          NTLuokE8b6KU
          <br>
          <blockquote type="cite">
            <blockquote type="cite">Tg86Q&amp;s=i5HfnVg5UjXCB7L7-dyAGSUS4WOGA26soB1m2mk6gRQ&amp;e=
              <br>
            </blockquote>
            That documentation is pretty opaque.  I can only blame
            myself.
            <br>
          </blockquote>
          The fact that documentation for an experimental feature exists
          at all raises
          <br>
          you well above the level at which criticism is justified ;)
          <br>
          <br>
          <blockquote type="cite">
            <blockquote type="cite">If so, my concern with that approach
              is that it effectively requires
              <br>
              a build system.  Perhaps the default module mapper does
              not (I'm not
              <br>
              sure exactly what it does at present.  My brief tests
              indicate it
              <br>
              requires a
              <br>
            </blockquote>
            The defaults it has right now may not be the best defaults. 
            (Hey, you
            <br>
            can go experiment with better defaults!)
            <br>
          </blockquote>
          Indeed, I can - and would like to if this discussion reveals
          an approach that
          <br>
          might have broad agreement.
          <br>
          <br>
          I'm lobbying for a position in which the default behavior is,
          if no suitable
          <br>
          module artifact is identified, identify the module interface
          unit source code
          <br>
          and translate it (produce and discard a module artifact if
          useful; or not).  And
          <br>
          I'm looking for the answers to "where is the module interface
          unit source"
          <br>
          and "how do I translate it" to be available in some industry
          standard tool
          <br>
          agnostic form that doesn't require a running build invocation
          (but can
          <br>
          depend on a prior (partial) build).
          <br>
          <br>
          Tom.
          <br>
          _______________________________________________
          <br>
          Ext mailing list
          <br>
          <a class="moz-txt-link-abbreviated" href="mailto:Ext@lists.isocpp.org">Ext@lists.isocpp.org</a>
          <br>
          Subscription: <a class="moz-txt-link-freetext" href="https://urldefense.proofpoint.com/v2/url?u=http">https://urldefense.proofpoint.com/v2/url?u=http</a>-
          <br>
3A__lists.isocpp.org_mailman_listinfo.cgi_ext&amp;d=DwIGaQ&amp;c=I_0YwoKy7z5L
          <br>
MTVdyO6YCiE2uzI1jjZZuIPelcSjixA&amp;r=y8mub81SfUi-UCZRX0Vl1g&amp;m=b-
          <br>
          ZgaER9j5-_3U9ipw-k24_LU-
          <br>
NTLuokE8b6KUTg86Q&amp;s=wCdzzdGNbO34zKR_3LjCRsXdJkJqhmj9EM_xNrQ1y
          <br>
          4k&amp;e=
          <br>
          Link to this post:
          <a class="moz-txt-link-freetext" href="https://urldefense.proofpoint.com/v2/url?u=http">https://urldefense.proofpoint.com/v2/url?u=http</a>-
          <br>
3A__lists.isocpp.org_ext_2018_08_5718.php&amp;d=DwIGaQ&amp;c=I_0YwoKy7z5L
          <br>
MTVdyO6YCiE2uzI1jjZZuIPelcSjixA&amp;r=y8mub81SfUi-UCZRX0Vl1g&amp;m=b-
          <br>
          ZgaER9j5-_3U9ipw-k24_LU-
          <br>
NTLuokE8b6KUTg86Q&amp;s=qSsZRHLeU9jVHHSr0tACq_IQ9Jl6aL_o9niC9twsUmE
          <br>
          &amp;e=
          <br>
        </blockquote>
        _______________________________________________
        <br>
        Ext mailing list
        <br>
        <a class="moz-txt-link-abbreviated" href="mailto:Ext@lists.isocpp.org">Ext@lists.isocpp.org</a>
        <br>
        Subscription: <a class="moz-txt-link-freetext" href="http://lists.isocpp.org/mailman/listinfo.cgi/ext">http://lists.isocpp.org/mailman/listinfo.cgi/ext</a>
        <br>
        Link to this post: <a class="moz-txt-link-freetext" href="http://lists.isocpp.org/ext/2018/08/5720.php">http://lists.isocpp.org/ext/2018/08/5720.php</a>
        <br>
      </blockquote>
      <br>
      <br>
      _______________________________________________
      <br>
      Ext mailing list
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:Ext@lists.isocpp.org">Ext@lists.isocpp.org</a>
      <br>
      Subscription: <a class="moz-txt-link-freetext" href="http://lists.isocpp.org/mailman/listinfo.cgi/ext">http://lists.isocpp.org/mailman/listinfo.cgi/ext</a>
      <br>
      Link to this post: <a class="moz-txt-link-freetext" href="http://lists.isocpp.org/ext/2018/08/5723.php">http://lists.isocpp.org/ext/2018/08/5723.php</a><br>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>