On 7/19/23 20:47, Ben Boeckel wrote:
On Wed, Jul 19, 2023 at 17:11:08 -0400, Nathan Sidwell wrote:
GCC is neither of these descriptions. a CMI does not contain the transitive
closure of its imports. It contains an import table. That table lists the
transitive closure of its imports (it needs that closure to do remapping), and
that table contains the CMI pathnames of the direct imports. Those pathnames
are absolute, if the mapper provded an absolute pathm or relative to the CMI
repo.
The rationale here is that if you're building a CMI, Foo, which imports a bunch
of modules, those imported CMIs will have the same (relative) location in this
compilation and in compilations importing Foo (why would you move them?) Note
this is NOT inhibiting relocatable builds, because of the CMI repo.
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.
- 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.
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.
On 7/18/23 20:01, Ben Boeckel wrote:
Maybe I'm missing how this *actually* works in GCC as I've really only
interacted with it through the command line, but I've not needed to
mention `a.cmi` when compiling `use.cppm`. Is `a.cmi` referenced and
read through some embedded information in `b.cmi` or does `b.cmi`
include enough information to not need to read it at all? If the former,
distributed builds are going to have a problem knowing what files to
send just from the command line (I'll call this "implicit thin"). If the
latter, that is the "fat" CMI that I'm thinking of.
please don't use perjorative terms like 'fat' and 'thin'.
Sorry, I was internally analogizing to "thinLTO".
--Ben
--
Nathan Sidwell
