Maybe, for the benefit of "the rest of us" you might jointly compose a
*brief* explanation of what problems have to be addressed and what
alternatives there are. Eventually, the basic idea of the adopted
standard (assuming we can agree on one) should be explainable to novices
in a single short paragraph.


On 10/15/2021 8:56 PM, David Blaikie via SG15 wrote:
> 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.
>
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15