How to compile an Erlang application into executable binary and run it?

Question

Now I am learning Erlang and I have a question about kind of running and testing Erlang applications.

We have some views of running and testing Erlang programs:

We can run Erlang shell and test in there our function.
We can compile some files with our Erlang code, than create .app file, and then again run Erlang shell and call application:start(AppName).

My question: Can we make binary executable file from Erlang code, Like C code? How can I run programmes without Erlang shell, in a way that I can run program, input something command and after that calls Erlang functions for this command?

For example I have a module (test.erl) with three functions:

foo1() -> ...

foo2() -> ...

foo3() -> ...

Then I want to run the programme in terminal and input -a flag to call function foo1, -b flag for foo2 and so on.

Hamidreza Soleimani Hamidreza Soleimani · Accepted Answer · 2015-12-28T10:22:05

Let me divide the answer into three parts:

1. Running Erlang Applications

As Erlang source code (.erl files) compiled to BEAM bytecode (.beam files) and then run on top of Erlang virtual machine (BEAM), so There is no option for creating a stand-alone binary without the need of the virtual machine. But there are ways for packing, building, porting, upgrading and running Erlang applications based on OTP which is its formal platform.

A. Command-line flags

Imagine we developed an application with foo name, now we can start it with a set of flags just like this:

$ erl \
-pa path/to/foo \
-s foo \
-sname foo_node \
-setcookie foo_secret \
-noshell -noinput > /path/to/foo.log &

-pa adds the specified directory to the path
-s starts the foo application
-sname makes it distributed with a short name
-setcookie sets a cookie for making a minimum level of security
-noshell starts erlang without shell
-noinput doesn't let to read any input from shell

Then we can stop it with following command:

$ erl \
-sname stop_foo_node \
-setcookie foo_secret \
-eval 'rpc:call(foo, foo_node, stop, []), init:stop()' \
-noshell -noinput > /path/to/foo.log &

-eval evaluates the given expressions

And also we can attach to the foo application shell with this command:

$ erl \
-sname debug_foo_node \
-setcookie foo_secret \
-rmesh foo_node

-rmesh makes a remote shell to given node

We can put above commands into a makefile or shell script for using them simply. Also for finer grained control over the start-up process of the system we can use a boot script file and specify it with -boot flag. The boot file contains instructions on how to initiate the system, which modules and applications we are dependant on, and also contains functions to restart, reboot and stop the system. The process of creating and using boot script is well documented in Erlang documentation website.

B. Release tool

The other way that automates and integrates most of the works for us is reltool which is a standard and fully featured release management tool. We can specify our application version, boot script, dependencies, and so on in reltool config file and create a portable release. This is a sample structure of an Erlang/OTP application compatible with reltool:

├── deps
│   └── ibrowse
├── ebin
│   ├── foo.app
│   ├── foo_app.beam
│   └── foo_sup.beam
├── rebar.config
├── rel
│   ├── files
│   ├── foo
│   └── reltool.config
└── src
    ├── foo_app.erl
    ├── foo.app.src
    └── foo_sup.erl

We can use Rebar which is an Erlang build tool for making it even simpler to create Erlang application and also releases. There is a detailed tutorial on how to use Rebar for such task.

2. Testing Erlang applications

There are two standard test frameworks for Erlang applications:

Eunit: It is a standard unit-testing framework of OTP which can test a function, a module, a process or even an application.
CommonTest: It is another standard test framework of OTP that provides structures for defining local or distributed test scenarios and manages to run, log and report the results.

It is a common practice to combine them together for both white-box and black-box testing. Also Rebar provides rebar eunit and rebar ct commands for automating their execution.

3. Passing command-line argument

Using init:get_argument/1 we can retrieve user defined flags to decide upon them as follows:

$ erl -foo foo1 foo2 -bar bar1
1> init:get_argument(foo).
{ok,[["foo1","foo2"]]}
2> init:get_argument(bar).
{ok,[["bar1"]]}