[PATCH v5 4/5] c++modules: report imported CMI files as dependencies
Nathan Sidwell
nathan@acm.org
Fri Jul 21 20:23:07 GMT 2023
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
More information about the Gcc
mailing list