So, all in all, very like Boost.Build currently does. And that's because it's the correct design and approach to take. So we should do that in any cmake of Boost too.
I'm not necessarily arguing against that approach, but after having heard many (both over the years, and recently) argue that CMake's "one build directory per configuration" philosophy is better than Boost.Build's multiconfig philosophy, it's amusing to see you suggest that idiomatic and modern CMake 3 is a reinvention of Boost.Build. :-)
Boost.Build has the correct design. That was and never has been in doubt. We should not throw out the baby with the bathwater in any cmake transition. Cleave as close as is possible to Boost.Build and the existing build and test design. Makes for much less work. Besides, the "one build directory per configuration" really refers to differing compiler versions, differing 32 vs 64 bit, and the other things for which cmake specifically requires a separate build directory each. If cmake doesn't require a separate build directory for something, then use graphs of targets. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/