Well, I swear, every three years like clockwork, the C++ community has a collective meltdown about build systems. And I recently saw a discussion floating around about “The Rise of Meson” — it gave me déjà vu. I remember when SCons was going to save us. Then Premake. Then Bazel (if you have Google-scale patience).

But here we are in February 2026, and I’m still writing CMakeLists.txt files. Look, I get the hate. I really do. CMake’s syntax feels like a shell script had a bad night out with a macro processor. But after spending last weekend trying to migrate a medium-sized project to Meson just to see if the grass really was greener, I have some thoughts. And unfortunately for my sanity, the conclusion isn’t “abandon ship.”

The “Clean Slate” Trap

I decided to port my internal logging library—about 15k lines of code, handful of dependencies—from CMake to Meson. I did this on my Fedora 43 workstation, running the shiny new Meson 1.7.2. The first hour was pure bliss. I’m not gonna lie. Writing a meson.build file feels like writing actual code. It’s Pythonic, typed, and sensible.

But then I hit the wall.

The Ecosystem Gravity Well

The problem isn’t the tool. It’s the rest of the world. My project relies on a specific internal library that hasn’t been touched since 2024. It uses CMake. It exports a MyLibConfig.cmake file. It does not export a pkg-config file.

Meson has a CMake module that allows it to ingest CMake packages, which is technically impressive. But in practice? It’s fragile. I spent three hours fighting with cmake.subproject() options because the internal library was doing something weird with CMAKE_MODULE_PATH that Meson didn’t like.

CMake 3.35: It’s Actually Getting Better

While everyone is busy looking for the next big thing, Kitware has been quietly patching the holes in the ship. I recently updated to CMake 3.35.1, and there are two features that have stopped me from defecting entirely.

1. The Debugger is Finally Usable

Remember trying to debug variables with message(STATUS "VAR IS ${VAR}")? Yeah, we all do. The DAP (Debug Adapter Protocol) support that landed a while back has matured significantly in the 3.34/3.35 cycle. I hooked it up to VS Code last Tuesday to figure out why a generator expression was evaluating to an empty string. I could actually step through the CMakeLists.txt execution and inspect variable states. It felt illegal.

2. C++26 Modules Support

C++ modules are a nightmare for build systems because they require dependency scanning before compilation. CMake’s implementation with ninja has become the gold standard here. I ran a quick benchmark on a modules-heavy project using GCC 15.2: CMake 3.35 + Ninja 1.14 correctly handled the dependency graph updates when I modified a partition interface, with an incremental build time of 1.2s. The alternative tool (SCons) required a full rebuild in 14s.

The Verdict: Why I’m Staying Put

Here is the brutal truth: Build tools are network effects, not technology contests. If you are building a standalone application with standard dependencies (fmt, spdlog, Qt), Meson is objectively a better user experience. But if you are writing a library that others need to consume, or if you are integrating five different proprietary SDKs that only provide CMake configs, sticking with CMake is the path of least resistance. The friction of maintaining a non-standard build system in a C++ ecosystem that has largely standardized on CMake (and CMakePresets.json) is just too high.

So, I’ll keep reading the articles about how Meson is rising. I’ll even nod along. They’re right. It’s better technology. But tomorrow morning, I’m still going to type cmake -B build.

Questions readers ask

Should I switch from CMake to Meson in 2026?

For standalone applications using standard dependencies like fmt, spdlog, or Qt, Meson offers an objectively better user experience with its Pythonic, typed syntax. However, if you’re writing a library for others to consume or integrating proprietary SDKs that only ship CMake configs, stick with CMake. Build tools are network effects, not technology contests, and the C++ ecosystem has largely standardized on CMake and CMakePresets.json.

Does Meson work with existing CMake packages?

Meson includes a CMake module that can ingest CMake packages via cmake.subproject(), which is technically impressive but fragile in practice. When porting a 15k-line logging library on Fedora 43 with Meson 1.7.2, three hours were lost fighting cmake.subproject() options because an internal library manipulated CMAKE_MODULE_PATH in a way Meson didn’t like. Libraries without pkg-config exports are especially painful.

How do you debug CMakeLists.txt variables in VS Code?

CMake 3.35 supports the Debug Adapter Protocol (DAP), which matured significantly across the 3.34 and 3.35 release cycle. You can hook it up to VS Code to step through CMakeLists.txt execution and inspect variable states directly, instead of sprinkling message(STATUS “VAR IS ${VAR}”) calls everywhere. It’s genuinely useful for diagnosing issues like a generator expression unexpectedly evaluating to an empty string.

How well does CMake handle C++26 modules compared to SCons?

CMake’s C++26 modules implementation with Ninja has become the gold standard because modules require dependency scanning before compilation. In a benchmark on a modules-heavy project using GCC 15.2, CMake 3.35 with Ninja 1.14 correctly handled dependency graph updates after modifying a partition interface, producing a 1.2-second incremental build. SCons, by contrast, required a full 14-second rebuild for the same change.