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

Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
From: paul (pfultz2_at_[hidden])
Date: 2017-06-22 17:16:51

On Thu, 2017-06-22 at 12:06 +0100, Paul A. Bristow via Boost wrote:
> 
> > 
> > -----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_lists.boost.
> > > org>
> > > 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.

Yes, that is why moving to cmake which has a larger community that already
provides lots of these materials. Plus, we can get support from this larger
community to help improve boost build infrastructure.

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

And after users spend many hours debugging these issues, they usually
abanonded it:

https://github.com/boostorg/build/issues/106

> 
> 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

Daniel Pfeifer's "Effective CMake" does a wonderful job explaining cmake and
how to stucture it:

https://www.youtube.com/watch?v=bsXLMQ6WgIk

I also put together a wiki that goes over the best practices and guidelines:

https://github.com/boost-cmake/bcm/wiki/Cmake-best-practices-and-guidelines

> , especially with an army of 2.5 mindset users.

What army of cmake 2.5 users? I don't see anyone advocating for cmake 2.8
style of cmake.

> 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 !

There is also my example, which follows the "effective cmake" structure:

https://github.com/pfultz2/boost-cmake-demo

It also supports both the `add_subdirectory` and `find_package` workflow,
something that Niall's example does not.

> 
> 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...

There are the tests. For some libraries they are simple to add, for others,
they are more complicated. There really should be a look at the testing
infrastrucutre as well.