Re: [boost] Moving CMake forward

Subject: Re: [boost] Moving CMake forward
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-07-22 13:03:59

On 7/22/2017 5:07 AM, John Maddock via Boost wrote:
> Man but there's been a lot of hot air expanded on this subject.... guys 
> if we're going to do this, just do it.  We're empiricists around here: 
> lets see what the proponents of CMake can come up with, yes I know there 
> are straw man proposals, but I want something that demonstrates it can 
> fully handle the complex cases at least as well as Boost.Build, and be 
> maintainable by CMake ignorants like myself, because lets face it, once 
> the transition is over, library authors will have to do the maintenance 
> grunt work as before: and if we can't easily see how to do that, then 
> the project probably fails.
> 
> As a minimal first step, what I would like to see come up for review 
> (yes a review folks!) is a system that:
> 
> * Provides users with a way to build those libraries with source via 
> CMake.  All of them together, or just some subset.
> 
> * Provides an install option for all of Boost.
> 
> * Is trivially easy for non-CMakers like myself to maintain. 
> Documentation should be provided (Boost/CMake best practice is...).
> 
> * Is fully compatible with current auto-linking naming on Windows (plus 
> whatever else comes along later like address-model and architecture name 
> mangling that's in the works and has long been requested).
> 
> * Supports libraries with non-trivial build requirements (regex, locale, 
> what others?).
> 
> * Is usable by end users to be able to easily reference Boost libraries 
> from their own CMake projects (note, might be limited to libraries with 
> source, since header only libraries are kind of trivial).  An example, 
> and how to documentation should be provided.
> 
> * It would be nice if generated VS projects were reference-able from our 
> own solutions as well, but I accept that may not be possible.
> 
> * Is at a minimum, no worse than what we have now.
> 
> 
> What else?

Testing and documentation with CMake. This covers nearly all libraries 
which test, as well as a large subset of libraries which use b2 to 
create the library documentation.

> 
> Takers?
> 
> BTW, I don't see a need for this to encompass every Boost library with 
> source before some kind of mini-review to iron out the warts...
> 
> Just hoping to move things along, John.

Exactly. CMake as the required build system for Boost is a done deal and 
we are wasting much hot air arguing about, even if we understand the 
reasons for that hot air. I fully support settings practical use cases 
and moving forward addressing those use cases for the people who 
understand CMake and can make things happen.