<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 08/30/2018 05:42 PM, Jason Merrill
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CADzB+2mdDdqzY9DJTRQBLy9aEmwBcH5Q3FKXT_3gtsXuKAZDSQ@mail.gmail.com">
      <pre wrap="">On Wed, Aug 29, 2018 at 1:06 PM, Tom Honermann <a class="moz-txt-link-rfc2396E" href="mailto:tom@honermann.net">&lt;tom@honermann.net&gt;</a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
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.</pre>
    </blockquote>
    <br>
    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.<br>
    <br>
    Some possible complications:<br>
    <ul>
      <li>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).<br>
      </li>
      <li>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 &lt;header&gt; and
        #include &lt;HEADER&gt; may denote the same header, but 'import
        M' and 'import m' do not denote the same module.<br>
      </li>
    </ul>
    Tom.<br>
  </body>
</html>