It is a very important property to have in a build system for large-scale development.
It is very important for boost to be able to support `add_subdirectory` builds. However, hijacking `find_package` to call `add_subdirectory` is the wrong approach and goes against cmake’s workflow. The approach I outlined is what is presented in Daniel Pfeifer’s Effective Cmake talk(although I was aware of this before Daniel’s talk).
I'm mostly in agreement with Paul here. You may however also be in agreement too David. Here are some cmake use cases: 1. I want a library from a Boost release, so find_package(boost 1.60 MODULE COMPONENTS asio REQUIRED), link to boost::asio 2. I am making a new Boost library or I am using Boost trunk source tree. So add_subdirectory(boost/libs/asio EXCLUDE_FROM_ALL), link to boost::asio 3. There is a third use case pre-C++11 Boost libraries can't do which is to mix some release Boost libraries from find_package with some brought in by add_subdirectory() from a source tree. You may wish to rule out supporting that, but equally, a correct cmake implementation should implement that just fine. I do agree David that cmake innovation is to be avoided right now. I have a superb cmake innovation at the library formerly known as boost-lite and now called quickcpplib because it lets you write state of the art C++ libraries super-quick by eliminating needing to think about build or test or tooling or documentation or CI scripting, just supply the config file and go, the cmake inspects its environment and automates everything thereafter. It's really amazing. But it also is very experimental, and insufficiently tested. And it has several serious bugs I haven't got to fixing yet. So don't innovate cmake. Just use 100% standard cmake 3.5, and make sure it is a *good neighbour* to other cmake and is not *anti-social* like most cmake currently written today. Design the cmake to be usable as build and discovery drivers by other cmake. This is the key improvement in cmake 3 - being nice to **any** other cmake. I'd recommend a minimum of cmake 3.5. You can create header only library targets and >= 3.5 those work right without bugs. You can create static and dynamic library targets for those libraries which implement those. I would personally suggest a Python script which parses Jamfile.v2 and spits out a CMakeLists.txt. You'd get 80% of Boost.Build easily enough using just this. You just then need to feed everything to the cmake package tooling, again all 100% cmake 3. And you should be done, no cmake innovation needed. As Edward pointed out, not everything Boost.Build can do will work in cmake without cmake innovation. But worry about that after, for end users of Boost they almost certainly have no need nor want for any of the stuff beyond already described. Indeed one argument could be "don't move Boost to cmake, *package* Boost releases with auto-generated cmake build support". That would make for happy end users. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/