<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 <foo/detail.h><br>
...<br>
</tt></tt>void foo();<br>
...<br>
<br>
// foo.cpp</tt><tt><tt><br>
void foo() { ... }<br>
<br>
</tt>// t.cpp<br>
#include <foo.h>
</tt><tt><br>
</tt><tt>int main() { foo(); }
</tt></td>
<td valign="top"><tt>// foo.cpp<br>
module;<br>
#include <foo/detail.h><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 <iostream>
<br>
int main() {std::cout<<"Hello World\n";}
<br>
* After
<br>
import std.io
<br>
int main() {std::cout<<"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"><ext-bounces@lists.isocpp.org></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"><nathan@acm.org></a>; Evolution Working
Group mailing list
<br>
<a class="moz-txt-link-rfc2396E" href="mailto:ext@lists.isocpp.org"><ext@lists.isocpp.org></a>; WG21 Tooling Study Group SG15
<tooling@open-
<br>
std.org>
<br>
Cc: C++ Library Evolution Working Group
<a class="moz-txt-link-rfc2396E" href="mailto:lib-ext@lists.isocpp.org"><lib-ext@lists.isocpp.org></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&d=DwIGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSj
<br>
<blockquote type="cite">
<blockquote type="cite">ixA&r=y8mub81SfUi-UCZRX0Vl1g&m=b-ZgaER9j5-_3U9ipw-k24_LU-
<br>
</blockquote>
</blockquote>
NTLuokE8b6KU
<br>
<blockquote type="cite">
<blockquote type="cite">Tg86Q&s=i5HfnVg5UjXCB7L7-dyAGSUS4WOGA26soB1m2mk6gRQ&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&d=DwIGaQ&c=I_0YwoKy7z5L
<br>
MTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=b-
<br>
ZgaER9j5-_3U9ipw-k24_LU-
<br>
NTLuokE8b6KUTg86Q&s=wCdzzdGNbO34zKR_3LjCRsXdJkJqhmj9EM_xNrQ1y
<br>
4k&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&d=DwIGaQ&c=I_0YwoKy7z5L
<br>
MTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=b-
<br>
ZgaER9j5-_3U9ipw-k24_LU-
<br>
NTLuokE8b6KUTg86Q&s=qSsZRHLeU9jVHHSr0tACq_IQ9Jl6aL_o9niC9twsUmE
<br>
&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>