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

Tom Honermann tom at honermann.net
Fri Aug 31 18:05:38 CEST 2018


On 08/31/2018 07:53 AM, Nathan Sidwell wrote:
> On 08/31/2018 07:09 AM, Boris Kolpackov wrote:
>> Message-ID: <boris.20180831104601 at codesynthesis.com>
>>
>> Tom Honermann <tom at honermann.net> writes:
>
>>> 2. A method of specifying a path to search for module description
>>>     files, similar to existing include paths.
>>
>> I would argue against any kind of "search paths" approach (whether for
>> modules or description files themselves). We've used them for includes
>> and I think it has proven to be brittle (I am talking about the "header
>> doesn't exist where you expect it to exist but the compiler found you
>> another one" kind of situtions) and not toolable (where shoudl I 
>> generate
>> this non-existent header?)
>
> A search path seems the obvious choice, because of the similarity to 
> include paths.  It is the route I originally went down.  It's a trap! 
> As Boris says, it's brittle.  It continues the performance problems of 
> searching a bunch of filesystem locations for each import.
>
> I abandoned that approach for an interface allowing the compiler to be 
> agnostic, and other tools to plug into that.  Expect a paper for San 
> Diego.

Are you referring to the module mapper approach documented at 
https://gcc.gnu.org/wiki/cxx-modules?

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 
<module>.nms file to exist in gcc's current working directory).  What 
I'd like is for the default module mapper to use a common tool agnostic 
approach that does not require build system integration, nor precompiled 
artifacts.  Repeating a point I'm trying to make, use of module 
artifacts should be an optimization opportunity, not a requirement.

Tom.


More information about the Tooling mailing list