CMake is a great example on problems with DSLs. Simply not everybody is a good language designer. CMake uses a pretty horrible language and comes with its own kinds of strangeness. I have used it quite extensively and it's probably the way to go if you want to support MSVC. But I'm not really happy with it.
My recent gripe with CMake: the language toolchain is still a singleton. You can't easily use multiple C++ compilers in the same build. This doesn't feel like a language limitation.
I also never got why we need DSLs for build systems. It seems like Turing completeness is often inevitable, no matter if people don't like it. There is no reason that a build file couldn't be mostly declarative with a general-purpose programming language though.
I want to upvote this for solid info, but I want to flag it so fewer people have to know about CMake. It blows my mind that experienced software developers would develop yet another pseudo-language DSL vs creating a portable library (python, java, go, whatever) that has a sensible interface.
CMake is the perl of build systems: useful and feature-fat but one of the worse DSL syntax I've had to grapple with, barely better than that of a Makefile
Well, there's a lot of gross things about CMake (the syntax of its DSL is horrifying), but in my experience if you want Windows support it's a lot better than autoconf and make.
The CMake language is just an atrocious mess, but that gets easier with time. The main problem with CMake on Windows is that it is really really slow for large projects (because it has to call back out to CMake to do all sorts of basic stuff) and that debugging CMake errors is horrifically hard (this has improved in recent MSVS generator integration, but I'm stuck w/ VS2008 still).
I'm not arguing that it doesn't do what it was designed to do. I'm arguing that it is a grotesque DSL with bizarre design choices. CMake would have been better off as a cross-platform library that didn't re-invent concepts that other programming languages have already gotten correct, and instead focused on making the build system be cross-platform.
The language itself isn't great, but I don't think that's the main problem with CMake. The whole structure of the thing is like having a dump truck pour a giant pile of tools in front of you. It's all in there somewhere, but good luck figuring out which ones you need.
Right now, CMake is being actively integrated into QtCreator and Visual Studio where they previously had their own bespoke defaults. It might be shit but it's also becoming more and more "standard" as one DSL you need for cross-platform builds, instead of fifteen xkcd-927 style.
I think this is being misunderstood, partially because of the self-claim that this is a build system.
The CMake DSL is utter garbage. From my understanding, this converts TOML that follows the same/similar naming as CMake commands/options to CMake DSL. Allowing for total compatibility with CMake while avoiding the pain of actually interacting directly with a CMakeLists.txt.
Most people agree that CMake is not a good option but the only real option. I'd happily put lipstick on this pig.
I've gotten used to CMake and I kind of like it now. The language is atrociously ugly, but it's very functional at least and feature-rich. Ugly-but-functional is better than pretty-but-inherently-broken.
The CMake documentation is pretty good actually. I don't think people really want to settle on it though because the language is so awful. Almost as bad as Bash.
I like when a project I downloaded uses CMake because then I already know how to build it. Just the same old "mkdir;cd;cmake ..;build" I always do, maybe with some custom option flags.
But using CMake for my own projects? Hell no. The concept of a DSL for build systems just seems awful to me. A shitty build system is one where you have to rely on "magic" commands/flags/options to get it to do what you want. A DSL is an entire language dedicated to magic commands. Why would I want to go through the pain of mastering that, even if the documentation were decent?
My current go-to build system for non trivial projects is waf. It's got some really interesting ideas (like describing builds using aspect-oriented programming), but most importantly it has you use straight up Python to write your build scripts. No DSL or special formats.
There are other build systems that use general purpose languages to describe builds like premake/xmake which use Lua, Gradle which uses Groovy and Kotlin, or Scons which uses Python (and inspired waf). Personally, I think Python is much more comfortable for working with strings and files, but I'd prefer any of those build systems over something like CMake or Meson.
I was a C++ developer in a past life and Cmake was a big reason I moved on to greener pastures. It’s the only language that is more toilsome to use than C++ itself, and that by an enormous margin. It’s stringly typed (no, that’s not a typo, everything is a string), it’s syntax is obscure, it extends so poorly that it just bakes-in support for building popular libraries (e.g., Google’s test framework, Qt, etc iirc), imports are implicit so it’s tedious to track down the definition for a particular symbol, it completely punts on package management—not only were builds not reproducible but you couldn’t even get it to download and install dependencies for you from a declarative list. Cmake isn’t a build system, it’s a toolkit for scripting your own bespoke build system (and a crumby one at that) which basically means that every project is a unique snowflake with its own distinct quirks which are tedious to learn and maintain—even though 99% of projects would be covered by something like cargo. Those are some of the things I remember off the top of my head ten years later (it was also doggedly slow and things would break across minor releases, but I’m told those things have improved).
Cargo is imperfect, but it’s the right tool for the job 99% of the time.
After maybe three years of experience with cmake I must admit its scripting language is just disgusting. Makefile provided a nice, well thought out, simple DSL, with just three concepts: targets, dependencies and actions, and while it didn't provide enough support for handling multiple compiler toolchains, etc. I think replacing it with the cmake shell like 'scripting language', sporting one data structure (string; lists are really just semicolon separated strings...), is an example of very, very bad engineering.
The scripting language is bad, most cmake scripts are much more complex than they should be, but cmake does a lot of things under the hood that make multi- and cross-platform development easier (for example: being able to build with the Visual Studio compiler without running in the "Visual Studio Developer Command Prompt").
A lot of fancy new build tools don't even have proper Windows support.
reply