Gesendet: Dienstag, 07. Mai 2019 um 08:03 Uhr Von: "Gavin Lambert via Boost"
On 7/05/2019 15:57, Rene Rivera wrote: [...]
This can get a little tricky in some cases, as previously discussed. For example, if Optional depends on Serialization only if you include a specific header file (which is not included by the default
) -- is that a dependency or not? It is.
This is where circular dependencies and too-eager dependencies come from, though.
If a user wants to use Optional without downloading Serialization, they would never include that header file, and thus Optional does not "really" depend on Serialization for their usage, thus it should not be downloaded.
If the user wants to use both, then they're probably using Serialization elsewhere already, so they would already be downloading both, and can then use that header. So nothing actually needs to consider Serialization a dependency of Optional -- both are simply dependencies of the consuming app/library.
I'm with Gavin on this. If the dependency is well contained in a separate header file (in particular not included by a library source file or by boost/libname.hpp) and doesn't provide any functionality beyon integration with serialization, then serialization is not really a usage requirement of - in this example - Boost.Optional. Just to be clear though: Such integration headers are a special case. I don't agree with Robert that dependencies should generally be tracked on a per-file basis. In particular not, if that requires the user to use yet another specialized tool. The latter is also, why I'd prefer if every library explicitly states its dependencies in a simple to parse file that is checkid into the repository (of course the maintainer may use a tool to automatically create/update that file): Boost should make it as easy as possible to be used with/ consumed by existing tools (i.e. package managers like conan and vcpkg) and not require yet another specialized tool to be used in a modular fashion. Mike