Subject: Re: [boost] [modularization] What do we do with "glue" headers?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-10-19 10:57:53
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?
> 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.
> "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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk