Subject: Re: [boost] Proposal for moving Boost to CMake
From: P F (pfultz2_at_[hidden])
Date: 2017-06-18 14:50:42


> On Jun 18, 2017, at 9:24 AM, Rene Rivera via Boost <boost_at_[hidden]> wrote:
>
> On Sun, Jun 18, 2017 at 12:03 AM, P F <pfultz2_at_[hidden] <mailto: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.

git clone https://github.com/boostorg/build
cd build
./bootstrap.sh
b2 install

cd ..

git clone https://github.com/boostorg/hana
cd hana
b2 install

or with cmake:

git clone https://github.com/boost-cmake/bcm
cd bcm
mkdir build
cd build
cmake ..
cmake --build . --target install

cd ../..

git clone https://github.com/boostorg/hana
cd hana
mkdir build
cd build
cmake ..
cmake --build . --target install

>
>
>> 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.

These files would be generated during installation. I am not sure what more detail you are asking?

>
>
>> 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.

That is not my assumption, either.

>
>
>> 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.

Yes, the build is not directly at fault, but if boost moved to cmake, there is a much larger community of people who are familiar with cmake and boost that could help work on these structural changes.