| -----Original Message-----
| From: Ext <ext-bounces_at_[hidden]> On Behalf Of Jason Merrill
| Sent: Thursday, August 30, 2018 2:43 PM
| To: Evolution Working Group mailing list <ext_at_[hidden]>
| Cc: WG21 Tooling Study Group SG15 <tooling_at_[hidden]>; C++ Library
| Evolution Working Group <lib-ext_at_[hidden]>
| Subject: Re: [Ext] Modules and tooling: Resolving module import declarations
|
| On Wed, Aug 29, 2018 at 1:06 PM, Tom Honermann <tom_at_[hidden]>
| wrote:
| > What might such an industry standard approach look like? Here is a sketch
| > of a design:
| >
| > A (set of) module description file(s) that specifies:
| >
| > 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).
| > 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).
| >
| > A method of specifying a path to search for module description files,
| > similar to existing include paths.
|
| I have figured that module interface unit source code would be found
| on the existing include paths if no suitable compiled form is
| available.

Agreed.

| This does need a naming convention, as you say.

That does not necessarily follow. All that is needed is a mapping - that mapping could be naming convention, or literally a mapping stored in a file or some other form.

-- Gaby