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.