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.

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