[David]

  * Gaby: What "module map file approach" are you referring to - could you provide more details or a link? Do you mean something like (or exactly) Clang's .modulemap files, for instance? ( https://clang.llvm.org/docs/Modules.html#module-maps<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclang.llvm.org%2Fdocs%2FModules.html%23module-maps&data=04%7C01%7Cgdr%40microsoft.com%7Cd43396c1f0054b9852bc08d9901c2691%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637699272877402361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7J9TqJIS%2Fo1HqUd2uIBiz3q1krwPsgKEkw8D5JUEftI%3D&reserved=0> )

I am thinking, indeed, of a subset of the facilities in the Clang's modulemap experiment: a mapping from a module name to where to find the corresponding BMI - no filesystrem poking adventure to discover something. It wouldn't shut down the door to possible multiple module interface stored in the same file. I am unsure of why that is considered "extra complexity".

-- Gaby


From: David Blaikie <dblaikie_at_[hidden]>
Sent: Friday, October 15, 2021 1:41 PM
To: sg15_at_[hidden]
Cc: Gabriel Dos Reis <gdr_at_[hidden]>; Daniel Ruoso <daniel_at_[hidden]>
Subject: Re: [SG15] P2473R0: Distributing C++ Module Libraries



On Fri, Oct 15, 2021 at 1:18 PM Daniel Ruoso via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> wrote:
On Fri, Oct 15, 2021 at 4:12 PM Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:

  * [1] which wouldn't preclude the support for module map files, in fact I can see a build system build a module map file for the local modules with a fallback to path-based lookup for external libraries
Why is the module map file approach being discounted or not pursued in favor of the current proposal?

I think there's a misunderstanding here.

The question is: on an arbitrary system with arbitrary libraries being made available to the build system as pre-built artifacts, how is the module map going to be assembled for a given translation that depends on modules provided by those external libraries?

Might be some talking past each other here, maybe?

Gaby: What "module map file approach" are you referring to - could you provide more details or a link? Do you mean something like (or exactly) Clang's .modulemap files, for instance? ( https://clang.llvm.org/docs/Modules.html#module-maps<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclang.llvm.org%2Fdocs%2FModules.html%23module-maps&data=04%7C01%7Cgdr%40microsoft.com%7Cd43396c1f0054b9852bc08d9901c2691%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637699272877402361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7J9TqJIS%2Fo1HqUd2uIBiz3q1krwPsgKEkw8D5JUEftI%3D&reserved=0> )

I think one of the problems with modulemap files is that you can only have one per directory (module.modulemap) for discovery - so that's perhaps what Daniel's responding to: How do you build the modulemap for your system if you were to do this - since you'd have a bunch of different libraries that all need to share a single module.modulemap file, I think?

If we had one modulemap per public interface unit thingy - then that's roughly what Daniel's proposing, I think. A way to map them to the filesystem/find associated instructions next to the module interface file.