Hacker News Reader

Comment by jitl | Hacker News Reader

The best thing about make is that it’s available everywhere on POSIX systems. macOS comes with it pre-installed, and every Linux distro or *BSD does too, or offers a package for it that’s often depended on by everything else devtools-wise. This means make skills are super transferable; possibly more so than bash/shell skills.

Sure there are more user-friendly tools written in the programming language du jour, but those will always need some special snowflake setup process for all of your developers. If you’re cross-platform, now you need encode that in a setup script before your project can build… Maybe you can offer a Makefile just to install `better-make`?

View on HN

It's true, but the compatibility is limited.

I had to resort to tricks to make Makefiles which work both on Linux and macOS. I had to mandate the use of GNU make on Macs in other cases.

This is on top of having BSD vs GNU coreutils for things like grep, awk, etc, and the ancient bash on macOS.

I really wish there was a self-contained tool that could work like make (building a dependency graph and only doing the needed things), with reasonable string / list / map processing built in. (In a limited way, GNU make is such a tool.)

Does ninja fit your needs? It’s available on just about all of the Linux distros and it’s extremely fast with very few bells and whistles. The language is (for better or worse) designed to be generated by a higher-level tool, so it strips out most of the complexity of GNU make, but it might go too far if you’re looking to do list/map processing in it.

People always claim ninja is fast, but I can't figure out what they mean by that. A typical C++ project build uses 10-10,000 CPU core minutes, and make takes (maybe, in some pessimal situation) 100 milliseconds to schedule and coordinate the build invocations.

Even if ninja is 100x faster, it really, really doesn't matter, at all.

If you build something much smaller, a difference betwen 5 sec and 0.5 sec is pretty noticeable for interactive work, even though 5 sec is not prohibitively long at all.

They probably mean incremental builds, where the actual compilation doesn't overshadow the "coordination" work.

In my (artificial) benchmark, make scaled poorly, taking 70 seconds to process 100k C files worth of dependencies, vs. ninja's 1.5 seconds: https://david.rothlis.net/ninja-benchmark/

Most of make's time was spent processing the ".d" files containing header dependencies (Ninja has a special optimisation for these files, where it reads them the first time they're created, inserts the dependency information into a binary database, then deletes them so it doesn't have to parse them in future invocations).

In real world projects, you often end up "abusing" make to add behaviour such as detecting if the compilation flags have changed, and this can make your makefiles slower; whereas ninja has those features built in. Apparently this made a big difference in build times for Chromium (where ninja was born). See this comment by the ninja's author: https://news.ycombinator.com/item?id=23182469

If you have a slow filesystem and you’re compiling C, make has a “lot” of overhead due to implicit rules. There are many more rules than you write, unless you set stuff like

   .SUFFIXES:

to nothing

Ninja isn't necessarily faster in the slow path of "rebuilding the whole project" vs make, but it's often significantly faster in the fast path of "incremental rebuild given a small change in the input code" vs make. Which is what you're doing most of the time. You also do not have to abuse ninja for it to record certain changes; for example tracking CFLAGS as a dependency in Make can be awkward (e.g. write it to a file and all the associated overhead from the filesystem), but in Ninja it's "just" a variable binding, and the usage of variables in commands is tracked as a dependency, and so changing that variable and re-computing the needed set of commands to run is much, much faster. Those things add up in large builds.

I have personally had Ninja turn multi-second long no-op rebuild times (e.g. run 'make' with no changes) into the 10s of milliseconds range. The no-op build is often the most extreme case but closest to the average case, which is "recompile after a small edit." The difference in interactivity is quite large in these scenarios.

If your project builds in under like 5 minutes from scratch on a modern laptop it probably is not large enough to see huge benefits (outside of pathological cases), but probably some benefit; but for larger projects the difference can be very pronounced, very quickly.

One possible culprit is that ninja parallelizes builds by default, whereas make requires you to explicitly specify the number of jobs with a flag, although I've run into issues with this occasionally if the project happens to do manual parallelization (e.g. with the `parallel` tool). I've seen people not realize this or just happen to forget the flag often enough that I wouldn't be that surprised if a decent number of those claims stem from this.

Ninja also allows different level of parallelism for different stages which is useful if the process itself is already parallelized internally or you need to limit it for other reasons (ld consuming huge amount of memory is a typical usecase)

Maybe tup would interest you? https://gittup.org/tup/examples.html I've been considering it for the next time I do a project that needs this kind of ordered construction.

tup comes packed with a lua parser that gets executed first, so if you need something fancy it can be expressed in a lua file with lua's tools https://gittup.org/tup/ex_lua_examples.html

Tup is interesting, especially its dependency discovery mechanism.

The macOS version of GNU Make is stuck at 3.81, which I discovered does not print the information needed by vim's quickfix feature when traversing subdirectories using `make -C`. Installing the latest version of GNU Make (4.4) using `brew install make` fixed that problem.

The frozen macOS build also has some weird issue with my makefiles where it sometimes finishes the job but then sits there spinning at 100% CPU forever :(.

Beware, the macOS version is historic (as is macOS bash version).

I think Windows comes with nmake

Nope, you have to install developer tools to get it. Usually that means visual studio. Historically they also ship compilers and command line dev tools as a separate package, I'm not sure if that's still a thing.

Nmake is also not very compatible with gnu or bsd make.

> Historically they also ship compilers and command line dev tools as a separate package, I'm not sure if that's still a thing.

It's still a thing: https://visualstudio.microsoft.com/visual-cpp-build-tools/

Note that while the download page and tools don't perform license checks, you are supposed to have a visual studio license to use that package[1]. It is intended as an easy way for VS customers to install tools on build machines and the like without doing a full VS install, not a way for non-customers to get a free compiler. Individuals can get a free license to VS community that would include this package[2], but commercial use requires a paid license.

[1] https://visualstudio.microsoft.com/downloads/#build-tools-fo...

[2] https://visualstudio.microsoft.com/vs/community/

Windows has always been a problem. Now lots of build tools work better cross platform than make.

I use msys gnu make on windows for personal projects.

Reply on news.ycombinator.com