To build a project, all you have to do is type make:

$ make

It will work regardless of your project: OTP applications, library applications, NIFs, port drivers or even releases. Erlang.mk also automatically downloads and compiles the dependencies for your project.

All this is possible thanks to a combination of configuration and conventions. Most of the conventions come from Erlang/OTP itself so any seasoned Erlang developers should feel right at home.

Erlang.mk supports multi-threaded building. Parallel execution is supported for all targets. To execute Erlang.mk in parallel the -j option must be used:

$ make -j8

The MAKEFLAGS variable can be used to enable parallel building permanently on your system. It can be set in your .zshrc, .bashrc or equivalent file.

MAKEFLAGS="-j8"

Erlang.mk gives you control over three steps of the build process, allowing you to do a partial build if needed.

A build has three phases: first any dependency is fetched and built, then the project itself is built and finally a release may be generated when applicable. A release is only generated for projects specifically configured to do so.

Erlang.mk handles those three phases automatically when you type make. But sometimes you just want to repeat one or two of them.

The commands detailed in this section are most useful after you have a successful build as they allow you to quickly redo a step instead of going through everything. This is especially useful for large projects or projects that end up generating releases.

$ make app

$ make app SKIP_DEPS=1

$ make deps

$ make rel

When building your application, Erlang.mk will generate the application resource file. This file is mandatory for all Erlang applications and is found in ebin/$(PROJECT).app.

PROJECT is a variable defined in your Makefile and taken from the name of the directory when Erlang.mk bootstraps your project.

Erlang.mk can build the ebin/$(PROJECT).app in two different ways: from the configuration found in the Makefile, or from the src/$(PROJECT).app.src file.

PROJECT = cowboy
PROJECT_DESCRIPTION = Small, fast, modular HTTP server.
PROJECT_VERSION = 2.0.0-pre.2
PROJECT_REGISTERED = cowboy_clock

LOCAL_DEPS = crypto
DEPS = cowlib ranch

define PROJECT_ENV
[
  {chips, [currysauce,{mushypeas,false}]},
  {pizza, [{size,large},{toppings,[anchovies]}]}
]
endef

PROJECT_ENV_FILE = src/env.src
PROJECT_ENV = $(subst \n,$(newline),$(shell cat $(PROJECT_ENV_FILE) | sed -e 's/$$/\\n/;'))
ebin/$(PROJECT).app:: $(PROJECT_ENV_FILE)

[
  {chips, [currysauce,{mushypeas,false}]},
  {pizza, [{size,large},{toppings,[anchovies]}]}
]

$ make -f erlang.mk bootstrap-lib LEGACY=1

When building the application resource file, Erlang.mk may automatically add an id key with information about the Git commit (if using Git), or an empty string otherwise. It will only do this under specific conditions:

This value is most useful when you need to help your users, as it allows you to know which version they run exactly by asking them to look in the file, or by running a simple command on their production server:

1> application:get_all_key(cowboy).
{ok,[{description,"Small, fast, modular HTTP server."},
     {id,"2.0.0-pre.2-25-g0ffde50-dirty"},

Erlang.mk supports a variety of different source file formats. The following formats are supported natively:

Files are always searched recursively.

The build is ordered, so that files that generate Erlang source files are run before, and the resulting Erlang source files are then built normally.

In addition, Erlang.mk keeps track of header files (.hrl) as described at the end of this chapter. It can also compile C code, as described in the NIFs and port drivers chapter.

Erlang.mk also comes with plugins for the following formats:

Erlang.mk provides a few variables that you can use to customize the build process and the resulting files.

ERLC_OPTS = -Werror +debug_info +warn_export_vars +warn_shadow_vars +warn_obsolete_guard

ERLC_OPTS = +debug_info

include erlang.mk

ERLC_OPTS := $(filter-out -Werror,$(ERLC_OPTS))

ERLC_EXCLUDE = cowboy_http2

The first time you run make, Erlang.mk will build everything.

The second time you run make, and all subsequent times, Erlang.mk will only rebuild what changed. Erlang.mk has been optimized for this use case, as it is the most common during development.

Erlang.mk figures out what changed by using the dependency tracking feature of Make. Make automatically rebuilds a target if one of its dependency has changed (for example if a header file has changed, all the source files that include it will be rebuilt), and Erlang.mk leverages this feature to cut down on rebuild times.

Note that this applies only to building; some other features of Erlang.mk will run every time they are called regardless of files changed.

Erlang.mk keeps track of the dependencies between the different files in your project. This information is kept in the $(PROJECT).d file in your directory. It is generated if missing, and will be generated again after every file change, by default.

Dependency tracking is what allows Erlang.mk to know when to rebuild Erlang files when header files, behaviors or parse transforms have changed. Erlang.mk also automatically keeps track of which files should be compiled first, for example when you have behaviors used by other modules in your project.

If your project is stable, you may want to disable generating the dependency tracking file every time you compile. You can do this by adding the following line to your Makefile:

NO_MAKEDEP ?= 1

As you can see, the snippet above uses ?= instead of a simple equal sign. This is to allow you to temporarily override this value when you do make substantial changes to your project (including a new header file, new module with dependencies, etc.) and want to rebuild the dependency tracking file. You’ll be able to use the following command:

$ NO_MAKEDEP= make

Otherwise, make clean app will of course force the recompilation of your project.

Erlang.mk can also keep track of the source files generated by other means, for example if you generate code from a data file in your repository.

Erlang.mk provides hooks at different stages of the build process. When your goal is to generate Erlang source files, you can add your own rules before or after the dependency tracking file is generated. To do this, you would add your hook before or after including the erlang.mk file.

The easiest way is after:

PROJECT = example

include erlang.mk

$(PROJECT).d:: src/generated_mod.erl

src/generated_mod.erl:: gen-mod.sh
    $(gen_verbose) ./gen-mod.sh $@

In this case we use $(gen_verbose) to hide the details of the build by default. Erlang.mk will simply say what file is it currently generating.

When using an external script to generate the Erlang source file, it is recommended to depend on that script, so that the source file gets generated again when the script gets modified.

If for whatever reason you prefer to hook before including Erlang.mk, don’t forget to set the .DEFAULT_GOAL variable, otherwise nothing will get built:

PROJECT = example

.DEFAULT_GOAL = all

$(PROJECT).d:: src/generated_mod.erl

include erlang.mk

src/generated_mod.erl:: gen-mod.sh
    $(gen_verbose) ./gen-mod.sh $@

Building typically involves creating a lot of new files. Some are reused in rebuilds, some are simply replaced. All can be removed safely.

Erlang.mk provides two commands to remove them: clean and distclean. clean removes all the intermediate files that were created as a result of building, including the BEAM files, the dependency tracking file and the generated documentation. distclean removes these and more, including the downloaded dependencies, Dialyzer’s PLT file and the generated release, putting your directory back to the state it was before you started working on it.

To clean:

$ make clean

Or distclean:

$ make distclean

That is the question.

Note that Erlang.mk will automatically clean some files as part of other targets, but it will never run distclean if you don’t explicitly use it.