Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk