First, thank you Robert for starting this discussion. Second, I think the scope and goals of supporting CMake, even though well intentioned, fall short of what Boost needs to do to resolve the varied afflictions that plague us. In what follows when I refer to: "users" I mean those programmers that obtain Boost and use the libraries in their projects, and "authors" as the programmers that develop and support the Boost Libraries and tools. With that in mind, what I would like us to do is what I've mentioned many times in the past.. Move towards a truly modular Boost distribution and development that: a) supports users no matter what environment they choose to use Boost Libraries in, b) supports developers to flexibly develop and test their libraries, c) allows Boost to grow in a way that doesn't cripple development resources. I think that without a "fully normalized modular Boost" a CMake, or any other build system, effort is a waste of time. As it doesn't address the long term viability of Boost. And hence if we are going to spend considerable effort it should be towards modularity. And everything else can flow from that. In addition to the standard requirements that Robert mentioned here's what I think is required for a modular Boost: 1) Fully normalized library file structure that can be introspected. 2) Clear inter-library, and non-cyclic, dependency arrangement and information. 3) Abandon the super-project structure as a development and distribution vehicle. To telegraph my intent for when it's time for proposals.. I think that for #1 above I think we should be forward looking and follow the Pitchfork structure proposal http://bit.ly/2Edy4pC. As for build system.. I think I only have one additional requirement given the above: 1) We should support generating multiple build system files for distribution and development from the introspection of the modular Boost libraries to support the varied user and developer needs. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net