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

Gabriel Dos Reis gdr at microsoft.com
Fri Aug 31 18:36:58 CEST 2018



| -----Original Message-----
| From: Ext <ext-bounces at lists.isocpp.org> On Behalf Of Jason Merrill
| Sent: Thursday, August 30, 2018 2:43 PM
| To: Evolution Working Group mailing list <ext at lists.isocpp.org>
| Cc: WG21 Tooling Study Group SG15 <tooling at open-std.org>; C++ Library
| Evolution Working Group <lib-ext at lists.isocpp.org>
| Subject: Re: [Ext] Modules and tooling: Resolving module import declarations
| 
| On Wed, Aug 29, 2018 at 1:06 PM, Tom Honermann <tom at honermann.net>
| 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




More information about the Tooling mailing list