On Fri, Oct 15, 2021 at 5:02 PM Gabriel Dos Reis <gdr@microsoft.com> wrote:
I am unsure as to how and why you conclude  that my previous observations were irrelevant  to what is bring proposed.

Perhaps we can try to connect the miscommunication here.

What sort of ideas do you have around managing/creating modulemaps? Currently their design is a single one in a given directory - that doesn't seem like a feasible approach for a distribution format to me, at least - given that each separate library couldn't provide a copy of the file - each one would conflict with others. How're you picturing/proposing this working? If it's separate files per package (perhaps containing multiple module interface definitions) - how would a consumer of an interface module identify which modulemap pertains to the module they want to consume? If it's one per module, how would they locate that modulemap? (what sort of lookup approach would you suggest/propose/have in mind)

I think the summary is: Modulemaps as they exist today don't solve the issues Daniel is trying to address. So if "something like modulemaps, but that does solve the issues proposed" is what you're suggesting, it's not obvious to me at least, what direction/differences/how you're suggesting adapting modulemaps to cover the issues, and what the differences/tradeoffs that would have compared to the proposal so far.

- Dave

-- Gaby

From: Daniel Ruoso <daniel@ruoso.com>
Sent: Friday, October 15, 2021 2:50:44 PM
To: Gabriel Dos Reis <gdr@microsoft.com>
Cc: David Blaikie <dblaikie@gmail.com>; sg15@lists.isocpp.org <sg15@lists.isocpp.org>
Subject: Re: [SG15] P2473R0: Distributing C++ Module Libraries
On Fri, Oct 15, 2021 at 5:00 PM Gabriel Dos Reis <gdr@microsoft.com> wrote:

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

Ok. It doesn't seem like we're talking about the same thing at all. I'll ask for you to please consider taking a new read at both papers, because the point you're trying to make is unrelated to the thing being discussed. The question is not whether or not a map file is a good or a bad way to map from a module name to a bmi file. That's irrelevant to the discussion.

Let me try to formulate a few simple questions that should reframe the conversation in terms of the actual problem that the papers try to address.

 1) Organization A is trying to ship a C++ library that contains modules, how does it advertise which modules the library has? Which files contain the interfaces? How is a compiler supposed to parse those interfaces? Which modules do they depend on? And maybe even, as an optimization, How to ship the BMI file for the compiler the library vendor used (just in case the consumer is using the same compiler)?

 2) Organization B is trying to consume modules from various libraries that are shipped to them as prebuilt artifacts. How is it supposed to know how to find the mappings? or, in case they use a different compiler version, how to produce their own BMI file for those modules?

 3) Organization C is trying to run static analysis on code from organization B that consumes library modules from organization A. How is it that it finds out how to reproduce the parsing context for all the modules required to correctly parse the actual translation units? Especially considering the static analysis tool is not deeply integrated into the build system, and it only observes the build system via artifacts like the compilation database? 

Those are the questions the proposal is trying to answer.