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

Subject: Re: [boost] CMake, modular Boost, and other stories
From: Hans Dembinski (hans.dembinski_at_[hidden])
Date: 2019-04-24 10:09:15

> On 24. Apr 2019, at 10:30, Dominique Devienne via Boost <boost_at_[hidden]> wrote:
> 
> 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.

Boost.Histogram on its release was the library at the bottom of the module level hierarchy. `boostdep  --module-levels`

I started to replace some of the dependencies of Boost.Histogram with private implementations, which is not really a nice solution, because it can and will introduce new bugs. Dropping boost.iterator was a big step up in the module levels, but it didn't feel right. boost.iterator is very annoying to replace and the actual core CRTP class should not depend on much else.

So, it would be useful to move the actual iterator adaptors into boost.core, and have the practical iterators provided by the library with extra dependencies (function_output_iterator, shared_container_iterator, ...) stay in the library.

Best regards,
Hans