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?
Takers?
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 project * port the documentation generation, focus quickbook+doxygen at first * think/design/adapt/deploy regression runners and a possibly new regression dashboard How do you want to interact? Raffi PS: for the record, I am not a proponent/opponent of cmake/b2, I am proficient in cmake though.