On Fri, Jun 16, 2017 at 9:01 PM, Robert Ramey via Boost < boost@lists.boost.org> wrote:
On 6/16/17 4:44 PM, David Sankel via Boost wrote:
* Boost sources would provide a compatible, drop-in replacement for the 'FindBoost' module that is distributed with CMake. A CMake-based application could point to it and, instead of using the system Boost libraries, Boost targets would be built from source as part of the user build.
Hmmm would this be a FindBoost for the whole of Boost or for each particular library? Who would re-write and maintain this FindBoost as the current one is not up the task. Getting this right - or even better is not a trivial task.
I agree that this is a non-trivial task. The contract for FindBoost is relatively straightforward. The implementation for the Boost-source version of this library would look at the COMPONENTS argument and, based on that, add_subdirectory the source for the particularly requested library. The CMakeLists.txt file would be author maintained and provide its corresponding target (e.g. boost::thread).
I see this progressing with several milestones.
1. Release of a CMake-buildable Boost and the CMake conventions. In this stage each Boost library can be built in isolation or with the entire distribution and all the 'FindBoost' functionality mentioned above would be incorporated.
2. The unit tests for all Boost libraries are incorporated into CTest (the
CMake unit test orchestration tools).
My experience is that many boost tests cannot be run with cmake. For example, I cannot make a CTest test which will be successful on compile-fail. - Correction I can, but involves some gymnastics about re-invoking CMake and capturing the result and inverting it and ...
Thanks for pointing that out. With any build system switch, some things will be easier and other things will be harder.
3. The Boost infrastructure is modified to use CTest for unit testing.
I don't think this would be necessary.
Perhaps not.
4. Unit testing functionality is removed from Boost.Build.
I don't think this is necessary either.
Likewise.
5. Boost.Build is removed.
If CMake is successful, boost build would die on it's own. If you have to forcibly remove it, you've failed.
I see your point.
Although there are many other great ideas floating around (e.g.
modularization of Boost, Boost-Classic, and Boost2), I'd like to keep this focused on CMakification of Boost because I think it is something that would have big impact and is small enough to be doable.
The problem is that we have problems migrating to CMake BECAUSE we've got with the other stuff mentioned.
Actually, I believe the real problem is the monolithic build/test design of boost libraries which inhibits evolution. Boost Build developers have been very accommodating about adjusting to the particular features of different libraries. This demonstrates good will, but has given use with a testing/deployment setup which is very complex.
Yeah, this is unfortunate, but I don't think this is unfix-able. One step at a time. First, lets work on getting a decent CMake build. I would love to have your support here Robert.