[Tooling] [Ext] Modules and tooling: Resolving module import declarations

Tom Honermann tom at honermann.net
Fri Aug 31 21:35:01 CEST 2018


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 lists.isocpp.org> On Behalf Of Tom Honermann
>> Sent: Friday, August 31, 2018 1:44 PM
>> To: Nathan Sidwell <nathan at acm.org>; Evolution Working Group mailing list
>> <ext at lists.isocpp.org>; WG21 Tooling Study Group SG15 <tooling at open-
>> std.org>
>> Cc: C++ Library Evolution Working Group <lib-ext at 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 at 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 at 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




More information about the Tooling mailing list