Re: [boost] Proposal for moving Boost to CMake

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]>
> wrote:
>
>>
>> > 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
> building
>

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