

Recursive Make Considered Harmful (1997) [pdf] - epberry
http://aegis.sourceforge.net/auug97.pdf

======
rleigh
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.

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

"Considered Harmful" considered harmful. And annoying.

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

------
csirac2
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](https://github.com/apenwarr/redo)

~~~
brobdingnagian
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.

~~~
csirac2
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.

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

~~~
brobdingnagian
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?:)

~~~
marssaxman
Ha!

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

