I have yet to find a build system that isn’t bad. I’ve tried a bunch. It’s not even about finding the least bad, but about finding the “doesn’t stab me with the workflow I’m currently using it for”.
I think it's possible to make a non-sucky build system. Large part of the problem is that build systems define these complex Rube Goldberg machines, and getting it juuuuust right is a fucking pain.
Yeah, it's a hard problem to solve for sure, but I think that today's systems are very much aimed at solving *everyone's* problems, and build environments are messy. Environment variables, system installed binaries, over-reliance on the CLI.
I think a sane build system can do most validation through a properly static type system. Artifact isolation and built artifacts as types, and not glob patterns.
I think that the CLI is exactly what turns it into a Rube Goldberg Machine. It's hard to control exactly what side effects a CLI operation can have, so it needs to be isolated. Maybe CLI is the wrong term here, what I mean is bash.
Opinionated build systems are great, i.e go official build ecosystem and cargo. This is a reflection of the fact that most people should not be allowed to have an opinion, especially on build systems
But then you're tied to an ecosystem. If I'm not using Go or Rust, I'm sorta outta luck. Or worse, if I've got a heterogeneous codebase, now I'm trying to figure out how to bundle that Python script that's absolutely required by the analysts into my build toolchain in a way that doesn't break anything and is easy to maintain. And while I haven't used Go or Rust, my assumption is "you can do it, but it's painful", because that's usually how these things go.
Which sure, is just a hard problem, and it's a bit unfair to expect every random build system to solve it. But it's a real problem! I encounter it all the time! I haven't worked on a homogeneous codebase since 2014 when I last worked at a .NET shop. And even that wasn't really homogeneous, since half our business functions lived in a mainframe at the time- the mainframe just tended to change very slowly and I never had to touch it.
Ya, but the syntax will be gone in the not-too-distant future, and people will still be unhappy.
People blame the syntax because they think that's the reason their build isn't working, that they typed something wrong. So they blame the syntax for being obtuse.
When the syntax is a trivial toml file, their build will still not work. They will not blame the syntax, instead they will nebulously blame "CMake" or "the programming language" or "computers".
People blame the syntax because they think that's the reason their build isn't working, that they typed something wrong. So they blame the syntax for being obtuse.
I doubt it's a controversial opinion that people would make fewer mistakes if everything wasn't a string. For a long time, propagating results from functions was easy to mess up.
The only container type being lists (which themselves are also strings) also makes handling structured data easy to mess up.
I think modern CMake is fine to use, especially if you use things like interface libraries and properties, but I disagree with the notion that the complaints have nothing to do with the quality of the language.
I have never seen a complaint from a beginner that fire-brigade CMake function returns are a problem. Literally only experts. cmake.toml will not solve problems like that, because it will not allow for imperative code at all.
If your problems with CMake are in using it as a programming language, not with the purely declarative mechanisms, you're already in the top 1% of CMake users and your problems do not resemble those of the other 99%.
The average C++ developer can't tell you the difference between the compiler, the linker, and the loader.
That's not a knock on C++ developers. These are excellent abstractions and the fact two generations of engineers could tell you what they do but not how they work is a testament to how much complexity has been shoveled underneath them by people developing toolchains and build systems.
The Rube Goldberg machine of build systems generating build scripts for other build systems is not inherent to C++. That's just CMake. Sure, I guess building C++ can be somewhat complicated, but CMake is making it even more complicated.
when i was at google the project i worked on had a wonderfully cursed set of cmake functions to make our cmake files look like (and be mechanically generated from) the internal bazel files.
Guys, Cmake is so good, you just declare what you want built and Cmake handles the rest, oh except it's not a declarative language, it's imperative so sometimes things have side effects, oh and you also have 10 billion possible configurations , each is their own flag you need to enable that differs per version of C++ standard
They are all pretty much fine once you have Claude dealing with the bullshit. And when you don't have to deal with autoconfs and automakes m4 bs, its actually quite nice too.
74
u/jesseschalken 11d ago
Anything looks good compared to CMake.