| People that don't understand make are destined to recreate it poorly, and there's no better example than cmake, imho. Here's my arc through C/C++ build systems: - make (copy pasted examples) - RTFM [1] - recursive make for all sorts of non-build purposes - this is as good as hadoop up to about 16 machines - autotools - cmake - read "recursive make considered harmful" [2] - make + templates Anyway, once you've understood [1] and [2], it's pretty hard to justify cmake over make + manual vendoring. If you need windows + linux builds (cmake's most-advertised feature), you'll pretty quickly realize the VS projects it produces are a hot mess, and wonder why you don't just maintain a separate build config for windows. [1] https://www.gnu.org/software/make/manual/ [2] https://news.ycombinator.com/item?id=20014348 If I was going to try to improve on the state of the art, I'd clean up a few corner cases in make semantics where it misses productions in complicated corner cases (the problems are analogous to prolog vs datalog), and then fix the macro syntax. If you want a good package manager for C/C++, check out Debian or its derivatives. (I'm serious -- if you're upset about the lack of packages, there's a pretty obvious solution. Now that docker exists, the packages run most places. Support for some sort of AppImage style installer would be nice for use with lesser distros.) |
> If I was going to try to improve on the state of the art
The state of the art is buck/bazel/nix/build2.