3 ms·

30 years on and I've used make, imake, autotools, cmake, ant, gradle, boost.jam (because every C++ library really should have its own individual custom build to

by bleair 7y ago

30 years on and I've used make, imake, autotools, cmake, ant, gradle, boost.jam (because every C++ library really should have its own individual custom build tool-chain), scons, ninja, and maybe the least bad was a very nice system internal to ILM (though it was purpose written for building C++ & python targets). These days I'm using bazel the most, and while it can be forced into working, it's pretty miserable (and requires support of about 5 people on a dedicated build team). It does not bring software developers joy. A group/language/team decides "that's it, I hate build tool X, we're going to solve this problem", and they go build their thing, but they care about different details and make some things easy, handle some things automatically, and leave other things as "just don't care" with the resulting tool ends being just like all the previous ones. I'd be willing to wager lots of money that in future years there will be many more build systems, and they too will perfectly match their predecessors. https://www.xkcd.com/927/ https://www.xkcd.com/927/

humanrebar 7y ago
Boost seems to be switching to CMake for what it's worth.
- bleair 7y ago
  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.

by bleair 7y ago

humanrebar 7y ago

Boost seems to be switching to CMake for what it's worth.

bleair 7y ago
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.