Re: [boost] [type_traits] Rewrite and dependency free version

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 
"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 <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.