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

On 6/22/2017 7:06 AM, 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.

(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

No definition in my "Webster's Third New International Dictionary", I don't have the OED, don't recall the word in literature, find only 'Oligoneuron' on the web about a genus of flowering plants, so a definition would be appreciated as my own neurons are not firing enough connections to understand it. Perhaps it means an oligarchy of neurons, whatever that is supposed to be.

(just like most users), but the real cause was nearly all a massive communication failure. The documentation just does not work.

I tend to agree but on the basis that the Boost Build doc probably has most everything but not organized in ways that the C++ programmer can easily understand.

(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 ;-)

rotfl

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

+1 What I am really afraid of is not that Boost end-users do not like CMake, because obviously most programmers appear to love it, but that Boost will just be substituting one build system under its own control, which few really understand, for another build system controlled elsewhere, which more evidently understand but whose usage even more people disagree about. However if we can provide CMake for end-users from our bjam files, without tortuous work, I am all for it as long as I personally don't have to understand it. I find reading the CMake docs, such as they are, much more incomprehensible than the Boost Build docs.

Paul

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