A lot of projects use erlang.mk → ninenines/erlang.mk. But what are the pros and cons do you experience while using this tool?
3 Likes
RabbitMQ has been using it for 6 years now. It has done its job but there’s recently been some movement toward Bazel (mostly running in CI currently).
Kazoo has also been a long time user.
Both of them have a fair amount of customisations and at least for RabbitMQ a different set of defaults so the experience varies a little compared to the base Erlang.mk.
However I would argue it is best for the use case of “small” open source projects.
4 Likes
I’ve used it in the past and it helped me get going, but when I needed something changed in it, it was hard to understand.
4 Likes
We used it for a medium-sized multi-app umbrella project, for about 2 years. At the time, it was significantly quicker than rebar.
We eventually found that dependency management was brittle, so we moved to using mix (yes, for Erlang) instead.
The fact that it’s written in GNU make, er, makes it quite hard to hack on.
5 Likes
TL;DR:
- Pros: easy to use and extend
- Cons: lack of a command to update dependencies
When I had to choose between Rebar and Erlang.mk for RabbitMQ to replace the home grown set of Makefiles used to build and release RabbitMQ in the past, I picked Erlang.mk for its ease of extensibility.
RabbitMQ was quite far from the recommended practices in the Erlang world when it came to build and run things. We wanted to get rid of this specific build system to use something wide spread and known by the Erlang community. A contributor should not have to learn something he will never use elsewhere. This doesn’t incentivize contributions.
I found it more practicle to use Erlang.mk compared to Rebar because Makefiles are quite nice and easy when you have to manipulate files and run commands. Doing that with Rebar would have been possible, just more time consuming.
RabbitMQ still uses some specific Makefile rules on top of Erlang.mk so it doesn’t reflect the standard use case of Erlang.mk.
To me, the biggest concern with Erlang.mk is the simplistic pinning of dependencies and the lack of dependency updates. For instance, if a dependency pinning of RabbitMQ is bumped, the working copy isn’t automatically updated.
4 Likes
Just used it for a next small internal project, because didn’t want to deal with Rebar3, and there are only a handful of dependencies. However, it is not as convenient to get an interactive shell env running as it is with rebar.
4 Likes
You have make shell and the SHELL_OPTS variable to set the shell the way you want (starting your application like Rebar3 does for example). Otherwise you have make run for releases. For make run there’s also auto reloading features built in.
make shell not starting anything by default is a feature. On larger projects starting everything can take quite a while or not work at all in that context, so it shouldn’t be the default.
2 Likes
Something Torben Hoffmann said in a talk I once attended stuck in my mind: “The good thing about the erlang.mk is that it’s predictable. It might do shit (in terms of picking versions), but it does the same thing every time.” (The recording is here, around 10:50).
This talk is admittedly 6 years old (at another point in the talk they ask about "both versions of rebar", so I guess rebar3 wasn’t even a thing back then), but it is something I have always cherished with erlang.mk.
4 Likes