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

Subject: Re: [boost] [modularization] What do we do with "glue" headers?
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2013-10-19 07:14:29

On 10/19/2013 12:22 PM, 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).

Could such glue headers simply be considered separate components by the 
dependency scanning as their dependencies do not incur as dependency 
before they are actually included in application source.

B --> core
A_with_B_glue --> core
A_with_B_glue --> B

becomes:

A --> core
B --> core
AB_glue --> A
AB_glue --> B

Whether these should belong in one of the git repositories of which main 
libraries they depend on or somewhere else is a different question that 
has more to do more software configuration management than component 
dependencies.  I am trying to say it may not be important to move those 
headers.

--
Bjørn