On 08/31/2018 01:50 PM, Boris Kolpackov wrote:
>
>> 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?").

If there is a better option than search paths, I'm all for it!

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

Indeed, they may not.

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

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.

An alternative to a search path would be a list of build maps.

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

In the world I'm envisioning, build systems consume this information
(though it may also be generated and maintained by a build system).

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

Nice! Improvements that would move this more towards the problems I
want to solve include:

  * Express the requirements in a tool agnostic form.
  * Support multiple build modes or module variants.

I'm thinking of something more similar in spirit to Clang's module map
files [1]. For example, in a JSON format:

    [
       {
         "module" : "std.core",
         "source" : "libstd-modules/std-core.mxx",
         "requires" : [
           "cplusplus20",
           "coroutines",
         ],
         "include_paths" : [
           "libstd-modules/include",
           "libstd-modules/include/detail",
         ],
         "build_modes" : [
           "debug" : {
             "macros" : [
               "_LIBCPP_DEBUG" : "1",
             ],
           },
           "release" : {
             "macros" : [
               "_LIBCPP_DEBUG" : "0",
             },
           },
         ],
       },
    ]

Build mode support will require considerably more thought, but I think
is important.

Tom.

[1]: https://clang.llvm.org/docs/Modules.html#module-map-language