From 6029c8d8f090cc98bb8f46986fc16262383796c2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Hoguin?= Date: Wed, 24 Jan 2018 13:44:51 +0100 Subject: Update user guide --- guide/plugins_usage.html | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'guide/plugins_usage.html') diff --git a/guide/plugins_usage.html b/guide/plugins_usage.html index 8fd3022..aaf5af7 100644 --- a/guide/plugins_usage.html +++ b/guide/plugins_usage.html @@ -33,7 +33,7 @@ div.navfooter{margin-bottom:1em}
-
Prev   Next

Chapter 23. External plugins

It is often convenient to be able to keep the build files +

Prev   Next

Chapter 24. External plugins

It is often convenient to be able to keep the build files used by all your projects in one place. Those files could be Makefiles, configuration files, templates and more.

Erlang.mk allows you to automatically load plugins from dependencies. Plugins can do anything, including defining @@ -42,19 +42,19 @@ inside the normal Erlang.mk processing or even adding new rules.

You can load plugins using one of two methods. You can either load all plugins from a dependency, or just one. We will also cover conventions about writing external -plugins.

23.1. Loading all plugins from a dependency

To load plugins from a dependency, all you need to do is add +plugins.

24.1. Loading all plugins from a dependency

To load plugins from a dependency, all you need to do is add the dependency name to DEP_PLUGINS in addition to the list of dependencies.

For example, if you have cowboy in DEPS, add cowboy in DEP_PLUGINS also:

DEPS = cowboy
 DEP_PLUGINS = cowboy

This will load the file plugins.mk in the root folder of -the Cowboy repository.

23.2. Loading one plugin from a dependency

Now that we know how to load all plugins, let’s take a look +the Cowboy repository.

24.2. Loading one plugin from a dependency

Now that we know how to load all plugins, let’s take a look at how to load one specific plugin from a dependency.

To do this, instead of writing only the name of the dependency, we will write its name and the path to the plugin file. This means that writing DEP_PLUGINS = cowboy is equivalent to writing DEP_PLUGINS = cowboy/plugins.mk.

Knowing this, if we were to load the plugin mk/dist.mk from Cowboy and no other, we would write the following in our Makefile:

DEPS = cowboy
-DEP_PLUGINS = cowboy/mk/dist.mk

23.3. Writing external plugins

The plugins.mk file is a convention. It is meant to load +DEP_PLUGINS = cowboy/mk/dist.mk

24.3. Writing external plugins

The plugins.mk file is a convention. It is meant to load all the plugins from the dependency. The code for the plugin can be written directly in plugins.mk or be separate.

If you are providing more than one plugin with your repository, the recommended way is to create one file per plugin in the @@ -65,7 +65,7 @@ file:

THIS := $(dir $(realpath $(lastword $(MAKEF
 include $(THIS)/mk/dist.mk
 include $(THIS)/mk/templates.mk

The THIS variable is required to relatively include files.

This allows users to not only be able to select individual plugins, but also select all plugins from the dependency -in one go if they wish to do so.

23.4. Early-stage plugins

Plugins declared in DEP_PLUGINS are loaded near the end of Erlang.mk. +in one go if they wish to do so.

24.4. Early-stage plugins

Plugins declared in DEP_PLUGINS are loaded near the end of Erlang.mk. That’s why you have access to all previously initialized variables. However, if you want your plugin to add common dependencies to your applications, a regular is loaded too late in the process. @@ -79,7 +79,7 @@ BUILD_DEPS = common_deps DEP_EARLY_PLUGINS = common_deps

# In the plugin's early-plugins.mk
 DEPS += cowboy
 TEST_DEPS = ct_helper
-dep_ct_helper = git https://github.com/ninenines/ct_helper master

23.5. Loading plugins local to the application

If the Erlang.mk plugin lives in the same directory or repository as your +dep_ct_helper = git https://github.com/ninenines/ct_helper master

24.5. Loading plugins local to the application

If the Erlang.mk plugin lives in the same directory or repository as your application or library, then you can load it exactly like an external plugin: the dependency name is simply the name of your application or library.

For example, the following Makefile loads a plugin in the mk -- cgit v1.2.3