I'd like to weigh in as a consumer and occasional patcher of the Boost library. My company uses boost extensively for our cross-platform Windows and Mac OS X C++ application. We maintain two build systems, a Xcode project for Mac-specific components and a *huge* CMake tree that builds our dependencies, proprietary libraries, and tests. We use CMake because it is extremely flexible for different dependency strategies on our target platforms, because it integrates cleanly with our IDEs (My team members use both Xcode and CLion), and because it's relatively easy to maintain the CMakeLists for the majority of our modules. I must admit that I was initially resistant to propagating CMake through our projects but I came around after being part of a minor refactor that we did to modularize some of our code. This effort required writing new CMakeLists and splicing some existing ones into new library targets. It was just as easy to do by hand in the CMakeLists as I was used to doing in our Xcode projects (Xcode is my preferred IDE). I fully support the proposed long-term goal of switching to CMake as the Boost build system, both personally and as a representative of my professional development team. I understand that there is a great deal of sunk cost, history, and personal affinity with Boost.Build/B2. I can only offer inconsequential anecdotes related to attempting to integrate B2 builds the existing build system of a myriad of projects in different organizations. With that disclaimer, I want to say that I have been disappointed with the complexity of the B2 system and it has definitely turned me off as a development. As a library user, it's generally been simple enough to script a "dumb" build task in B2 and then hardcode some usage of the resultant binaries. However, that was completely unacceptable for the current project I lead. I realize that experienced and devoted developers of Boost have a totally different experience interacting with the build system, this is just my perspective. I'd like to offer whatever help I can muster with regard to adopting CMake in Boost. My team practically celebrated when we heard about this proposal. I've posted our semi-proprietary Boost CMakeLists on GitHub. Maybe they'll be useful for a porting effort. https://github.com/GroundControl-Solutions/boost-cmake https://github.com/GroundControl-Solutions/boost-cmake Regards, Jeremy Agostino CTO GroundControl Solutions, Inc. -- View this message in context: http://boost.2283326.n4.nabble.com/CMake-Announcement-from-Boost-Steering-Co... Sent from the Boost - Dev mailing list archive at Nabble.com.