On 08/31/2018 03:35 PM, Tom Honermann wrote:
> On 08/31/2018 03:09 PM, Ben Craig wrote:
>> Maybe it's too soon for this, but can I see a Tony table for the
>> build process? I can even start...
>
> 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.

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.

*Implementation*
 *Header style*
 *Module style*

 // foo.h
#include <foo/detail.h>
...
void foo();
...

// foo.cpp
void foo() { ... }

// t.cpp
#include <foo.h>
int main() { foo(); } // foo.cpp
module;
#include <foo/detail.h>
export module foo;
...
export void foo() { ... }
...


// t.cpp
import foo;
int main() { foo(); }
Microsoft
 $ cl /Ifoo/include t.cpp foo.lib /Fet.exe
 $ cl /experimental:module /module:interface /c /Ifoo/include foo.cpp #
generates foo.ifc
$ cl /experimental:module /module:reference m.ifc t.cpp foo.lib /Fet.exe
Clang
 $ clang -Ifoo/include t.cpp-lfoo -o t
 $ clang -fmodules-ts --precompile -Ifoo/include foo.cpp -o foo.pcm#
generates foo.pcm
$ clang -fmodules-ts -fmodule-file=foo.pcm t.cpp-lfoo -o t
Gcc
 $ gcc -Ifoo/include t.cpp -lfoo -o t
 $ gcc -fmodules-ts -c Ifoo/include foo.cpp # generates foo.nms (and
unused foo.o)
$ gcc -fmodules-ts t.cpp -lfoo -o t # implicitly searches for foo.nms


Now assume the existence of a module description file similar to:

*Hypothetical minimal module description file (module.desc)*
[
   {
     "module" : "foo",
     "source" : "foo.cpp",
     "include_paths" : [
       "foo/include",
     ],
   },
]


This would allow compilers to determine on their own how to translate
module interface units to resolve module import declarations:

*Implementor* *Module style with module description file
*
Microsoft $ cl /experimental:module /module:desc module.desc
t.cppfoo.lib /FEt.exe
Clang $ clang -fmodules-ts -fmodule-desc module.desc t.cpp-lfoo -o t
Gcc $ gcc -fmodules-ts-fmodule-desc module.desc t.cpp-lfoo -o t


To be clear, this simplification for compiler invocations is *not* 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).

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).

Tom.

>
>
>>
>> Code in question...
>> * Before
>> #include <iostream>
>> int main() {std::cout<<"Hello World\n";}
>> * After
>> import std.io
>> int main() {std::cout<<"Hello World\n";}
>>
>> Minimal build process before...
>> * MSVC
>> vcvars64.bat
>> cl /EHs HelloWorld.cpp
>> HelloWorld.exe
>> * GCC
>> g++ HelloWorld.cpp
>> ./a.out
>> * Clang
>> clang HelloWorld.cpp
>> ./a.out
>>
>> Minimal build process after...
>> ???
>>
>>
>>> -----Original Message-----
>>> From: Ext <ext-bounces_at_[hidden]> On Behalf Of Tom Honermann
>>> Sent: Friday, August 31, 2018 1:44 PM
>>> To: Nathan Sidwell <nathan_at_[hidden]>; Evolution Working Group mailing
>>> list
>>> <ext_at_[hidden]>; WG21 Tooling Study Group SG15 <tooling_at_open-
>>> std.org>
>>> Cc: C++ Library Evolution Working Group <lib-ext_at_[hidden]>
>>> Subject: Re: [Ext] [Tooling] Modules and tooling: Resolving module
>>> import
>>> declarations
>>>
>>> On 08/31/2018 01:25 PM, Nathan Sidwell wrote:
>>>> On 08/31/2018 12:05 PM, Tom Honermann wrote:
>>>>
>>>>> Are you referring to the module mapper approach documented at
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__gcc.gnu.org_wiki
>>>>> _cxx-2Dmodules-
>>> 3F&d=DwIGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSj
>>>>> ixA&r=y8mub81SfUi-UCZRX0Vl1g&m=b-ZgaER9j5-_3U9ipw-k24_LU-
>>> NTLuokE8b6KU
>>>>> Tg86Q&s=i5HfnVg5UjXCB7L7-dyAGSUS4WOGA26soB1m2mk6gRQ&e=
>>>> That documentation is pretty opaque. I can only blame myself.
>>> The fact that documentation for an experimental feature exists at
>>> all raises
>>> you well above the level at which criticism is justified ;)
>>>
>>>>> If so, my concern with that approach is that it effectively requires
>>>>> a build system. Perhaps the default module mapper does not (I'm not
>>>>> sure exactly what it does at present. My brief tests indicate it
>>>>> requires a
>>>> The defaults it has right now may not be the best defaults. (Hey, you
>>>> can go experiment with better defaults!)
>>> Indeed, I can - and would like to if this discussion reveals an
>>> approach that
>>> might have broad agreement.
>>>
>>> I'm lobbying for a position in which the default behavior is, if no
>>> suitable
>>> module artifact is identified, identify the module interface unit
>>> source code
>>> and translate it (produce and discard a module artifact if useful;
>>> or not). And
>>> I'm looking for the answers to "where is the module interface unit
>>> source"
>>> and "how do I translate it" to be available in some industry
>>> standard tool
>>> agnostic form that doesn't require a running build invocation (but can
>>> depend on a prior (partial) build).
>>>
>>> Tom.
>>> _______________________________________________
>>> Ext mailing list
>>> Ext_at_[hidden]
>>> Subscription: https://urldefense.proofpoint.com/v2/url?u=http-
>>> 3A__lists.isocpp.org_mailman_listinfo.cgi_ext&d=DwIGaQ&c=I_0YwoKy7z5L
>>> MTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=b-
>>> ZgaER9j5-_3U9ipw-k24_LU-
>>> NTLuokE8b6KUTg86Q&s=wCdzzdGNbO34zKR_3LjCRsXdJkJqhmj9EM_xNrQ1y
>>> 4k&e=
>>> Link to this post: https://urldefense.proofpoint.com/v2/url?u=http-
>>> 3A__lists.isocpp.org_ext_2018_08_5718.php&d=DwIGaQ&c=I_0YwoKy7z5L
>>> MTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=b-
>>> ZgaER9j5-_3U9ipw-k24_LU-
>>> NTLuokE8b6KUTg86Q&s=qSsZRHLeU9jVHHSr0tACq_IQ9Jl6aL_o9niC9twsUmE
>>> &e=
>> _______________________________________________
>> Ext mailing list
>> Ext_at_[hidden]
>> Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/ext
>> Link to this post: http://lists.isocpp.org/ext/2018/08/5720.php
>
>
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]
> Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/ext
> Link to this post: http://lists.isocpp.org/ext/2018/08/5723.php