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 12:34:18

2013/10/19 Vicente J. Botet Escriba <vicente.botet_at_[hidden]>:
> Le 19/10/13 15:58, Daniel Pfeifer a écrit :
>>
>> 2013/10/19 Andrey Semashev <andrey.semashev_at_[hidden]>:
>>
>>> 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.
>>
>> Lets use the example of Boost.UUID and Boost.Serialization.
>>
>> My gut-feeling says that serialization support for UUID belongs to
>> UUID. But lets consider the alternatives:
>>
>> If serialization support for all libraries belongs to Serialization,
>> the Serialization library is required to keep serialization support
>> updated for all current and future Boost libraries.
>
> Agreed, this could not work.
>
>>
>> If we say the glue code shall be a distinct component, we and up with
>> an explosion of glue-components, one for each edge in the worst case.
>
> If you don't add the glue-component either you don't have the information of
> the possible added dependencies or you add them to the UUID component :( The
> glue files must belong to some component, isn't it?

This is exactly my point.

>>
>> So, having serialization support as an optional part of the supported
>> components seems most viable.
>>
>> Simply scanning all headers for #includes gives a list of all possible
>> dependencies. Telling whether such a dependency is actually required
>> or just optional cannot be easily decided.
>>
>> A smarter dependency scanner might be able to distinguish optional
>> dependencies for libraries that provide an "include all" header.
>
> I don't think the optional dependency is the way to go. We have an optional
> component that the user can choose or not, but its dependencies are not
> optional.

The (required) dependencies of the optional component of the library
introduce an optional dependency of the library. :-)

>> Example:
>> "boost/asio.hpp" pulls in most headers from Boost.ASIO, but not all.
>> "boost/asio/ssl.hpp" is an example of such an exception.
>> Hence, SSL is an optional dependency of Boost.ASIO.
>>
>>
> I suspect that then we need a new component asio/ssl that can have other
> dependencies than asio.

Asio already provides optional SSL support. As long as you don't
include "boost/asio/ssl.hpp", SSL is not required.
Are you suggesting that Asio should provide SSL support in a separate
Git repository? I hope not!

Cheers, Daniel