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

Subject: Re: [boost] To modularize, or not to modularize. What is the plan?
From: James E. King III (jking_at_[hidden])
Date: 2019-05-08 12:24:00

On Tue, May 7, 2019 at 10:06 PM Peter Dimov via Boost
<boost_at_[hidden]> wrote:
>
> Rene Rivera wrote:
> > On Tue, May 7, 2019 at 8:41 PM Peter Dimov via Boost
> > <boost_at_[hidden]> wrote:
> > > Rene Rivera wrote:
> > >
> > > > * Ban relative use of inter-library dependencies.
> > >
> > > What does this mean?
> >
> > It means no doing "../../lib/thread/.." from some other lib to get at the
> > build files or anything else.
>
> How will the libraries refer to each other? <library>/boost//libname,
> target_link_libraries(Boost::libname), and rely on someone to have made
> these available somehow? (If we're dropping the superproject.)
>
>

Wouldn't we be able to make much simpler builds for each repository if
we assume a third party package manager will handle acquiring our
dependencies and tell us how to leverage them?  If you want to stick
with b2 we could add a b2 generator to conan so it would spit out some
b2 rules, otherwise we could further simplify things by using cmake
builds in each repository instead of b2.

I'd like to suggest we take two repositories, one that has no other
boost dependencies, and one that depends on it and only it, both of
which are header-only, and convert them to this new potential build
environment:

1. Package management in conan
2. CMake build in each repo (header only repos means this build runs tests)
3. depender declares a dependency on the dependee
4. depender cmake build automatically invokes conan to acquire
dependee and learn the target(s)

Where things get messy are:

* having to support all the library variants for those repos that
still have a library is more difficult
* coordinating changes to multiple repositories requires an extra step
of locally publishing to a private conan repo that is always consulted
first, unless we come up with a better way do to it locally
* Dependencies are managed as part of the build process, whereas
before they were all handled together by b2
* build tools like cmake tend not to produce more than one language
level or one link variant at a time

Benefits that occur however are:

* No more monolithic release coordination - a huge responsibility and
time sink for a select few individuals.
* Versioned dependencies isolate each repository from breaking changes
in others.
* Each repository can release on its own schedule (following SemVer
rules, of course) - code gets to consumers much faster; defect windows
shrink
* No real need to continue to develop or support b2 (unless cmake is
insufficient to cover all potential platforms, which would be
surprising), reducing overall maintenance burden and aligning with
what is popular.
* Optional dependencies can be separated into different recipes (for
example, if you want to use serialization with uuid), otherwise
normally serialization is not a dependency, further reducing the
standard dependency tree
* No more need for both a develop and master branch; repositories
would be free to manage their release strategies as they see fit.
Typical projects create release branches from master when they are
ready to stabilize a release.

It's probably worth asking the question - how important is it to
enable each repository to release on its own schedule, or to eliminate
the monolithic coordination process, or to eliminate the need for use
of and continued maintenance of b2, or ...?

We could continue to use b2 however, and just train it to work with
the package manager.  b2 would have to be an external thing someone
already has (like cmake) installed. That's a less radical change and
may have more potential to succeed.

- Jim