On 10/10/2018 12:09, mike wrote:
It is for such a reason that as soon as you start talking about using CMake for anything else but identifying Boost libraries for the purposes of end-user use of Boost libraries in their own CMake scripts,
Just consuming precompiled/pre-installed boost libraries in a cmake script is already possible thanks to the work of cmake contributors and the people providing boost packages for vcpkg, conan and other package management systems (some of those contributors are probably also boost library maintainers?). Those solutions have to keep playing catch up with the latest boost release if something significant changes (like name-mangling or a new library), but by and large they work quite well. Imho an official boost solution should provide a bit more functionality to justify the effort.
I'm mostly watching this from the sidelines (since other than building Boost itself I use neither b2 nor cmake), so take this with a grain of salt, but: I think that "onboarding" the consumption of Boost libraries into Boost could be valuable in itself with no need to justify additional functionality, simply because it eliminates that catch-up process and helps ensure things are correct before release instead of after. And Boost is probably in a better position to track library dependencies. Having said that, I'm not sure how feasible it is in practice simply due to historically package deployment being left entirely to outside parties (especially on Linux), thus there being significant variation in the wild.