Starting an Erlang Project, Part III

I’ve posted twice now about starting an Erlang project (one and two). I now have a directory structure and a Makefile that I’m happy with, plus some odds-and-ends from my first attempt at stubbing out an OTP application. I’m now going to begin again, with a healthy dose of Chapter 18 from Joe Armstrong’s book and a bit of Pete Kazmier’s Howto as well.

To remind you again, we’re calling this project “North Zulch” and prefixing all of our modules with “nz.” This sort of prefixing and underscoring seems to be the way that Erlang manages its namespace. It’s a bit ugly, but that’s the way it is. The first thing we want is an application callback module, more or less like we made before. We’ll name this file after the overall project: north_zulch.erl. Our first shot at this is:

-module(north_zulch).
-behaviour(application).
-export([ start/2, stop/1 ]).

start(_Type, _StartArgs) ->
    io:format("north_zulch is starting~n"),
    {ok, self()}.

stop(_State) ->
    io:format("north_zulch has stopped~n"),
    ok.

This obviously doesn’t do anything interesting at all, but it’s a good place to start. The start/2 function prints out a little message and then returns a tuple of the term ok and our process id. Generally, this process id will be for a supervisor, but right now we just give it this. stop/1 does a similar thing, but without a process id. Note that we prefix the various arguments with underscores to indicate that we’re not interested in the values. We put north_zulch in our MODULES list in the Makefile, run make to compile it and then run erl -pa ebin, which fires up Erlang and looks in the ebin directory for .beam files. Now we get

Erlang (BEAM) emulator version 5.5.5

Eshell V5.5.5  (abort with ^G)
1> north_zulch:start(foo,bar).
north_zulch is starting
{ok,<0.31.0>}
2> north_zulch:stop(foo).
north_zulch has stopped
ok

We give the two functions dummy values (since we aren’t using them), or we’ll get an error. So, this seems to work. However, the whole point is that this is an application callback module. We want to be able to deal with it as an OTP application. To do that we have to create an .app file, which we place in the ebin directory, named north_zulch.app. This file tells the application what to do with us.

%% -*- erlang -*-
{application, north_zulch,
 [{description, "North Zulch Master"},
  {vsn, "1.0"},
  {modules, []},
  {registered, []},
  {applications, [kernel, stdlib]},
  {mod, {north_zulch, []}},
  {env, []},
  {start_phases, []}
 ]}.

I won’t go into detail about this, but the important bits are: the first thing in the tuple must be the term application, followed by the name of the application – which must also be the name of the file. You can give it a description and a version number. You need to make sure to include the kernel and stdlib applications, because pretty much everything uses these. The mod field needs to be your application callback module, along with the arguments that will eventually get handed to start/2. Also, for you folks that care about such things, the top line sends Emacs into Erlang-mode, which it would not be in by default for a file ending in .app. Now, we can fire up our application like this:

Erlang (BEAM) emulator version 5.5.5

Eshell V5.5.5  (abort with ^G)
1> application:start(north_zulch).
north_zulch is starting
ok
2> application:stop(north_zulch).
north_zulch has stopped

=INFO REPORT==== 24-Jan-2008::14:32:32 ===
    application: north_zulch
    exited: stopped
    type: temporary
ok

Now I’m going to invoke (very slightly) deeper magic to allow us to run our application via “make run” on the command line like this:

$ make run
Running application north_zulch...
north_zulch is starting
north_zulch has stopped
$

The Makefile changes are:

APP       = north_zulch
MODULES   = $(APP)

--- SNIP ---

run: all
	@echo "Running application $(APP)..."
	@ $(ERL) -pa $(BINDIR) -eval 'application:start($(APP)).' \
               -noshell -s init stop

and remember – there are tabs before the commands, not spaces.

In the next installment, we’ll look at making the application actually do something – like run a supervisor, for instance.

2 Responses to “Starting an Erlang Project, Part III”

  1. Anonymous

    Joe Anderson?? His name is Armstrong.

  2. Ryan

    Oh yes, you’re right. Fixed.

Leave a Reply

You must be logged in to post a comment.