Re: [boost] Proposal for moving Boost to CMake

On Jun 18, 2017, at 9:24 AM, Rene Rivera via Boost wrote:

On Sun, Jun 18, 2017 at 12:03 AM, P F mailto:pfultz2@yahoo.com> wrote:

...

On Jun 17, 2017, at 11:14 PM, Rene Rivera wrote:

On Sat, Jun 17, 2017 at 10:55 PM, P F via Boost wrote:

...

...

On Jun 17, 2017, at 3:10 PM, Robert Ramey via Boost < boost@lists.boost.org> 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.