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

Tom Honermann tom at honermann.net
Sat Sep 1 01:14:29 CEST 2018


On 08/31/2018 01:07 PM, Gabriel Dos Reis via Ext wrote:
> [Boris]
>
> | > 1. A (set of) module description file(s) that specifies:
> | >     1. A map from a module name to the file name for the module
> | >        interface unit source code.  A default naming convention could
> | >        also be adopted, though we already have two competing
> | >        conventions (.cppm vs .ixx).
> | >     2. A set of requirements for translating the module interface unit
> | >        source code (for one or more variations or build modes).  This
> | >        includes preprocessor information (include paths, macro
> | >        definitions, macro undefinitions), and, potentially, language
> | >        dialect requirements (specified in a generic form and, perhaps,
> | >        with the ability to customize for specific tools).
> | > 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?)
>
> Strongly seconded.
>
> One of the early decisions - based on decades of experience - for the Microsoft implementation
> is to
>     1. dissociate module-names from file-names
>     2. not rely on search paths, because of the associated havoc they cause
>
> Hence the "/module:reference" option.
> However, some people liked the "convenience" of search path for small examples, so we added the "/module:search" option.
>
> The Microsoft recommendation to its customers is to strongly prefer file mapping references over search paths.

And that makes tons of sense to me when considering use of a specific 
tool with support for module artifacts.  The question I'm trying to get 
at is, where does the information used to construct those options come 
from?  The obvious answer is, of course, the build system.  The problem 
I want to solve is how to enable tools that are not integrated with 
"the" build system without requiring elaborate tool and code base 
specific configuration.  Essentially, to reduce the tool (M) by code 
base (N) order MxN configuration problem to an order N problem.

Tom.


More information about the Tooling mailing list