On 18 June 2017 at 20:05, Louis Dionne via Boost
It is also worth noting that people on this list that oppose vocally are Boost library developers or folks with deep involvement/knowledge of Boost.Build, which is a very small minority. This has become clear through years of anecdotal evidence (such as speaking to people at conferences). Based on this and previous failed attempts, I think it is unlikely that we'll be able to make a decision based solely on discussion on this list, and my opinion is that a top-down decision is required to make something (anything) happen, like for the Git modularization.
One difference with git modularization is that there was a lot of support for it. And I don't think it was a roaring success.
That being said, I would like to propose an alternative route that is softer than David's to see what people think. I still think that David's proposal is better, but if that was uncontroversial enough, perhaps this could get the ball rolling and we could go from there (and provide some relief to our users in the meantime).
The proposal is to add to the Boost library guidelines the requirement that a XYZConfig.cmake module be provided with the installation of any Boost.XYZ library. This module would simply export the proper CMake targets, which would solve the problem of integrating Boost with a CMake-based build system and would remove the need for the custom FindBoost support in CMake. This would not make Boost easier to build, but once built and installed, it would at least be trivial to use _properly_ from a CMake project. This does not require changing the build system of existing libraries to CMake.
This seems more sensible, but adding a guideline won't do anything. Someone needs to volunteer to create the pull requests, and maintain it in the future.