Re: [boost] [cmake] Minimum viable cmakeification for Boost

Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2017-06-22 11:06:34

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Robert Ramey via Boost
> Sent: 21 June 2017 16:23
> To: Chris Glover via Boost
> Cc: Robert Ramey
> Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
> 
> On 6/21/17 6:47 AM, Chris Glover via Boost wrote:
> > On Wed, 21 Jun 2017 at 04:01 Thomas Heller via Boost <boost_at_[hidden]>
> > wrote:
> >
> >>
> >> Interesting that you bring this up ... If you are so much in favor of a
> >> declarative build system, we already have multiple. For example plain
> >> old make or Boost.Build. With that being said, wouldn't it be more
> >> viable to improve Boost.Build with:
> >>    - Better Documentation
> >>    - More examples
> 
> Boost build has been hampered by a number of design decisions which have
> never been revisited.

<snip>
 
> Of course this would be coupled with the manual which would describe
> this stuff.  Actually, the text for this stuff is already in boost build
> docs.  It's just that no one knows what part he needs to read to get it
> right.  So compiling this document and code reorganization to support
> the above would have to go hand in hand.
> 
> Bjam is much, much better than is generally appreciated.  Its' just that
> the designers were/are too clever and presume we are also.

I've just returned from holiday to plough through all this discussion :-(    I wish I hadn't!

It feels like there are two groups, one with a spanner who think everything is a nut, and another group with loads of hammers, and
think everything is a nail.

The hammers are made of plastic, and the spanners are adjustable, but come without a manual.

I have been pleading and begging for much more *effective* documentation with far more examples for bjam  and the build system for
15 years, and still believe that this is root cause of the current mess.

 (The daft syntax, incomprehensible error messages, and failure to deal with windows file names with spaces also factors).

I use two IDE, VS and CodeBlocks and using Boost header-only is entirely painless. Quite why there is so much opposition, I find
difficult to understand. Libraries are much, much more troublesome, and I very much like auto-linking.  Sadly, there are a few
essential libraries like system, chrono, filesystem and test that work nicer with libraries, so I can see how people need more than
Boost header-only.

So personally, I am now fairly happy using bjam/b2, after years of swearing and gnashing of teeth. 
Compared to the creators, I'm oligoneuronic (just like most users), but the real cause was nearly all a massive communication
failure.  The documentation just does not work.

(And, if I am honest, I just wanted not to need to know so much, especially when it didn't Just Work, as promised.  The torrent of
plaintive emails on Stackoverflow and Boost say that I am not alone. I'd like to live in the blissful ignorance that Daniela's team
enjoy.)

If a cmake that called b2 to install would make cmake_2.5_rs happy, I think this might be a good first step, but only a feeble
band-aid.

I fear we are about to get into a similar mess with ill-documented cmake 3.5, especially with an army of 2.5 mindset users.
Personally, I don't wish to know about cmake - my brain is full ;-)

I'm encouraged by Niall producing a working cmake 3.5 example - it even includes some comments explaining what is happening !

But it's doing the whole of Boost that is the elephant.  For example, there are 591 files in boost/math/test and hundreds of tests
in each file.  The jamfile is not just a simple list of targets to build and run, there are many options and variants, depending on
many Boost and several external libraries.  So there is a BIG mountain ahead...

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]