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.cpp foo.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@lists.isocpp.org> On Behalf Of Tom Honermann
Sent: Friday, August 31, 2018 1:44 PM
To: Nathan Sidwell <nathan@acm.org>; Evolution Working Group mailing list
<ext@lists.isocpp.org>; WG21 Tooling Study Group SG15 <tooling@open-
std.org>
Cc: C++ Library Evolution Working Group <lib-ext@lists.isocpp.org>
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@lists.isocpp.org
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@lists.isocpp.org
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@lists.isocpp.org
Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/ext
Link to this post: http://lists.isocpp.org/ext/2018/08/5723.php