Hacker News Reader

Comment by dgfitz | Hacker News Reader

The only thing worse than a complex codebase is a complex build system. I think CMake is an abomination. “Hey go learn this new language to compile this other language!”

View on HN

The only thing worse than a complex build system is a simple build system that can't build what you need to build. :(

This means the architecture is also bad, and that is what needs to be fixed.

so simple huh? since you fancy yourself an architect can you let me know how we might fix the architecture of https://github.com/llvm/llvm-project such that CMake is no longer needed?

Not in a glib response, no.

okay can you at least tell me how the architecture of https://github.com/llvm/llvm-project is "bad"?

That’s such an obnoxious tactic. It’s basically saying “Your point is invalid unless you can cut this Gordian Knot on the spur of the moment in an internet comment!”

It's less bad than the ill informed Dunning-Kruger opinion it rebuts.

Don’t worry Phillip, ignoring the bit where it isn’t a rebuttal at all, I know I’m not a smart person. That’s why I like simple builds!

It’s a logical fallacy; it doesn’t rebut anything.

>> Complexity has to live somewhere. If you are lucky, it lives in well-defined places. In code where you decided a bit of complexity should go, in documentation that supports the code, in training sessions for your engineers. You give it a place without trying to hide all of it. You create ways to manage it. You know where to go to meet it when you need it. If you're unlucky and you just tried to pretend complexity could be avoided altogether, it has no place to go in this world. But it still doesn't stop existing.

>> With nowhere to go, it has to roam everywhere in your system, both in your code and in people's heads. And as people shift around and leave, our understanding of it erodes.

>> Complexity has to live somewhere. If you embrace it, give it the place it deserves, design your system and organisation knowing it exists, and focus on adapting, it might just become a strength.

- Fred Hebert, https://ferd.ca/complexity-has-to-live-somewhere.html

I think that's true up to a point, but it misses the distinction between accidental and essential complexity. Essential complexity has to go somewhere, accidental complexity doesn't, and most complexity in software is accidental.

And even when the complexity is essential, IMO it's better off not in the build system. I'll gladly accept more complex code for the sake of a simpler build (even though that theoretically means worse performance). Worst case if I need to do something complex at build time I'd rather model that as "the build system invokes a program that does something complex" than try to express the complex thing in some Turing Tarpit "configuration" language.

Also the point of software engineering is to take the real complexity that actually exists and you can't get rid of and work out how to write simple code to deal with it. Good software architecture does not include complexity because there is complexity in the business. It manages the complexity with simple code.

The trouble is when people say "complex" you don't really know what they mean, though. They often just mean "difficult". Every programmer who wants to use that word needs to watch this: https://www.youtube.com/watch?v=SxdOUGdseq4

Nah. Hickey say stuff that sounds profound but doesn't actually help you get better at writing software or even at talking about it.

> accidental complexity doesn't, and most complexity in software is accidental.

I strongly disagree. Most software is insufficiently complex to adequately represent reality.

> Most software is insufficiently complex to adequately represent reality.

That may be so; what I'm claiming is that most of the complexity in software as it currently exists is accidental.

> I think that's true up to a point, but it misses the distinction between accidental and essential complexity.

Very respectfully, I think you may be missing the author's point. When you fail to make a home for necessary complexity, it rears its head as unintended complexity in unexpected parts of the system. The source of 'accidental' complexity is unaccounted for complexity.

> When you fail to make a home for necessary complexity, it rears its head as unintended complexity in unexpected parts of the system. The source of 'accidental' complexity is unaccounted for complexity.

If that's what they're claiming then I completely disagree. No, that's not the reason, that's got nothing to do with it. If that were true we would expect e.g. projects with more complicated builds to have simpler code, and IME that's not true.

Again, respectfully, I don't think that follows (or makes much sense). There is not a set amount of complexity for all software that gets apportioned between the build system and the business logic, so that an increase in one necessarily means a reduction in the other.

Instead, each domain space has some degree of inherent complexity, which varies from problem to problem. Failing to account for this inherent domain complexity appropriately will cause it to bubble through at unexpected points throughout the system.

Build systems inherently have a very complex job. A good build system grapples with this complexity and tries to harness it; a bad one pretends it isn't there, and becomes a tangled mess once the (inevitably complex) demands made of it exceed its limited assumptions.

> Build systems inherently have a very complex job. A good build system grapples with this complexity and tries to harness it; a bad one pretends it isn't there, and becomes a tangled mess once the (inevitably complex) demands made of it exceed its limited assumptions.

I don't think this is true. I think that when looked at in the right way the job of a build system (when used appropriately) is actually fairly simple, and most build system complexity is either accidental complexity (either just straight-up bad design, or misguidedly overengineered flexibility in directions that don't matter) or comes from trying to accommodate things that the build system shouldn't have been doing in the first place. When I've seen overcomplicated builds they've never been because the build system made assumptions that were too limiting.

After seeing enough bitbake recipes, I have to respectfully disagree. Some things are better off left unbuilt.

I wish I’d included this in my initial response:

I am painfully aware of bitbake. I’ve probably written 3-400 recipes.

Most of them are about 20-30 lines long, because I refused to hide the compilation mess inside a recipe. I fixed the problem _before_ getting to the bitbake part. Most of my recipes at this point need only a repo name, the recipes are identical after that.

> CMake is an abomination. “Hey go learn this new language to compile this other language!”

"go learn this awful new language"

Xmake uses lua if you want to give it a try.

He did write ‘awful,’ which is a fair description of the experience of writing Lua.

I don’t mean that as an insult to Lua’s creators. They seem like really smart fellows. It’s just that the language is (to my eyes, with my background) viciously ugly. And 1-based arrays, of course, are evil.

It has some neat ideas, though, and it is supposed to be very easy to integrate into a project. But man, that syntax …

1-based arrays are fully optional in Lua. You can use -2-indexed arrays instead, should you wish to.

Ah good old $[ in perl.

I kind of agree, but it's still far better than CMake's custom language IMO.

I suspect that INTERCAL would be better than CMake's own language.

I don't mind CMake. It's awful, but I'm already using C or C++, so the bar is set pretty low. It does do a few things right, and at least some of the things it does wrong are manageable.

I'll eat at least a bit of shit if it means I can get more than one platform's-worth of build process out of a single set of human-editable configuration files.

Have you tried meson? I used it once many years ago, and it seemed slightly better.

Meson's approach to simplicity is if you need anything nontrivial, you simply add it to Meson itself. In CMake, you can script it in more cases.

Depends on what you need; you can easily call out to external Python scripts to solve many problems, which will work everywhere because Python is needed to run meson itself.

Meson is quite nice if you want to build software exactly and exclusively how the Meson designers want to build software.

The world does not work like this though. CMake is weird but once you've learned some non-intuitive stuff, it works very well and there's a reason why pretty much everyone is using it.

I initially tried to use Meson for a small emscripten project targeting WASM, but it seemed stuck on the idea that I was cross-compiling (technically true), and this seemed to make everything more complicated. With CMake I was able to hack together a working build configuration without too much trouble. I just had to tell it that I wanted to use emscripten as the compiler.

The ideas embodied in modern target-oriented CMake are worthwhile. It's all hobbled by a dreadful script language but that could be improved with sufficient motivation.

I think what annoys me about it the most is that for every good idea in there there's one piece of tedious crap you have to work around, one actively bad misfeature that doesn't work properly, and one terrible aspect of the awful scripting language.

(And two minor annoyances that people determined to hate CMake will never shut up about. But then, if you're determined to hate something, there are worse things than CMake to do it to! So I can't be too critical.)

> I think what annoys me about it the most is that for every good idea in there there's one piece of tedious crap you have to work around, one actively bad misfeature that doesn't work properly, and one terrible aspect of the awful scripting language.

Sounds like the perfect match for C++.

It's hobbled not just by that but by the fact that it's not the thing doing the building. It's a build system for build systems, and suffers from brittleness and confusion as a result.

Make, in all its various implementations, is far more brittle than CMake. Ninja requires a meta-build tool like CMake.

Reply on news.ycombinator.com