Subject: Re: [boost] Proposal for moving Boost to CMake
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2017-06-18 14:24:22
On Sun, Jun 18, 2017 at 12:03 AM, P F <pfultz2_at_[hidden]> wrote:
> 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]>
>> > On Jun 17, 2017, at 3:10 PM, Robert Ramey via Boost <
>> 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
Concretely define what "modular building" is.
> and to have boost export its usage requirements in the form of pkgconfig
> or cmake find packages.
Concretely define what it means to support those.
> This can also be done using bjam files as well, but there is work that
> needs to be done to support this.
True.. But the assumption seems to be that it would easier to do all of the
above with cmake. Which I dispute.
> Of course, the fact that Louis has done the work is not fair to compare
> with non-existent work.
Perhaps it's not fair to compare work that hasn't been defined sufficiently
to implement for any build system.
> 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.
It is unfair to blame the build system for requests that are substantially
structural issues with Boost. Issues that would malign any build system
that Boost might use.
-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail