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

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

On 19 October 2013 14:58, Daniel Pfeifer <daniel_at_[hidden]> wrote:
>
> Lets use the example of Boost.UUID and Boost.Serialization.
>
> My gut-feeling says that serialization support for UUID belongs to
> UUID.

FWIW that's how hash support is added. Support is usually in the same
header as the object being hashed. Since it just requires writing a
'hash_value' function, a library might not even need to include any of
hash's headers. To support writing generic hash functions, there is a
lightweight forward declaration header[1] which only depends on config
and workaround. If a library uses that header, bcp will understand
this, but a tool which works on the module level won't.

[1] http://www.boost.org/boost/functional/hash/hash_fwd.hpp

It isn't a big problem for hash, as it doesn't have many dependencies
(by boost's standards at least). But might be elsewhere.

> A smarter dependency scanner might be able to distinguish optional
> dependencies for libraries that provide an "include all" header.
>
> 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.

"include all" headers aren't always appropriate. There's no
established naming convention, so there will need to be some explicit
specification (e.g. I don't think boost/exception/exception.hpp or
boost/bind/bind.hpp are "include all" headers). I think I'd prefer to
explicitly specify optional dependencies, since they are the special
case. Counting everything in a module is the safe option, so it should
be the default.

It also isn't clear how to handle the case when the glue for modules A
and B depends C, but nothing else in A or B do. Would have to
explicitly specify that the glue was being used, or have the
dependency tool somehow understand this? Or maybe just require one of
A or B to depend on C.