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

2013/10/19 Vicente J. Botet Escriba :

Le 19/10/13 15:58, Daniel Pfeifer a écrit :

...

2013/10/19 Andrey Semashev :

...

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