That's obviously wrong; we are building all of Boost (including its executables) cross-platform with single build files and little or no platform switching.
Well, I wasn't saying that you can't do that with CMake. CMake being a language, you can probably do whatever you want with it as long as you write the code for doing it. I was saying that you can't do that with the simple building rules CMake provides out-of-the-box. I mean, without going beyond where a developer would want to go to define the build targets of his project. For me, currently this limit is: if you have to write more than what Boost.Build would require you to write, then you are already too far into the build system internals. As an example, creating a library should be as simple as: lib foo : bar.c ; Or whichever syntax fits you best. Going back to what you said, I quickly went to the Ryppl sources, and that is exactly what I meant. You had to write an entire framework in CMake language, wrapping the CMake built-in rules, to provide a such usable and high-level syntax to the developers so their project's CMakeLists files will be as easy to write as they were with Boost.Build. Basically, you've rewritten a Boost.Build like framework in CMake, as Boost.Build is written over Jam. I never said this to be impossible. I've had to write a build system using CMake some time ago, and I faced the exact same problem. I had to rewrite tons of stuff, like you did for Ryppl, to make it usable for individual projects. And I feel sorry for seing this happening again and again. Basically every project using CMake rewrites its own macros over CMake built-ins to satisfy this, more or less complicated and powerful depending on the project's initial needs. Then, the initial question was about choosing between CMake and Boost.Build. And I said that the two are at a totally different level of abstraction. It is like, the other way around, comparing the framework you have built using CMake vs Jam. That said, I can understand that because of CMake being more widely used, this framework will probably be much more maintainable than Boost.Build, and much attractive to people who want to expand it. I don't know, maybe it can achieve what Boost.Build couldn't, being widely used by other than Boost. But maybe it will be only perfectly fitted to Boost needs, and not usable enough for other projects. And maybe people will continue to only remember CMake and rewrite their own build macros until a new challenger appears that will have all the right features built-in. -- Beren Minor