Recursive Make Considered Harmful (1997) [pdf] | Hacker News Reader

Recursive Make Considered Harmful (1997) [pdf]

aegis.sourceforge.net

14 pointsepberry12 comments

Am I alone in my annoyance of "Considered Harmful" named papers?

"Considered Harmful" considered harmful. And annoying.

The fact that this is nearly 20 years old gives it a pass in my eyes. I certainly agree for anything new, though.

You might enjoy this, then: http://meyerweb.com/eric/comment/chech.html

This brings back some memories. While it's nearly 20 years old, it's taken a surprisingly long time for this to become widely understood and tackled.

Even today, tools like Automake default to recursion. It offers a non-recursive mode if you explicitly enable it and adapt your code to use it. I did this for my projects when the support was originally added, and the improvement is noticable, from both a speed point of view and overall maintainability. If you're not using Makefile generators, the effect is even more dramatic.

Today I use CMake for all new projects and have converted from Automake for some older projects. This is always non-recursive but split up into separate files. Having a global DAG of dependencies for the whole project and being able to run a parallelised make over a huge source tree is a wonderful thing to behold, and greatly reduces build times.

I recently spent a week replacing all Makefiles in a reasonably complex embedded arm project I maintain with apenwarr's redo [1] (revamping our cobbled-together CI).. Which allows recursive make structured .do files, without tbe downsides - global dependencies and build state is cached across invocations in a throw-away .redo directory. It's an absolute joy to be able to stamp things that aren't files (eg docker containers) and just use one syntax (script of your choice) to orchestrate builds.

Cross-compiled kernel, bootloader, custom packages, full distro rootfs to final sdcard image without a single Makefile. I owe that man a beer.

[1] https://github.com/apenwarr/redo

This is an interesting anecdote, but we wouldn't really expect you to waste a week doing something pointless like this and then tell us it wasn't awesome. You'd experience cognitive dissonance, so in order to avoid the dissonance of admitting that that redo is not really much better than make (if at all) you are just singing its praises.

I spent a week pulling apart our old build scripts (which were dysfunctional) and putting it all back together again with something new. I'd have done almost the same amount of work if I had stuck with make. In fact I spent two days doing just that prior to my redo adventure: I gave redo a whole day, and found I'd achieved a lot very quickly despite never having used it before. So I completed my spring cleaning with redo.

Edit: I'm not singing redo's praises because I think the world should stop using make; fundamentally redo has potential scaling issues for very large codebases, but for the other 99.9% of projects if you want to explore an alternative, you could do much worse than djb redo.

Really? I frequently hear people spend time on projects and have the outcome be 'fuck that, never again' or similar. I don't think that's uncommon, unless I'm misunderstanding you.

Pretty much anything to do with make ends up being harmful, in my experience. It's just not a good language.

If good is defined in terms of economic utility, then Make is possibly the best language of all time. The majority of the world's compute infrastructure depends on make. (See what I did there?:)

Ha!

AOSP's build system is based on non-recursive make. I like it quite a bit.

Reply on news.ycombinator.com