I’ve been a C/C++ programmer most of my life. I wrote my first programs in the 1970s, so most of my professional life has been a sequence like this: write some code, build it, and debug it. The tools we use to do that second part, the build step, have gotten considerably better since make was written at Bell Labs in 19761. For many years at GenArts, I used, and helped develop, SCons. It was pretty great in those days; it built a complete graph of the code and executed it in parallel, build descriptions were written in python, not some one-off domain-specific language you had to learn. SCons is still in use in some very big projects, and I was proud of the work we did on it. But it is stuck in the python idioms of the 1990s and hasn’t been able to keep up with the times, and never achieved the traction we were hoping for.
Over the years, CMake became dominant as the way to build C and C++ applications. A huge community has sprung up around it and it’s genuinely the de facto standard for modern build tooling. It runs everywhere, supports lots of languages, and has lots of add-ons. It introduced the concept of transitive dependencies, which is a great innovation. The problem with CMake, though, is the build description language: the thing you actually write and maintain. It is abjectly terrible. Its syntax is odd at best, variable handling is byzantine, and debugging it is a nightmare. It also has undergone several complete redesigns of the public API over the years, so looking up how-to information online often leads to the old ways that aren’t supported anymore.
There are lots of other projects seeking to replace CMake: Meson and Bazel are two that are on good tracks. But after looking into them closely, I couldn’t bring myself to buy into either one. And I’d been thinking for years about rearchitecting SCons onto a modern python stack with Path and decorators and all the other wonderful stuff python has been doing, and fixing some of the pain points at the same time, but I’d never had the time to dig into it. And at the same time I started doing some consulting work using CMake, which taught me that there are some genuinely important features I hadn’t really understood deeply. Why couldn’t I create a new, modern build system with the best of CMake and SCons and all the things I’ve learned in a fifty year career in software?
Now that I’m (officially) retired, and I’ve been using a lot more Claude Code as a programming assistant, it seemed like the right time to try this as a collaborative project. And the more I got into the architecture, the more excited I got about it. It really is possible to describe a software build simply and cleanly by using modern python, a language everyone knows and is supported everywhere. I won’t go into the technical details here; you can check the website, or the docs or go straight the the source on github.
At this point it’s been used by a few small projects, I’ve done extensive testing myself, and I’ve ported some fairly significant-size open source projects to work with it (mostly privately, to test that it really can handle big jobs with multiple languages, libraries, dependencies, unusual custom commands, installers and so on). I think it’s ready for real use. If you are starting a C, C++, CUDA, Fortran, WASM, or other compiled-software project, please consider using pcons as your build tool! Or if you just can’t stand tearing your hair out one more time fighting with cmake, I’ve made it really easy to port over to pcons from cmake — there’s a porting guide, and the docs are AI-friendly so your AI can probably do the port in a few minutes.
Pcons is fully open source (MIT licensed) and I intend to stand behind it and make it a serious build tool. I hope you’ll try it — and please spread the word!
Footnotes
-
First publicly released with Unix v7 in 1979; I didn’t use it til the ’80s. ↩
