Hacker News Reader

Comment by qppo | Hacker News Reader

I feel like if you close with "only 20% slower than make" you can't justify the title "is not slow."

20% is a pretty huge margin for large builds, which I wouldn't consider using make for in the first place. CMake + Ninja has shaved enormous amounts of time off my builds from make, so why should I use something that's even slower?

View on HN

As a counterpoint, my builds are mostly too fast to care, but modifying the CMake files that describe them is excruciating. It's a miracle of software engineering that CMake functions, but wow is the language awful.

Is there something specific you dislike about it besides the syntax? I frequently hear complaints about cmake not supporting one thing or another but a lot of those have been addressed in recent releases. It's not clear to me why you say it's a miracle either, AFAIK it does most of the same things any other makefile generator does.

(Disclaimer: I'm not involved in the cmake project but I often see people struggling with it because of misuse, possibly because of expectations that it will work exactly like autotools)

Honestly, I switched to bazel and did not look back.

Yeah we switched from Scons to CMake and I have to admit I loved being able to use python for Scons. CMake's language is unintuitive and clunky. I wish CMake had been designed like LLVM with a front and back end so that there could be a python-based front end (for example).

Yeah, I've been unhappy with any automake system for a long time. Haven't tried ninja though. Scons was fine-ish.

Now that because work forces me to develop on a locked down windows box, make is the last thing I want.

Ninja is not a build system, it is an interpreter for the output of a build system.

A very, very fast interpreter, with truly admirable process-management skills.

there is llbuild...

https://github.com/apple/swift-llbuild

llbuild is a set of libraries for building build systems. Unlike most build system projects which focus on the syntax for describing the build, llbuild is designed around a reusable, flexible, and scalable general purpose build engine capable of solving many "build system"-like problems. The project also includes additional libraries on top of that engine which provide support for constructing bespoke build systems (like swift build) or for building from Ninja manifests.

> but modifying the CMake files that describe them is excruciating.

I've been using CMake for over a decade and the only time editing CMake files was not straight-forward was when whoever wrote them had no idea of what they were doing and were trying to crowbar a round peg into a square hole.

With "modern cmake", which is modern in name only, everything is declarative, modularized, and straight-forward. You just specify targets, target properties, and that's it. I have absolutely no idea of where all the drama comes from.

I guess it’s just a steep learning curve. I’ve been doing some cross platform JNI and python development with cmake and as someone who’s not intrinsically familiar with it, it’s very difficult to “grasp” how everything relates, how I can properly make cmake detect some arcane libraries on computers installed by customers, even when they put them in weird paths, etc etc.

I guess these are problems with all builds systems, but cmake feels like it’s hiding everything behind macros and it’s really difficult to understand what they are actually doing under the hood sometimes.

> I feel like if you close with "only 20% slower than make" you can't justify the title "is not slow."

IIUC, the 20% slowdown happens with a build that does nothing, it's just the scons overhead. (Not sure if they replaced the compiler invocations with echo, or if they touched the result files right from Python, for this number. They mentioned both, but I don't remember which one of them resulted in the 20% figure.)

The 20% figure should go down for real world builds.

Unless I'm misreading your description though, the problem is that "a build that does nothing", or "a build that does very little" is absolutely a real world build, because it's almost exactly what happens when you do incremental recompilation. It's one of the most common cases you would encounter.

Sure, but re-linking was the big factor, or god forbid you touched a header file that was used in 400 code units -- or your ccache corrupted itself, or you changed your compiler flags (which would force ccache to recompile everything anyway).

As much as I don't like programming golang, they did get compilation right. And Scons/ninja/automake/cmake issues just went away.

> or god forbid you touched a header file that was used in 400 code units

In C/C++ that means you decided to change 400 translation units.

That's not a problem with the build system at all. That's a problem with how the developers working on the project failed to follow basic best-practices in software development. No build system saves you from the mess you create yourself.

> IIUC, the 20% slowdown happens with a build that does nothing, it's just the scons overhead.

That's the whole point of performance measurement for build systems. The overhead is precisely what counts here.

If you have many source files to recompile, the fraction of time spent in the build system itself is going to quickly drop to almost zero : build-system stuff is generally several orders of magnitude faster than compiler stuff.

So it would make little sense to compare build-system performance on full builds.

Reply on news.ycombinator.com