On Wed, Apr 24, 2019 at 9:12 AM Mike via Boost
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
[...] 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. 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