On 08/30/2018 05:42 PM, Jason Merrill wrote:
> 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. This does need a naming convention, as you say.

That seems reasonable to me, but doesn't address the question of how to
determine what preprocessor and language options are required to
translate the module interface unit source.

Some possible complications:

  * Compilation of a module interface unit may produce an object file as
    well as a module artifact. Some code organization guidelines may
    object to source code requiring compilation being placed in
    directories with public header files (they could, of course, be
    placed in separate directories that are added to the include path).
  * Module names are case-sensitive, file names may not be. I would
    hope that module names that differ only in case would be rare
    outside of pathological test cases and therefore not much of a
    concern. Regardless, today, #include <header> and #include <HEADER>
    may denote the same header, but 'import M' and 'import m' do not
    denote the same module.

Tom.