From e5b8d638ea7293ae8a6d65386aefbb0d30aa254c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Hoguin?= Date: Mon, 28 Aug 2017 16:36:33 +0200 Subject: Update user guide --- guide/compat.html | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'guide/compat.html') diff --git a/guide/compat.html b/guide/compat.html index 4c1c80d..aa03ab7 100644 --- a/guide/compat.html +++ b/guide/compat.html @@ -33,25 +33,25 @@ div.navfooter{margin-bottom:1em}
-

Chapter 12. Compatibility with other build tools

Erlang.mk tries its best to be compatible with the other Erlang +

Chapter 13. Compatibility with other build tools

Erlang.mk tries its best to be compatible with the other Erlang build tools. It can use dependencies written with other build tools in mind, and can also make your projects usable by those build tools as well. Erlang.mk is like the cool kid that gets along with everybody.

In this chapter I will use the term Rebar project to refer to a project built using Rebar 2, Rebar 3 or Mad. These three build tools are very similar and share the same configuration -file.

12.1. Rebar projects as Erlang.mk dependencies

Erlang.mk comes with a feature called Autoload which will +file.

13.1. Rebar projects as Erlang.mk dependencies

Erlang.mk comes with a feature called Autoload which will 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 7, Packages and dependencies chapter.

12.2. Erlang.mk projects as Rebar dependencies

Erlang.mk projects can be made compatible with the Rebar family +Chapter 7, Packages and dependencies chapter.

13.2. Erlang.mk projects as Rebar dependencies

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, and the application resource file, found either at -ebin/$(PROJECT).app or at src/$(PROJECT).app.src.

12.2.1. Rebar configuration

Erlang.mk comes with a target that generates a rebar.config +ebin/$(PROJECT).app or at src/$(PROJECT).app.src.

13.2.1. Rebar configuration

Erlang.mk comes with a target that generates a rebar.config file when invoked:

$ make rebar.config

Careful! This will build the file even if it already existed before.

To build this file, Erlang.mk uses information it finds in the DEPS and ERLC_OPTS variables, among others. This @@ -66,7 +66,7 @@ target:

app:: rebar.config

Don’t forget feature specific to Erlang.mk, like the cp fetch method. It could also be that we forgot to handle something! Sorry. We are of course interested to hear about any compatibility -problems you may have, just open a ticket!

12.2.2. Application resource file

Erlang.mk has two ways to generate an application resource +problems you may have, just open a ticket!

13.2.2. Application resource file

Erlang.mk has two ways to generate an application resource file: from the information found in the Makefile, or from the information found in the src/$(PROJECT).app.src file. Needless to say, if you have this file in your repository, @@ -75,7 +75,7 @@ build tools.

If you don’t, however, it’s not much harder. Every time Erlang.mk will compile your application, it will produce a new ebin/$(PROJECT).app file. Simply commit this file when it changes. It will only change when you modify the -configuration, add or remove modules.

+configuration, add or remove modules.

-- cgit v1.2.3