Subject: Re: [boost] Proposal for moving Boost to CMake
From: Daniel James (dnljms_at_[hidden])
Date: 2017-06-18 21:05:50
On 18 June 2017 at 20:05, Louis Dionne via Boost <boost_at_[hidden]> wrote:
>
> 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.
One difference with git modularization is that there was a lot of
support for it. And I don't think it was a roaring success.
> 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. 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.
This seems more sensible, but adding a guideline won't do anything.
Someone needs to volunteer to create the pull requests, and maintain
it in the future.