Re: [boost] Proposal for moving Boost to CMake

Subject: Re: [boost] Proposal for moving Boost to CMake
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-06-18 20:03:47

On 6/18/2017 3:05 PM, Louis Dionne via Boost wrote:
> Boost - Dev mailing list 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
> 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.

> 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.
> 
> Regards,
> Louis