C++ Logo


Advanced search

Re: [SG15] P2473R0: Distributing C++ Module Libraries

From: David Blaikie <dblaikie_at_[hidden]>
Date: Fri, 15 Oct 2021 13:41:11 -0700
On Fri, Oct 15, 2021 at 1:18 PM Daniel Ruoso via SG15 <sg15_at_[hidden]>

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

Received on 2021-10-15 15:41:24