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

Subject: Re: [boost] [modularization] What do we do with "glue" headers?
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-10-19 08:29:19

On 10/19/2013 6:22 AM, 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 agree with what you have said and therefore in some cases it becomes 
wrong to simply move files from one place to another based on a graph of 
header file dependencies. Individual libraries need to be considered.

Regarding the property_map library I was wrong in not noticing that it 
does indeed including graph library headers but I believe I am correct 
in that its files, in a proposed modular Boost, should not be moved with 
those of the graph library. Property maps are an independent concept 
from graphs, even if used by the graph library.

I am actually doing work locally with the property_map library in order 
to move the graph-related distributed headers and specializations to the 
graph library and will report on my results when I am finished. These 
may indeed be "glue" headers but I will argue when I am done, if I am 
successful, that they belong with the graph library.