On 7/23/23 20:26, Ben Boeckel wrote:
On Fri, Jul 21, 2023 at 16:23:07 -0400, Nathan Sidwell wrote:
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.
Yes, `--whole-archive` would work great if it had any kind of
portability across CMake's platform set.
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.
I think this detail is relevant, but you can use
`$<TARGET_OBJECT:subobjlib>` as an `INTERFACE` sources and it would act
like that, but it is an explicit thing. Instead, `OBJECT` libraries
*only* provide their objects to targets that *directly* link them. If
not, given this:
A (OBJECT library)
B (library of some kind; links PUBLIC to A)
C (links to B)
If `A` has things like linker flags (or, more likely, libraries) as part
of its usage requirements, C will get them on is link line. However, if
OBJECT files are transitive in the same way, the linker (on most
platforms at least) chokes because it now has duplicates of all of A's
symbols: those from the B library and those from A's objects on the link
line.
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.
Sure, *CMake* knows them, but the *build tool* needs to be told
(typically `make` or `ninja`) because it is what is actually executing
the build graph. The way this is communicated is via `-MF` files and
that's what I'm providing in this patch. Note that `ninja` does not
allow rules to specify such dependencies for other rules than the one it
is reading the file for.
But since the direct imports need to be rebuilt themselves if the
transitive imports change, the build graph should be the same whether or
not the transitive imports are repeated? Either way, if a transitive
import changes you need to rebuild the direct import and then the importer.
I guess it shouldn't hurt to have the transitive imports in the -MF
file, as long as they aren't also in the p1689 file, so I'm not
particularly opposed to this change, but I don't see how it makes a
practical difference.
Jason
