And here is the finished reply:

Tom Honermann <tom_at_[hidden]> writes:

> I believe sharing module artifacts, in any form, will prove to be
> infeasible.

Agree.


> It seems to me that withholding standard library module interface unit
> source code would be rather user hostile and I don't expect any
> implementations to do so;

Agree.


> 2. A method of specifying a path to search for module description
> files, similar to existing include paths.

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?").

This also seems to go against your earlier suggestions:

> 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.

If search paths won't work well for modules why will they work well for
module description files?

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).


> 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.

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.

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:

https://github.com/build2/build2/tree/module-map-dump