Re: [boost] CMake - one more time

On Apr 22, 2016, at 8:20 AM, Paul A. Bristow wrote:

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Rene Rivera Sent: 20 April 2016 23:26 To: boost@lists.boost.org Subject: Re: [boost] CMake - one more time

On Wed, Apr 20, 2016 at 4:39 PM, Raffi Enficiaud < raffi.enficiaud@mines-paris.org> wrote:

...

Le 20/04/16 17:49, Robert Ramey a écrit :

...

Inspired by the recent discussion regarding CMake, I've spend some more time looking at this. As a result, I've done the following.

...

...

Thanks for summarizing this very very (very) long thread.

+1

...

...

I do not like the current state of b2 for many reasons (even though I think it could be really a good build system), but CMake is not covering many features that are currently required by the boost superproject. Until the point where we can consistently build the lib (including the possibly many flavor of the same library - STATIC/SHARED at the same time, etc), run the tests, and generate the documentation (including the possibility to have the boostdoc/quickbook/doxygen toolchain), I do not see any *good* reason to move to cmake.

+1

Despite its unpopularity, I see bjam/b2 having power to do things that other build tools are much less good at.

There has been many years of very helpful support from too few experts.

It's the devil many of us know and it *can be made to work powerfully*.

I've come from hate to love b2 (well - a grudging respect).

...

That's essentially the conclusion that the community ended up with years ago on the first attempt to implement Cmake support.

So still +1 for that conclusion.

However, we haven't explained this well enough, especially to would-be authors. I've provided some antenatal help to authors who are surprised at the implications of portability, especially if they come from an Visual Studio IDE or Linux environment. Being required to support multiple platforms and multiple compilers and multiple versions, and static and dynamic linking, and multiple libraries, comes as a bit of a shock.

We need to explain why b2 is still the best tool for *this task*.

The problem with BB is not entirely technical. It is very capable(as well as cmake). However, cmake has much larger community support. If I need to figure out how to do something in cmake, I can google it and quickly find an answer. This is because cmake is used by a very larger community. Outside of boost, Boost.Build is rarely used, and those that have used it end up abandoning it because of issues like this: https://github.com/boostorg/build/issues/106

...

And I would like to know what the reasons for not liking b2 are. But on the b2 list ;-)

I've aired my views on the b2 list before, so I'd like to do it here as well.

1 The syntax - As Paul Dirac might have said "It isn't even daft!". But given enough examples and warnings about the need/wrong for spaces, we can cope with that.

2 It tries to be too clever. Fine when it succeeds, and baffling when it doesn’t. But given more *examples* of what works, and more important, what commonly doesn't work, showing how to decode the inscrutable messages, again we can cope.

3 But most of all, I struggle with the documentation. * It doesn't say enough on 'why' Boost is using b2. * What there is looks nice, but assumes far, far too much and misses far too much. * It doesn't give *worked examples* of the main things one commonly does. * It hasn't got an index or other aids to *find* what one wants to know.

I see the same questions appearing again and again - and taking the time of the long-suffering and ever-helpful experts.

We need to minimize wasting their really valuable time (and hair-tearing by users).

I'd like to see a complete rewrite of documentation. Paradoxically, I want it written by someone who is *not* an author or expert. (Obviously it will have to be edited by several people who *are* experts).

For future library authors, a template dummy project with all the folders and files assembled to copy and modify for their library would mean that the learning curve is less steep - at present, it's an overhang!

Paul

--- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost