Interesting.. I did not know that. My googling shows that there has been an announcement with an intention to adopt cmake (~ 2 years ago) http://boost.2283326

Interesting.. I did not know that. My googling shows that there has been an announcement with an intention to adopt cmake (~ 2 years ago) http://boost.2283326.n4.nabble.com/CMake-Announcement-from-Boost-Steering-Committee-tt4696935.html http://boost.2283326.n4.nabble.com/CMake-Announcement-from-B... It appears further discussions are underway, but I don't know what that means in terms of how quickly they will switch. https://groups.google.com/forum/#!topic/boost-steering/5ifzupxKINI https://groups.google.com/forum/#!topic/boost-steering/5ifzu... In terms of bjam vs. cmake... I get why the boost library has needed a custom build tool chain (if you're curious just look at the complexity in headers in trying to work around various template bugs in different compiler versions, or the many many many ways to request naming of the generated libraries). I should have been less snarky in my first post. If boost does migrate to cmake I predict it will be quite a gnarly set of cmake logic.