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-17 13:57:50

> On Jun 17, 2017, at 2:11 AM, Klemens Morgenstern via Boost <boost_at_[hidden]> wrote:
> 
> I am dead set against that. CMake is inferior to boost.build and it's only popular for the lack of alternatives. Boost.build could be one (I use it in my projects outside of boost) but it a steep learning curve and is not distributed outside of boost. But even the syntax is less horrible than the CMake one in my opinion.

CMake's syntax is verbose, which makes it much more friendly to pickup. Bjam’s syntax is too terse with too many weird quirks that most authors just copy and paste code.

> 
> I do think CMake is broken in it's core, because it doesn't build but create a description (i.e. makefile or similar). And in order to change that I have to clear the cache and reconstruct it. Boost.build on the other hand works like a charm if I have a proper build description and write `b2 toolset=gcc toolset=msvc` - it will build both and test on both without any conflicts.

You would just create two separate build trees for each configuration. I don’t see how that makes CMake broken.

> I think we should definitely keep boost.build around, if only to have it's concepts (as in meta-targets) in a working build-system. I also don't think CMake will be around forever, it's a deficient solution.

A lot of autotools projects are moving to cmake. I don’t see them moving the Boost.Build. Boost.Build doesn’t have the support that cmake does.

> As ist boost.build, but boost.build gets the job done for boost. I don't see the point of moving from one deficient tool to a worse one, just because everybody seems to be using it.

I don’t think it does get the job done. Some boost libraries do more extensive testing in cmake than in the Boost.Build because it doesn’t get the job done. Some libraries have auto-generated tests and files because Boost.Build doesn’t get the job done. Even more so, downstream projects have to reverse engineer the dependencies because Boost.Build doesn’t get the job done.