Re: [PATCH v5 4/5] c++modules: report imported CMI files as dependencies

[Nathan Sidwell <nathan@acm.org>]

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