On Fri, Oct 15, 2021 at 1:18 PM Daniel Ruoso via SG15 <sg15_at_[hidden]>
wrote:

> On Fri, Oct 15, 2021 at 4:12 PM Gabriel Dos Reis <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 )

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.