Re: [boost] [modularization] What do we do with "glue" headers?

Subject: Re: [boost] [modularization] What do we do with "glue" headers?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-10-19 07:03:52

On Saturday 19 October 2013 11:22:58 John Maddock wrote:
> Trying to get this discussion somewhat back on track...
> 
> There are many libraries in Boost that have "glue" headers: by this I mean
> small headers that allow library A to interoperate with library B.  Often
> these are simply specializations of traits classes or function overloads,
> are relatively trivial, and are not included unless you need them to be.  By
> this I mean that: suppose library B wants to interoperate with lib A.  It
> defines a special header which #includes what it needs from lib A and
> defines whatever specializations are required to get the two libraries
> working together.
> 
> Now here's the thing: there is no dependency from lib B to lib A *unless you
> are already using both libraries*.
> 
> A good example would be the serialization lib: a simple dependency tracker
> would show this up as a dependency to a large part of Boost, but in fact
> that's not true: in the vast majority of those cases there is no such
> dependency unless you actually want to use both libraries together and do so
> by including the "glue" header.
> 
> So where does the glue header belong?
> 
> In most cases if you want B to interoperate with A then you define a header
> which:
> 
> * Includes headers from both libraries.
> * Uses the public interface of A, but may access the internals of B (think
> serialization).
> 
> Which would imply that the header belongs with B.  Pure and simple.  Except
> it's not, because these two libraries may be peers, and interoperability may
> be more complex than simply unidirectional.
> 
> I don't have an answer here, but it seems to me that "dependency" is a more
> complex thing than simply what-includes-what (and that's without getting
> into header file, vs source file, vs test file dependencies).

I think a notion of an optional dependency is needed. I don't know how such 
dependencies should be expresses in the technical sense though. Ideally, ryppl 
(or whatever other dependency tracking system) should offer a way to select 
the dependencies to install.