From a932f220ca62d1f4f6a0d9bfb6ee206fdef7fe59 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lo=C3=AFc=20Hoguin?=
Note that this command may fail if a required dependency is missing.
You can build all dependencies, and nothing else, by running the following command:
$ make deps
This will fetch and compile all dependencies and their -dependencies, recursively.
Packages and dependencies are covered +dependencies, recursively.
Packages and dependencies +Chapter 7, Packages and dependencies are covered in the next chapter.
It is not possible to build the release without at least building the application itself, unless of course if there’s no application to begin with.
To generate the release, make
will generally suffice with
a normal Erlang.mk. A separate target is however available,
and will take care of building the release, after building
-the application and all dependencies:
$ make rel
Consult the Releases chapter for more +the application and all dependencies:
$ make rel
Consult the Releases +Chapter 9, Releases chapter for more information about what releases are and how they are generated.
When building your application, Erlang.mk will generate the application resource file. This file is mandatory for all Erlang applications and is @@ -111,7 +113,8 @@ PROJECT_VERSION = 2.0.0-pre.2 PROJECT_REGISTERED = cowboy_clock LOCAL_DEPS = crypto -DEPS = cowlib ranch
Any space before and after the value is dropped.
Dependencies are covered in details in +DEPS = cowlib ranch
Any space before and after the value is dropped.
Dependencies +Chapter 7, Packages and dependencies are covered in details in the next chapter.
The src/$(PROJECT).app.src file is a legacy method of
building Erlang applications. It was introduced by the original
rebar
build tool, of which Erlang.mk owes a great deal as it
@@ -140,7 +143,8 @@ The following formats are supported natively:
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
+C code, as described in the NIFs and port drivers
+Chapter 8, NIFs and port drivers
chapter.
Erlang.mk also comes with plugins for the following formats:
Extension | Location | Description | Output |
---|---|---|---|
.dtl | templates/ | Django templates | ebin/*.beam |
.proto | src/ | Protocol buffers | ebin/*.beam |
Erlang.mk provides a few variables that you can use to customize the build process and the resulting files.
ERLC_OPTS
can be used to pass some options to erlc
, the Erlang
compiler. Erlang.mk does not restrict any option. Please refer to
diff --git a/guide/compat.html b/guide/compat.html
index def4498..005b305 100644
--- a/guide/compat.html
+++ b/guide/compat.html
@@ -44,7 +44,8 @@ use Rebar 2 to patch any Rebar project and make it compatible
with Erlang.mk. This feature essentially patches Rebar out
and adds a Makefile to the project that Erlang.mk can then
use for building:
Autoload is documented in more details in the -Packages and dependencies chapter.
Erlang.mk projects can be made compatible with the Rebar family +Packages and dependencies +Chapter 7, Packages and dependencies chapter.
Erlang.mk projects can be made compatible with the Rebar family of build tools pretty easily, as Erlang.mk will generate all the files they require for building.
The Rebar family requires two files: a rebar.config file containing compilation options and the list of dependencies, @@ -57,8 +58,8 @@ means that the Rebar family builds your project much the same way as Erlang.mk.
Careful though! Different build tools have different fetching strategies. If some applications provide differing dependencies, they might be fetched differently by other build tools. Check -the Sanity check chapter to find -out how to detect such issues.
You can automatically generate this file when you build +the upcoming Sanity check chapter to find out how to detect such +issues.
You can automatically generate this file when you build
your application, by making it a dependency of the app
target:
app:: rebar.config
Don’t forget to commit the file when it changes!
If you run into other issues, it’s probably because you use a
feature specific to Erlang.mk, like the cp
fetch method.
diff --git a/guide/ct.html b/guide/ct.html
index 14c1637..f1c21d5 100644
--- a/guide/ct.html
+++ b/guide/ct.html
@@ -54,7 +54,8 @@ using the variable t
. Note that this only applies t
suite-specific targets, like the ct-http
example above.
To run all tests from the http_compress
group in the
http_SUITE
test suite, write:
$ make ct-http t=http_compress
Similarly, to run a specific test case in that group:
$ make ct-http t=http_compress:headers_dupe
To do the same against a multi-application repository,
you can use the -C
option:
$ make -C apps/my_app ct-http t=my_group:my_case
Note that this also applies to dependencies. When using Cowboy -as a dependency, you can run the following directly:
$ make -C deps/cowboy ct-http t=http_compress
Finally, code coverage is available, +as a dependency, you can run the following directly:
$ make -C deps/cowboy ct-http t=http_compress
Finally, code coverage +Chapter 18, Code coverage is available, but covered in its own chapter.