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

On Thu, 2017-06-22 at 12:06 +0100, Paul A. Bristow via Boost wrote:

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] 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 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.