On Fri, Jul 21, 2017 at 8:57 AM, Stefan Seefeld via Boost
Does this process appeal to anyone ?
It sounds reasonable in theory, but I think the first thing that should be addressed is the use-case where Users of Boost who have pre-built binaries are able to easily consume Boost in their projects with support from within Boost itself and not the FindBoost.cmake that comes with CMake which is perpetually behind the latest Boost version. I'm talking about this: CMake Warning at cmake/share/cmake-3.8/Modules/FindBoost.cmake:762 (message): Imported targets not available for Boost version Call Stack (most recent call first): cmake/share/cmake-3.8/Modules/FindBoost.cmake:866 (_Boost_COMPONENT_DEPENDENCIES) cmake/share/cmake-3.8/Modules/FindBoost.cmake:1457 (_Boost_MISSING_DEPENDENCIES) CMakeLists.txt:67 (find_package) https://travis-ci.org/vinniefalco/Beast/jobs/255894286#L1385 Fixing this seems entirely non-controversial. It doesn't displace Boost.Build, it adds something that users clearly want (for example, I want this myself), it enhances the value of Boost and it does so in a non-intrusive way. And some work has already been done on this...if the Steering Committee is going make proclamations why don't they start with this instead of turning members of the Boost developer community against each other? Thanks