Subject: Re: [boost] Moving CMake forward
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2017-07-22 09:21:11
Le 22.07.17 à 11:07, John Maddock via Boost a écrit :
> 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?
I am in. I have several things in mind, such as
* to work on an component that describes the dependencies between
libraries in order to add then in a topological sort order from the main
* port the documentation generation, focus quickbook+doxygen at first
* think/design/adapt/deploy regression runners and a possibly new
How do you want to interact?
PS: for the record, I am not a proponent/opponent of cmake/b2, I am
proficient in cmake though.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk