On Tue, 2017-07-18 at 18:09 -0700, Louis Dionne via Boost wrote:
Hi,
I'd like to expose two strawman proposals for adding CMake support to Boost. Both proposals would solve the following problems, with different advantages and disadvantages:
(1) Users have a hard time integrating Boost into their build system, which is CMake more often than not.
(2) Prospective Boost developers are sometimes driven away from submitting because they would have to learn Boost.Build, which is not widely used and has a limited knowledge base.
FIRST PROPOSAL ============== The first proposal is to move completely to CMake and to render Boost.Build support optional. The possible rollout plan would look something like:
1. We start requiring that new libraries support both Boost.Build and CMake.
2. We start adding CMake support to existing libraries. This will take time. 2.1 We start moving our infrastructure to be CMake-based.
We need to start by defining the use cases we want to support. That is we want to support: * Prebuilt libraries with `find_package` * Integrated builds with `add_subdirectory` * Bulding libraries standalone(ignoring cycles for now) * Running tests with all of boost * Running tests standalone * Generating documenation... Of course, as we start to move to cmake, we can start by getting the first three cases done, and then move to integrating the tests. Then next phase would be integrating the documentation. I think it important that we start outlining these goals. Especially since users between prebuilt vs integrated builds don't agree, and we dont want to support one while ignoring the other case. I think its important and feasible to support both camps.