On Sat, Oct 16, 2021, 11:14 Bjarne Stroustrup via SG15 <
sg15_at_[hidden]> wrote:

> Maybe, for the benefit of "the rest of us" you might jointly compose a
> *brief* explanation of what problems have to be addressed
>

The first paper we discussed last month covered the requirements. As stated
on the abstract of this paper, it is meant as a proposal to address the
requirements laid out in the first.

But, I'll try to summarize the questions we're trying to answer one more
time:

 1) how does an organization distribute a C++ module library as a prebuilt
artifact to another organization that may use a different, but ABI
compatible, compiler?

 2) how does an organization that consumes prebuilt C++ module libraries
from other organizations discover where the modules are and how they are
supposed to be parsed in order to produce the BMI for the current compiler?

 3) how does an organization perform static analysis on a project producing
and consuming modules without having to do a tightly coupled integration
with the build system? (This is something that can be achieved today with
the compilation database).

and what alternatives there are.
>
So far, the implementations have focused only on situations where the build
system has full control over all the source code providing and consuming
modules.

There currently is no implementations that would work for C++ module
libraries in, for instance, a Linux distribution.

> Eventually, the basic idea of the adopted standard (assuming we can agree
> on one) should be explainable to novices in a single short paragraph.
>
The proposed convention of this paper is: you can map the module name to a
file name, and you look it up based on a module search path.

Daniel