On Fri, Oct 15, 2021 at 5:02 PM Gabriel Dos Reis <gdr_at_[hidden]> 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_at_[hidden]>
> *Sent:* Friday, October 15, 2021 2:50:44 PM
> *To:* Gabriel Dos Reis <gdr_at_[hidden]>
> *Cc:* David Blaikie <dblaikie_at_[hidden]>; sg15_at_[hidden] <
> sg15_at_[hidden]>
> *Subject:* Re: [SG15] P2473R0: Distributing C++ Module Libraries
>
> On Fri, Oct 15, 2021 at 5:00 PM Gabriel Dos Reis <gdr_at_[hidden]>
> 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.
>