Chapter 26. Why

Why would you choose, if not for its many features Chapter 3, Overview? This chapter will attempt to answer that.

26.1. is fast is as fast as it gets. will group the compilation of files so as to avoid running the BEAM more than necessary. This saves many seconds compared to traditional Makefiles, even on small projects. will not try to be too smart. It provides a simple solution that works for most people, and gives additional options for projects that run into edge cases, often in the form of extra variables or rules to be defined.

26.2. gives you the full power of Unix is a Makefile.

You could use directly without configuring anything and it would just work. But you can also extend it greatly either through configuration or hooks, and you can of course add your own rules to the Makefile.

In all cases: for configuration, hooks or custom rules, you have all the power of Unix at your disposal, and can call any utility or even any language interpreter you want, every time you need to. also allows you to write scripts in this small language called Erlang directly inside your Makefile if you ever need to…

26.3. is a text file is a Makefile.

Which means is a simple text file. You can edit a text file. Nothing stops you. If you run into any bug, or behavior that does not suit you, you can just open the file in your favorite editor, fix and/or comment a few lines, save, and try again. It’s as simple as it gets.

Currently using a binary build tool? Good luck with that.

26.4. can manage Erlang itself isn’t written in Erlang.

That’s not a good thing, you say? Well, here’s one thing that and Makefiles can do for you that Erlang build tool can’t easily: choose what version of Erlang is to be used for compiling the project.

This really is a one-liner in (a few more lines if you also let it download and build Erlang directly) and allows for even greater things, like testing your project across all supported Erlang versions in one small command: make -k ci.

26.5. can do more than Erlang doesn’t care what your dependencies are written in. will happily compile any dependency, as long as they come with a Makefile. The dependency can be written in C, C++ or even Javascript… Who cares, really? If you need to fetch it, then will fetch it and compile it as needed.

26.6. integrates nicely in Make and Automake projects

If you are planning to put your project in the middle of a Make or Automake-based build environment, then the most logical thing to do is to use a Makefile. will happily sit in such an environment and behave as you expect it to.