CMake is still clueless about its mission
I’m looking at Bill Hoffman’s cmake presentation during C++Now 2024 and I still feel like cmake is an increasingly bad solution for C++. It not only doesn’t respond to the needs of C++ developers, it keeps them in the dark ages of building makefiles in a very unclear and unstructured way, with an inconsistent language, because the cmake developers insist that they need to solve a different problem.
The problems
There are two types of problems in the C++ build world. The problems that existing projects created for themselves, and the problems that developers have when picking up a new project in C++. CMake tries to solve a lot of the first set of problems (as Bill Hoffman’s presentation shows), but solves none of the File->NewProject types of problems that developers need solved. In fact, it moves away from trying to solve those problems, and therefore becomes an increasingly less useful tool.
In my humble opinion, cmake wants to be a translator from a project definition to a build system. It fails at this badly: it’s a bad project definition language: it’s inconsistent and pretty unintuitive, I think I wrote about it here. And you already have build systems in place, we have enough of those wrappers over the compiler and linker. We don’t need more of that.
Everyone in the C++ community now cries over Rust tooling. We’re talking about a language and a toolset that doesn’t
allow basic features like delivering binary libraries usable by the whole system. But when they do cry about that it’s
because cargo
does what most developers think they need: it creates an isolated toolkit by downloading dependencies
from the internet (it’s a bad idea) and delivers statically linked libraries (I told you, guys, it’s a bad idea). But
people think they need this. They obviously don’t need a tool that adds security holes at immense speeds, but what they
need is what cargo really delivers:
- a very strict project structure
- a very simple configuration system that relies on an external server to solve the problem of
where's mah library at
. - One toolset. ONE.
I know, this would’ve been laughable in 2000. It was still laughable in 2010, remember all the jokes regarding Visual Studio? But people really require fewer freedoms so they can actually focus on the work done, not be exquisite at invoking the compiler in the most perfect way.
The solution
No solution yet, and I’m afraid cmake
’s availability and ubiquity will postpone this indefinitely. I wrote klb in my
spare time, it’s a project that obviously needs more love, but I don’t think klb is the way. At
least, definitely not where it is now. I would require some real time and money to invest in it - it can be done solo,
but not when I have other responsibilities that could stretch for 30 hours a day. But the current state of klb shows
that this can be done and can be done easily.
Does klb
scale? I have no clue. Maybe it shouldn’t scale. Maybe it can be improved to scale. But I think that klb
is
not the solution, it’s not the project that will pop up half a year from now and compile 90% of C/C++ projects out
there.
But it’s clear what people need. Fewer options, not more options. Fewer options means fewer ways to screw things up in a
project compilation. I’m still awed that cmake still requires you to list all the files in the CMakeLists.txt
, and
what an ugly choice of a project file name!
So cmake it’s still the best option we have in the C++ world now, but still the worst thing that happened to C++ in the past 20 years. Everything else is improving, only the build system is getting worse.