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

Subject: Re: [boost] [modularization] What do we do with "glue" headers?
From: Daniel Pfeifer (daniel_at_[hidden])
Date: 2013-10-19 09:37:48

2013/10/19 Andrey Semashev <andrey.semashev_at_[hidden]>:
> 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.

I agree.