On 19 October 2013 14:58, Daniel Pfeifer
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.