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

Subject: [boost] [modularization] What do we do with "glue" headers?
From: John Maddock (john_at_[hidden])
Date: 2013-10-19 06:22:58

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

Cheers, John.