2 // vim: set syntax=asciidoc:
4 === Infrastructure for rebar-based packages
6 [[rebar-package-tutorial]]
8 ==== +rebar-package+ tutorial
10 First, let's see how to write a +.mk+ file for a rebar-based package,
13 ------------------------------
14 01: ################################################################################
18 05: ################################################################################
20 07: ERLANG_FOOBAR_VERSION = 1.0
21 08: ERLANG_FOOBAR_SOURCE = erlang-foobar-$(ERLANG_FOOBAR_VERSION).tar.xz
22 09: ERLANG_FOOBAR_SITE = http://www.foosoftware.org/download
23 10: ERLANG_FOOBAR_DEPENDENCIES = host-libaaa libbbb
25 12: $(eval $(rebar-package))
26 --------------------------------
28 On line 7, we declare the version of the package.
30 On line 8 and 9, we declare the name of the tarball (xz-ed tarball
31 recommended) and the location of the tarball on the Web. Buildroot
32 will automatically download the tarball from this location.
34 On line 10, we declare our dependencies, so that they are built
35 before the build process of our package starts.
37 Finally, on line 12, we invoke the +rebar-package+ macro that
38 generates all the Makefile rules that actually allows the package to
41 [[rebar-package-reference]]
43 ==== +rebar-package+ reference
45 The main macro of the +rebar+ package infrastructure is
46 +rebar-package+. It is similar to the +generic-package+ macro. The
47 ability to have host packages is also available, with the
48 +host-rebar-package+ macro.
50 Just like the generic infrastructure, the +rebar+ infrastructure works
51 by defining a number of variables before calling the +rebar-package+
54 First, all the package metadata information variables that exist in
55 the generic infrastructure also exist in the +rebar+ infrastructure:
56 +ERLANG_FOOBAR_VERSION+, +ERLANG_FOOBAR_SOURCE+,
57 +ERLANG_FOOBAR_PATCH+, +ERLANG_FOOBAR_SITE+,
58 +ERLANG_FOOBAR_SUBDIR+, +ERLANG_FOOBAR_DEPENDENCIES+,
59 +ERLANG_FOOBAR_INSTALL_STAGING+, +ERLANG_FOOBAR_INSTALL_TARGET+,
60 +ERLANG_FOOBAR_LICENSE+ and +ERLANG_FOOBAR_LICENSE_FILES+.
62 A few additional variables, specific to the +rebar+ infrastructure,
63 can also be defined. Many of them are only useful in very specific
64 cases, typical packages will therefore only use a few of them.
66 * +ERLANG_FOOBAR_USE_AUTOCONF+, to specify that the package uses
67 _autoconf_ at the configuration step. When a package sets this
68 variable to +YES+, the +autotools+ infrastructure is used.
71 You can also use some of the variables from the +autotools+
72 infrastructure: +ERLANG_FOOBAR_CONF_ENV+, +ERLANG_FOOBAR_CONF_OPTS+,
73 +ERLANG_FOOBAR_AUTORECONF+, +ERLANG_FOOBAR_AUTORECONF_ENV+ and
74 +ERLANG_FOOBAR_AUTORECONF_OPTS+.
76 * +ERLANG_FOOBAR_USE_BUNDLED_REBAR+, to specify that the package has
77 a bundled version of _rebar_ *and* that it shall be used. Valid
78 values are +YES+ or +NO+ (the default).
81 If the package bundles a _rebar_ utility, but can use the generic
82 one that Buildroot provides, just say +NO+ (i.e., do not specify
83 this variable). Only set if it is mandatory to use the _rebar_
84 utility bundled in this package.
86 * +ERLANG_FOOBAR_REBAR_ENV+, to specify additional environment
87 variables to pass to the _rebar_ utility.
89 With the rebar infrastructure, all the steps required to build
90 and install the packages are already defined, and they generally work
91 well for most rebar-based packages. However, when required, it is
92 still possible to customize what is done in any particular step:
94 * By adding a post-operation hook (after extract, patch, configure,
95 build or install). See xref:hooks[] for details.
97 * By overriding one of the steps. For example, even if the rebar
98 infrastructure is used, if the package +.mk+ file defines its
99 own +ERLANG_FOOBAR_BUILD_CMDS+ variable, it will be used instead
100 of the default rebar one. However, using this method should be
101 restricted to very specific cases. Do not use it in the general