The cahotic state of C++ build systems

Meson, Ninja, CMake, Bazel, Buck, make, MSVC… Here are soome of the many ways you can now compile a C++ project. And with configuration files bigger than a whole project, one might wonder how 40 years of evolution brought this monstrosity.

First of all C++ dates way back before anyone figured out what a good package manager or build system could be and as make was one of the first real toolchains for it, a large portion of C++ was written aggainst it. Everything system that came later had to coexist with it or replace that deeply entrenched system. But the reason make even made its way into dev labs arround the world is because there is no official build system for C++. The ISO comitee responsible for C++ historically focused almost exclusively on the standard library definition, not the tooling. But this can also be because of the way C++ is used: it is everywhere from SBCs to supercomputers, it powers almost everything and making a “one-size-fits-all” system for every single one of these use cases is basically impossible. And the constant improvement of developement environment led to an almost generational landscape with Buck or Bazel, which were made to fix Cmake, which were make to fix GNU make and so on. Sometimes, these even came from companies that needed very specific requirements (like google’s Bazel)

With all that in mind, our goal with SPBuild wasn’t to replace CMake, Meson or other bigger Build System but to provide a simpler dev experience to bootstrap a project fast without needing to care about all the configuration needed to build it, focusing on code first. Whether you are developing a side project or a whole commercial software, SPBuild’s goal isn’t to bring a 100% configurable system but a simple one that works everywhere, right out of the box.