[erlang-questions 71] Erlang release generation

Sam Bobroff <>
Mon Mar 28 08:07:12 CEST 2011

Hi Erlangers,

I've been trying to work out how to "properly" build Erlang releases (on
a Linux system, to be deployed on another Linux system), and I'm getting
nowhere fast so I'm hoping someone here will have some useful pointers
or hints to help me out. I'm using Erlang R14B, but I assume the
problems I'm having are to do with understanding, rather than bugs so
the version probably doesn't matter much ;-)

For context, I've read a lot of the online Erlang documentation
including the sections on systools, reltool, sys, rel (and I've read the
Rebar documentation as well, I'll get to that later) and I'm familiar
with setting up OTP applications but this issue is confusing me more and
more: there doesn't seem to be any kind of overview that tells me how
the various pieces fit together or what I'm supposed to do. Is there
some standard document I'm missing?

"All" I want to do is go from a set of Erlang source, representing one
or more applications (presumably in a set of src and ebin dirs), to an
installed Erlang system that will start those applications. (Which I'm
obviously intending to package up for distribution but that's a separate

I realize I'm rambling so I'll try to phrase some specific questions:

Is reltool:create_target() the correct way to build a release?

If so, how do I get reltool:create_target() to include my apps? I've
tried using lib_dirs and -pa in various combinations but I always get
"Release NAME uses non existing application APP". I haven't yet tried
installing my application directly to the system Erlang
(/usr/lib/erlang/lib in my case) because the reltool doc clearly states
that "Applications may also be located outside root_dir ...". Does this
just not work? I'm not keen on installing my apps into the system Erlang
(as root) just so that I can build a release!

I've discovered that if I use reltool:create_target() to build a release
(and don't include any custom apps, so it works), I can't then use that
release as a development environment because running reltools fails on
all applications, even kernel. It seems to be that reltool doesn't
understand that things have been packaged up as .ez files because
manually extracting them all allows it to succeed. Is there a way to get
reltool to build a release that isn't zipped up, or to understand the
zipped files?

Should I instead be following the "target_system" module that's in the
"Creating a First Target System" section of the documentation? It seems
pretty odd to cut and paste a big chunk of example code out of the docs
to do a basic task... and it's also very slow because of the way it tars
everything up just to untar it again. This is, however, the only way
I've managed to get a release of my own app actually built.

Should I just build .rel files by hand and basically re-implement
target_system.erl (but more the way I want it to work)?

I've also tried using rebar, but I'm getting the same problem: I can't
get the created release to include any of my own applications. Here's
exactly what I tried:

mkdir rebar-tmp
cd rebar-tmp
wget http://hg.basho.com/rebar/downloads/rebar
chmod +x rebar
mkdir mysample
cd mysample
../rebar create-app appid=mysample
../rebar compile
cd ..
mkdir rel
cd rel
../rebar create-node nodeid=mysample
cd ..
echo '{sub_dirs, ["rel"]}.' > rebar.config
./rebar generate

(Runs successfully, but no mysample is included, as expected.)

edit rel/reltool.config and add "{lib_dirs, ["../../"]} to the top sys
list, ", mysample" to the mysample rel tuple and ",{app, mysample,
[{incl_cond, include}]}" to the top sys list (exactly following the
rebar documentation).

./rebar generate

And I get:

==> rel (generate)
{"init terminating in do_boot","Release mysample uses non existing
application mysample"}

Crash dump was written to: erl_crash.dump
init terminating in do_boot (Release mysample uses non existing
application mysample)

What am I doing wrong? :-)

Thanks for reading all the way :-)


More information about the erlang-questions mailing list