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

Gabriel Dos Reis gdr at microsoft.com
Fri Aug 31 19:07:45 CEST 2018


[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.

-- Gaby



More information about the Tooling mailing list