Re: [boost] Proposal for moving Boost to CMake

On Jun 18, 2017, at 3:03 PM, Edward Diener via Boost wrote:

On 6/18/2017 3:05 PM, Louis Dionne via Boost wrote:

...

...

Howdy all,

This is a request for comments on a possible path for migrating Boost's build system to CMake. [...] FWIW, I support this (or something very similar). Reading some of the discussions in this thread, it seems like people are getting caught into the

Boost - Dev mailing list wrote trap of discussing the specifics of how we would implement a proper CMakeLists.txt file and so on. I think this is completely missing the point. What we need is to acknowledge that the current situation of supporting Boost.Build only is a major pain for our users since they (1) most likely don't use it in house, (2) don't know it, (3) don't want to learn it, and (4) have to deal with it whether they like it or not. If you go into the wild, you'll find - people that don't use Boost because it's too hard to build or integrate into their build system - people that only use the header-only libraries because they don't have to build them and/or because the integration is as simple as changing a header path - people that build properly but are tired of maintaining their bridge between Boost.Build and their own system This, I think is our real problem. The discussion is not about whether it's better for Boost library developers to use Boost.Build, CMake, or Bazel for that matter. It's about what's best our users, who GREATLY outnumber us. And given that CMake is the de-facto standard, the best way to help our users is to provide easy integration of Boost with that build system (however that happens). 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. 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.

Please give a specific example of what this XYZConfig.cmake module entails ? For a header-only library ? For a built library ? For running tests ? For creating documentation ? Along with some sort of decent explanation of what is going on in each situation.

I think Daniel Pfeifer “Effective CMake” talk gives a good overview how this can be done in cmake. Of course, doing this outside of cmake would be a little more work, but probably could be built-in to boost build(which can handle the heavy lifting).