Why I use erlang.mk
Here is our typical Erlang project. And note we are on a pretty slow Mac OSX filesystem and a 5400 RPM disk. Not the fastest in the world. If I run a rebar-compile from cold, we get the following a timing of 26 seconds. Doing the same with erlang.mk is 24 seconds. Note that erlang.mk only uses one thread, whereas rebar is parallelizing the build and is using all 4 cores in the machine. But erlang.mk only spawns the erlc compiler once per directory, and only if it needs to—no change means no spawn.
But if we have already compiled the code, the numbers are much different. When compiling from warm, it takes rebar 9 seconds to figure out that there is nothing to do in the project. erlang.mk does the same thing in 0.2 seconds.
When developing, I don’t want to wait on the compile to finish all the time. I want it to be proportional to the amount of change in my repository, not on the complexity of the software project.
The other reason is that make(1) is the right tool for the job. Most of these other tools are reinventions of the thing make(1) does. And it is very hard to even contend with a tool that has survived so many years and is so archaic.