<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/31/2018 01:50 PM, Boris Kolpackov
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:boris.20180831194709@codesynthesis.com"><br>
      <blockquote type="cite">
        <pre wrap="">2. A method of specifying a path to search for module description
   files, similar to existing include paths.
</pre>
      </blockquote>
      <pre wrap="">
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 situations) and not toolable ("where should I
generate this non-existent header?").</pre>
    </blockquote>
    <br>
    If there is a better option than search paths, I'm all for it!<br>
    <br>
    <blockquote type="cite"
      cite="mid:boris.20180831194709@codesynthesis.com">
      <pre wrap="">

This also seems to go against your earlier suggestions:

</pre>
      <blockquote type="cite">
        <pre wrap="">Translating module interface unit source code may require different, even
conflicting, include paths and macro definitions.  Thus, configuration will
become more challenging.  I think we should strive for a better solution for
modules.
</pre>
      </blockquote>
      <pre wrap="">
If search paths won't work well for modules why will they work well for
module description files?</pre>
    </blockquote>
    <br>
    Indeed, they may not.<br>
    <br>
    <blockquote type="cite"
      cite="mid:boris.20180831194709@codesynthesis.com">
      <pre wrap="">

My suggestion would be to go for a global "build map" (similar to the
Clang's compilation database), especially since the tools have to work
in the context of a specific build anyway (include search paths, macros,
etc).</pre>
    </blockquote>
    <br>
    I think this is a fruitful direction, but I'm skeptical that a
    single global map suffices unless it can include other maps.  A
    notion that has been raised is that installed components should
    provide a map describing their own usage.<br>
    <br>
    An alternative to a search path would be a list of build maps.<br>
    <br>
    <blockquote type="cite"
      cite="mid:boris.20180831194709@codesynthesis.com">
      <pre wrap="">


</pre>
      <blockquote type="cite">
        <pre wrap="">Note that such module description files need not be statically written and
maintained.  They could be generated directly by a build system, or as a
side effect of compilation.
</pre>
      </blockquote>
      <pre wrap="">
I would change "need not" to "should not" and "could" to "should": it will
be really painful to maintain manually for any non-trivial project and the
build system has all this information readily available.</pre>
    </blockquote>
    <br>
    In the world I'm envisioning, build systems consume this information
    (though it may also be generated and maintained by a build system).<br>
    <br>
    <blockquote type="cite"
      cite="mid:boris.20180831194709@codesynthesis.com">
      <pre wrap="">

As a proof of concept I just "instrumented" (euphemism for "hacked") build2
to dump something along what you are proposing. Here is a sample run for VC:

std.core libstd-modules/libstd-modules/std-core.mxx msvc /std:c++latest /D__cpp_modules=201704 /experimental:module -Ilibstd-modules
std.io libstd-modules/libstd-modules/std-io.mxx msvc /std:c++latest /D__cpp_modules=201704 /experimental:module -Ilibstd-modules
std.regex libstd-modules/libstd-modules/std-regex.mxx msvc /std:c++latest /D__cpp_modules=201704 /experimental:module -Ilibstd-modules
std.threading libstd-modules/libstd-modules/std-threading.mxx msvc /std:c++latest /D__cpp_modules=201704 /experimental:module -Ilibstd-modules
hello libmhello/libmhello/hello.mxx msvc /std:c++latest /D__cpp_modules=201704 /experimental:module

And this is for Clang:

std.core libstd-modules/libstd-modules/std-core.mxx clang -std=c++2a -D__cpp_modules=201704 -fmodules-ts -Ilibstd-modules
std.io libstd-modules/libstd-modules/std-io.mxx clang -std=c++2a -D__cpp_modules=201704 -fmodules-ts -Ilibstd-modules
std.regex libstd-modules/libstd-modules/std-regex.mxx clang -std=c++2a -D__cpp_modules=201704 -fmodules-ts -Ilibstd-modules
std.threading libstd-modules/libstd-modules/std-threading.mxx clang -std=c++2a -D__cpp_modules=201704 -fmodules-ts -Ilibstd-modules
hello libmhello/libmhello/hello.mxx clang -std=c++2a -D__cpp_modules=201704 -fmodules-ts

The third column is the compiler id to help interpret the options that follow.
Here is the branch if anyone is interested:

<a class="moz-txt-link-freetext" href="https://github.com/build2/build2/tree/module-map-dump">https://github.com/build2/build2/tree/module-map-dump</a></pre>
    </blockquote>
    <br>
    Nice!  Improvements that would move this more towards the problems I
    want to solve include:<br>
    <ul>
      <li>Express the requirements in a tool agnostic form.</li>
      <li>Support multiple build modes or module variants.<br>
      </li>
    </ul>
    I'm thinking of something more similar in spirit to Clang's module
    map files [1].  For example, in a JSON format:<br>
    <blockquote><tt>[<br>
          {<br>
            "module" : "std.core",<br>
            "source" : "libstd-modules/std-core.mxx",<br>
            "requires" : [<br>
              "cplusplus20",<br>
              "coroutines",<br>
      </tt><tt>    ],<br>
            "include_paths" : [<br>
              "libstd-modules/include",</tt><br>
      <tt><tt>      "libstd-modules/include/detail",<br>
        </tt>    ],<br>
            "build_modes" : [</tt><tt><br>
              "debug" : {<br>
                "macros" : [<br>
                  "_LIBCPP_DEBUG" : "1",<br>
                ],<br>
              },<br>
              "release" : {<br>
                "macros" : [<br>
                  "_LIBCPP_DEBUG" : "0",<br>
                },<br>
              },<br>
            ],<br>
          },</tt><tt><br>
        ]</tt><br>
    </blockquote>
    Build mode support will require considerably more thought, but I
    think is important.<br>
    <br>
    Tom.<br>
    <br>
    [1]: <a class="moz-txt-link-freetext" href="https://clang.llvm.org/docs/Modules.html#module-map-language">https://clang.llvm.org/docs/Modules.html#module-map-language</a><br>
  </body>
</html>