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
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 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.
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.
> "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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk