On 7/21/23 10:57, Ben Boeckel wrote:
On Thu, Jul 20, 2023 at 17:00:32 -0400, Nathan Sidwell wrote:
On 7/19/23 20:47, Ben Boeckel wrote:
But it is inhibiting distributed builds because the distributing tool
would need to know:
- what CMIs are actually imported (here, "read the module mapper file"
(in CMake's case, this is only the modules that are needed; a single
massive mapper file for an entire project would have extra entries) or
"act as a proxy for the socket/program specified" for other
approaches);
This information is in the machine (& human) README section of the CMI.
Ok. That leaves it up to distributing build tools to figure out at
least.
- read the CMIs as it sends to the remote side to gather any other CMIs
that may be needed (recursively);
Contrast this with the MSVC and Clang (17+) mechanism where the command
line contains everything that is needed and a single bolus can be sent.
um, the build system needs to create that command line? Where does the build
system get that information? IIUC it'll need to read some file(s) to do that.
It's chained through the P1689 information in the collator as needed. No
extra files need to be read (at least with CMake's approach); certainly
not CMI files.
It occurs to me that the model I am envisioning is similar to CMake's object
libraries. Object libraries are a convenient name for a bunch of object files.
IIUC they're linked by naming the individual object files (or I think the could
be implemented as a static lib linked with --whole-archive path/to/libfoo.a
-no-whole-archive. But for this conversation consider them a bunch of separate
object files with a convenient group name.
Consider also that object libraries could themselves contain object libraries (I
don't know of they can, but it seems like a useful concept). Then one could
create an object library from a collection of object files and object libraries
(recursively). CMake would handle the transitive gtaph.
Now, allow an object library to itself have some kind of tangible, on-disk
representation. *BUT* not like a static library -- it doesn't include the
object files.
Now that immediately maps onto modules.
CMI: Object library
Direct imports: Direct object libraries of an object library
This is why I don't understand the need explicitly indicate the indirect imports
of a CMI. CMake knows them, because it knows the graph.
And relocatable is probably fine. How does it interact with reproducible
builds? Or are GCC CMIs not really something anyone should consider for
installation (even as a "here, maybe this can help consumers"
mechanism)?
Module CMIs should be considered a cacheable artifact. They are neither object
files nor source files.
Sure, cachable sounds fine. What about the installation?
--Ben
--
Nathan Sidwell
