[Tooling] [Ext] Modules and tooling: Resolving module import declarations

Tom Honermann tom at honermann.net
Sat Sep 1 01:08:29 CEST 2018


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/tooling/attachments/20180831/41bf20b6/attachment.html 


More information about the Tooling mailing list