Re: [boost] CMake - one more time

Subject: Re: [boost] CMake - one more time
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2016-04-22 09:20:56

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Rene Rivera
> Sent: 20 April 2016 23:26
> To: boost_at_[hidden]
> Subject: Re: [boost] CMake - one more time
> 
> On Wed, Apr 20, 2016 at 4:39 PM, Raffi Enficiaud <
> raffi.enficiaud_at_[hidden]> 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*.

> 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
[phone]