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

On Tue, May 7, 2019 at 10:06 PM Peter Dimov via Boost wrote:

Rene Rivera wrote:

...

On Tue, May 7, 2019 at 8:41 PM Peter Dimov via Boost 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