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