[erlang-questions] Re: Distributions of Erlang-coded SW on Windows (really)

[Hakan Mattsson]

On Fri, Aug 14, 2009 at 11:05 AM, Benjamin Tolputt<btolputt@REDACTED> wrote:

> Erlang/OTP is, by design, a platform best suited to running servers.
> Client applications generally don't need to be running thousands of
> processes (with the possible exception of games - my particular
> interest), so the primary benefits are lost. Not that they aren't useful
> or such like, just that the benefits Erlang can provide give best "bang
> for your buck" on server architectures :)
>
> As such, I've found Erlang developers are less worried about the ease of
> initial deployment (especially on Windows platforms) because it is not
> that common an occurrence for them. Updating an existing deployment on
> the other hand is a well explored topic.

There are work in progress in the areas of packaging and stand-alone
applications within Erlang/OTP. Some of it has already been released
but there are more in the pipe.

Stand-alone. Instead of trying to package an entire Erlang system into
one single executable file we are aiming at rather few files (10?).
Such a stand-alone system will have the same directory structure as a
development system. It is already today possible to create such systems
but more automation is needed.

Archives. In order to shrink the number of files in an Erlang
installation, we have made a few changes in the code loading mechanism
to enable loading of code from archive files. An archive file contains
a complete application or parts of an application. But if the
application contains drivers or port programs, these must be situated
outside the archive file. When you choose what parts of the
application that should be included in the archive it is done on
subdirectory basis. For example src, doc, ebin, priv etc. See the
documentation of the 'code' module for more info.

Escript. Escripts may nowdays contain an archive file which may
contain single .beam and .erl files. But the archive may also contain
entire applications. When you create an archive file and put it in an
escript you get an executable program (at least on UNIX). But that
executable program is today dependent on an already installed runtime
system. In a coming release it will be possible to have a stand-alone
system containing both escript(s) and the runtime system. Then you
will have a bin directory with your escripts and a stripped runtime
system that only contains the files that the escript(s) needs. In
order to make escripts more useful it is nowdays possible to hardcode
command line options to the emulator in the header of the escript. See
the documentation of the 'escript' module for more info.

Reltool. Reltool is a tool that both can analyze dependencies between
applications on module level and generate customized target systems as
a file tree. What you want to do with the generated file tree is up to
you. You may want to package it as a tar-file, zip-file, rpm-file,
deb-file, windows installer etc. In its current shape the target
generation part of reltool it is not so useful, but you can already
today use reltool to determine which dependencies your application (or
escript) have to other applications and modules. Reltool will improve
in coming releases.

Installer. In order to use a newly downloaded Erlang system today it
is not enough to unpack the files in the distribution and start the
system. You must also run an installer that patches hardcoded paths
into some files. In a coming release it will be possible to just
unpack and run without prior use of an installer.

/Håkan
---
Håkan Mattsson (uabhams)
Erlang/OTP, Ericsson AB