[boost] To modularize, or not to modularize. What is the plan?

Subject: [boost] To modularize, or not to modularize. What is the plan?
From: Mike (mike.dev_at_[hidden])
Date: 2019-05-07 08:41:31

> Gesendet: Dienstag, 07. Mai 2019 um 08:03 Uhr
> Von: "Gavin Lambert via Boost" <boost_at_[hidden]>
>
> 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
> >> <boost/optional.hpp>) -- 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