Re: [boost] CMake, modular Boost, and other stories

Subject: Re: [boost] CMake, modular Boost, and other stories
From: Dominique Devienne (ddevienne_at_[hidden])
Date: 2019-04-24 08:30:06

On Wed, Apr 24, 2019 at 9:12 AM Mike via Boost <boost_at_[hidden]>
wrote:

>    [...] Just an example: [1]Boost.TypeErasure depends on
>    [2]Boost.Thread(and all that entails), just because
>    somewhere in its bowels it needs a mutex.
>    > It's always been good practice to not repeat/copy
>    > functionality in one library into another.
>    Not always. A recent example I stumbled over:
>    Boost.Signal2 depended on boost multi index (which
>    itself depends on a lot of other libs) because it
>    reused it's scope guard implementation
>    (IIRC about 50 lines of straight forward code).
>    Tying yourself to another library for something
>    trivial like that should not be a no-brainer.

As Rene mentioned, cycles are bad, and should be eliminated.
But Mike is also right in that not all (non-cyclic) dependencies are
desired,
especially those that are "small", yet carry "lots of baggage".

Perhaps it's something that's missing from the current dependency analysis,
the "surface area" of the dependency, and whether it's for the public APIs
or
an implementation detail, so that those can be pushed down to a lower-level
library and thus eliminate dependencies between "lightly coupled" libraries.

Is it something doable, to have such an analysis?

But this is a bit OT with Peter's original post of course.

At work we bring in the whole of Boost as a "3rd party" dependency,
and declare dependencies per-libraries using the equivalent of the latter
method.

But I can see the appeal of the former as well, especially if there's a
precedent with vcpkg and conan,
especially when wanting to promote modular Boost.

If both methods are already available, why should Boost limit the choice of
the "consumers"?
Unless those doing the work think maintaining both is a big burden, I'd
keep the latter to maintain
consistency with the way things used to work, and provide the former as an
alternative for those who prefer it.
I'm not buying the CMake zealots who advocate for the "one true way" of
doing it... --DD