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 05:03:44

> On Jun 17, 2017, at 11:14 PM, Rene Rivera <grafikrobot_at_[hidden]> wrote:
> 
> On Sat, Jun 17, 2017 at 10:55 PM, P F via Boost <boost_at_[hidden] <mailto:boost_at_[hidden]>> wrote:
> 
> > On Jun 17, 2017, at 3:10 PM, Robert Ramey via Boost <boost_at_[hidden] <mailto:boost_at_[hidden]>> wrote:
> >
> > Actually, this example makes bjam look much easier than CMake which I believe conflicts with the original premise which motivated the proposal.
> 
> I don’t think its a fair comparison to bjam as its not doing the same thing. The bjam files in boost for header-only libraries do not individually install headers or usage requirements.
> 
> I think it is at minimum relevant, and mostly fair. The argument for using an external non-Boost build system, regardless of which one is the current flavor, is that it is externally supported. And hence no one at Boost needs to write a bunch of code to make use of it for the Boost use case. But if there needs to be a significant amount of code in Boost for the build system the justifications for switching loose considerable appeal. It doesn't matter where the code is. If it's in individual libraries or collected in a common Boost module, it's still effort to maintain comparable to the effort of maintaining b2.

There is many use cases for switching to cmake. One use case is modular building and to have boost export its usage requirements in the form of pkgconfig or cmake find packages. This can also be done using bjam files as well, but there is work that needs to be done to support this. Of course, the fact that Louis has done the work is not fair to compare with non-existent work. Furthermore, the argument is made that by switching to cmake, boost can take advantage of this larger community support to fulfill this work, instead of letting a decade go by on such unfulfilled requests in bjam.