Re: [boost] Proposal for moving Boost to CMake

Subject: Re: [boost] Proposal for moving Boost to CMake
From: P F (pfultz2_at_[hidden])
Date: 2017-06-18 21:20:28

> On Jun 18, 2017, at 3:03 PM, Edward Diener via Boost <boost_at_[hidden]> wrote:
> 
> 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.

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).