From b5d4cb91f80c833795a2d87050c3674bb7aecdc5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Hoguin?= Date: Tue, 3 Oct 2017 13:39:41 +0200 Subject: Update Hugo, docs --- docs/en/erlang.mk/1/guide/compat/index.html | 173 +++++++++++++++------------- 1 file changed, 90 insertions(+), 83 deletions(-) (limited to 'docs/en/erlang.mk/1/guide/compat') diff --git a/docs/en/erlang.mk/1/guide/compat/index.html b/docs/en/erlang.mk/1/guide/compat/index.html index da880762..d257d9ee 100644 --- a/docs/en/erlang.mk/1/guide/compat/index.html +++ b/docs/en/erlang.mk/1/guide/compat/index.html @@ -7,7 +7,7 @@ - + Nine Nines: Compatibility with other build tools @@ -67,97 +67,104 @@

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.

-
-

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.

-
-
-
-

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.

-
-

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 -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 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:

-
-
-

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. -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!

-
-
-

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, -then you don’t need to worry about compatibility with other -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.

-
-
-
+

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.

+
+

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.

+
+
+
+

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.

+
+

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 +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 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. +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!

+
+
+

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, +then you don’t need to worry about compatibility with other +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.

+
+
+
+ + +