buildroot
Public
Source
committed 0fe05ff3e16xxxxxxxxxx// -*- mode:doc; -*-// vim: set syntax=asciidoc:=== Infrastructure for rebar-based packages[[rebar-package-tutorial]]==== +rebar-package+ tutorialFirst, let's see how to write a +.mk+ file for a rebar-based package,with an example :------------------------------01: ################################################################################02: #03: # erlang-foobar04: #05: ################################################################################06:07: ERLANG_FOOBAR_VERSION = 1.008: ERLANG_FOOBAR_SOURCE = erlang-foobar-$(ERLANG_FOOBAR_VERSION).tar.xz09: ERLANG_FOOBAR_SITE = http://www.foosoftware.org/download10: ERLANG_FOOBAR_DEPENDENCIES = host-libaaa libbbb11:12: $(eval $(rebar-package))--------------------------------On line 7, we declare the version of the package.On line 8 and 9, we declare the name of the tarball (xz-ed tarballrecommended) and the location of the tarball on the Web. Buildrootwill automatically download the tarball from this location.On line 10, we declare our dependencies, so that they are builtbefore the build process of our package starts.Finally, on line 12, we invoke the +rebar-package+ macro thatgenerates all the Makefile rules that actually allows the package tobe built.[[rebar-package-reference]]==== +rebar-package+ referenceThe main macro of the +rebar+ package infrastructure is+rebar-package+. It is similar to the +generic-package+ macro. Theability to have host packages is also available, with the+host-rebar-package+ macro.Just like the generic infrastructure, the +rebar+ infrastructure worksby defining a number of variables before calling the +rebar-package+macro.First, all the package metadata information variables that exist inthe generic infrastructure also exist in the +rebar+ infrastructure:+ERLANG_FOOBAR_VERSION+, +ERLANG_FOOBAR_SOURCE+,+ERLANG_FOOBAR_PATCH+, +ERLANG_FOOBAR_SITE+,+ERLANG_FOOBAR_SUBDIR+, +ERLANG_FOOBAR_DEPENDENCIES+,+ERLANG_FOOBAR_INSTALL_STAGING+, +ERLANG_FOOBAR_INSTALL_TARGET+,+ERLANG_FOOBAR_LICENSE+ and +ERLANG_FOOBAR_LICENSE_FILES+.A few additional variables, specific to the +rebar+ infrastructure,can also be defined. Many of them are only useful in very specificcases, typical packages will therefore only use a few of them.* +ERLANG_FOOBAR_USE_AUTOCONF+, to specify that the package uses _autoconf_ at the configuration step. When a package sets this variable to +YES+, the +autotools+ infrastructure is used.+.NoteYou can also use some of the variables from the +autotools+ infrastructure: +ERLANG_FOOBAR_CONF_ENV+, +ERLANG_FOOBAR_CONF_OPTS+, +ERLANG_FOOBAR_AUTORECONF+, +ERLANG_FOOBAR_AUTORECONF_ENV+ and +ERLANG_FOOBAR_AUTORECONF_OPTS+.* +ERLANG_FOOBAR_USE_BUNDLED_REBAR+, to specify that the package has a bundled version of _rebar_ *and* that it shall be used. Valid values are +YES+ or +NO+ (the default).+.NoteIf the package bundles a _rebar_ utility, but can use the generic one that Buildroot provides, just say +NO+ (i.e., do not specify this variable). Only set if it is mandatory to use the _rebar_ utility bundled in this package.* +ERLANG_FOOBAR_REBAR_ENV+, to specify additional environment variables to pass to the _rebar_ utility.With the rebar infrastructure, all the steps required to buildand install the packages are already defined, and they generally workwell for most rebar-based packages. However, when required, it isstill possible to customize what is done in any particular step: