On 24.06.2017 04:59, Peter Dimov via Boost wrote:
There is considerable interest in Boost supporting CMake, but it seems that everyone has different ideas as to what this support will entail. After deliberation and discussions, I have identified the following (separate) scenarios:
I'm a bit confused by the listing, as you use the term "user" in quite different ways.
1. The user installs a Boost release as usual with `b2 install`, which makes the installation visible to CMake and usable via find_package(boost_libname).
2. The user brings several Boost libraries as git submodules into his CMake-based project and uses add_subdirectory in his CMakeLists.txt to link to them.
3. The user uses CMake to install an individual Boost library, which is then available for find_package.
4. The user uses CTest to run the tests of an individual Boost library.
5. CMake is supported as a way to build and install the entire Boost, in place of b2.
6. CTest is supported as a way to run the tests for the entire Boost, in place of b2.
All but 1) are addressed at boost developers, i.e. people who want to build (, test, etc.) boost itself. Only 1) is concerned about users who want to use boost as external dependency to their own project.
At the moment, I think that we should concentrate on (1) and (2) as providing most bang for the buck.
To be honest, I don't quite understand 2). Why do you want to support building boost (or parts of it) as an integral part of something else ? Modularity and encapsulation doesn't seem to have any value to you, or does it ?
5-6 in particular require that all Jamfiles are ported at once, which is a serious undertaking for a questionable benefit as what we have already works.
I agree. (In particular, I very much doubt that you'll get the required buy-in from all maintainers. I for once am strongly opposed to adding another bit of infrastructure to my project, which I won't be able to maintain myself.) Stefan -- ...ich hab' noch einen Koffer in Berlin...