Subject: Re: [boost] [type_traits] Rewrite and dependency free version
From: Peter Dimov (lists_at_[hidden])
Date: 2015-02-02 15:12:51
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
> 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
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 <boost/X/a.hpp>, it has no idea
whether a.hpp contains things that require the library to be built or not.
Therefore, it has to assume that you depend on libs/X/src/*, hence you
require the whole libs/X to be installed.
Doing modular installations on a file level of granularity makes no sense,
which is why no package manager in existence does it (to the best of my
knowledge). They all operate on a package level of granularity, and
therefore their dependency graphs are all on a package level.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk