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.
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk