Robert Ramey wrote:
Peter Dimov-2 wrote
<snip> These headers (along with their dependencies), or some subset of them, can be separated into a "serialization core" module.
OK then the "serialization core" needs tests - right? then wouldn't the serialization core module depend upon the archive part of the serialization library? Wouldn't that suck in the everything else as it does now.
No, test/ is not scanned for dependencies.
if one uses date-time but doesn't include date-time/serialization and everything works - how can one say that date-time is dependent upon the serialization library?
There is no such thing as date-time/serialization at present. It's not possible to not include it. But yes, in principle, if the serialization support were extracted into its own header, it might have been called an "optional dependency".
If one just included the header things might work - until someone needs to actually invoke the serialization of the type - at which case - either you've got a missing function when you try to link or you've had to make the serialization library dependent in any case.
You can't invoke the serialization of the type without having an archive, and if you have an archive, you have to have the rest of Serialization installed, otherwise where did the archive come from?
For what it's worth, the serialization library namespace is already divided into "archive" and "serialization" since the very beginning with the exact idea of separating the serialization from the concept of archive. I caught a huge amount of strident criticism for doing this (much more than the current incident). But It looks to me that things are already structure more or less as you are recommending - but that this doesn't show on the dependency graph...
The two hypothetical modules, 'archive' and 'serialization', would still be dependent on each other, because headers in serialization/ include headers in archive/. It's true that you have tried to keep them separate.
... because the graph tries to implement a concept of module dependency rather than header dependency.
As I have explained many times now, a per-header dependency graph is useless
for practical purposes if modular releases and installations are the goal.
Even if we assume header-only libraries, you still install and uninstall on
a library level, not on a header level; apart from making things needlessly
complicated, the documentation, for instance, can't automagically be split
to only contain whatever portion of the headers you have.
And for libraries that aren't header-only, it doesn't work at all. When the
dependency scanner sees your #include