It still boggles my mind that CMake was the thing that won for the next generation of build systems. Its syntax is probably even worse than bash (except that it didn't have decades of compatibility to blame that on), making it the single worst language I've ever written code in. I struggle to understand how one could sit down to create a language and come up with something that bad.<p>There was apparently at one point effort to replace its frontend with Lua, but that sadly never took off. (I, like everyone else, still hold my nose and use it, but man ... like ... bwa?)
While CMake is verbose I don't think it's terrible. The complexity of building a simple flat source project vs a multi-stage build project scales very well. One thing that amazed me was how simple it is to script up the creation of generated libraries.<p>For school I had to generate a build step that would allow me to embed Duktap and link to a library called Glad. Both needed to be generated with a python script. Doing this was dead simple [1]. I didn't have to do anything crazy to locate the path to python, the source folders I want to output into, etc. CMake has magic for that.<p>Granted I spent just as much time reading the really horrible docs to find out how to use these magic features as it took me to complete the assignment. I think like many amazing technologies it's blocked by a steep learning curve and a long long history of worse ways of doing things. Every time you google for how to do something you'll get an answer from a different part of the project's lifespan.<p>[1] - <a href="https://github.com/gravypod/solid-snake/blob/master/CMakeLists.txt#L22-L41" rel="nofollow">https://github.com/gravypod/solid-snake/blob/master/CMakeLis...</a>
If you liked this piece, please also consider reading <a href="https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/" rel="nofollow">https://pabloariasal.github.io/2018/02/19/its-time-to-do-cma...</a>, which is a modern (2018) guide to what you should and should not do in CMake.<p>It's very enlightening.
The generator expression used here isn't necessary:<p>add_test(NAME plain-run COMMAND $<TARGET_FILE:vector-test>)<p>You can just use:<p>add_test(NAME plain-run COMMAND vector-test)<p>Since the <COMMAND> is an executable target.
I also found this to be a decent reference (mostly the videos):<p><a href="https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1" rel="nofollow">https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4...</a><p>Also, some of the Kitware projects on GitHub.
While I appreciate the need for DSLs, in many cases I feel like I'd rather use an API. At least, an API imposes no constraints on the features of the language itself. (So, imagine a DOM for VS solutions and projects; writing your own script would be a breeze...)
<p><pre><code> Make is horrible because it does not handle spaces in paths
</code></pre>
Putting spaces in pathnames is idiotic to begin with. I have written Perl scripts that are 3x more complicated just to deal with spaces in pathnames. You might as well blame Make for not handling UTF-32 characters in pathnames -- I mean, someone might want to put a GREEK CAPITAL REVERSED DOTTED LUNATE SIGMA SYMBOL (U+03FF) in their path -- Make would suck if it didn't allow this.<p>You missed the most egregious problem with Make -- the fact that commands must begin with a friggin' TAB! No other whitespace will do. Think of every manual writer who has to somehow convey that the whitespace you (don't) see is a TAB.
CMake is absolutely terrible if not destructive for non-trivial projects that require frequent build system updates and restructuring (especially those tied to cross-compilation).<p>GNU Make might have its share of issues but compared to CMake, it's dead simple and I've never once in 20 years of programming encountered a build issue I could not debug.<p>CMake has had me throw up my hands and give up in despair far too many times. It boggles the mind that people continue to use such a rotten tool. Probably because it looks attractive, superficially, but if one examines it in more detail any possible justifications for using it should completely fall apart.
I'd suggest everyone to check out bmake. It has a very nice standard library of makefiles with which often your makefile can be a couple lines long, one of which just includes the relevant library.