Directory structure for a release

Jay Nelson jay@REDACTED
Sun Apr 27 01:10:15 CEST 2003

I am trying to package up some code according to OTP
principles so that I can do code upgrade / downgrade
and have bootable nodes and a pool of clients.

I am probably getting confused between traditional code
partitioning and the OTP way so I wanted a little guidance.
I am trying to avoid having a lump of code that ends up
causing things like in the OTP distribution where some
useful utilities are part of the HTTP module and so on.
Since I am just starting now is the time to get the directory
partitioning right.

I have the following "code sets":

1) Utilities (bin_utils, tcp_proxy)
2) HTTP utilities (web_utils, ProxyModule)
3) Host supervisor

I've got all the lib/App/ebin, src, priv and so on, but my
question has to do with what is an app and what is a
code organization structure.

I expect to use #1 Utilities for many projects.  I expect to
use #2 HTTP Utilities only for this application.  Likewise
the hostsupervisor is specific to this application.

Originally, I thought to put all three in separate directories
and to have other directories for other shareable or non-
shareable pieces, but it means each becomes an app with
  *.app file and so on.  It also means (I believe) that they
are regarded as part of an application tree whether or not
they have processes running or are code-only.

Now I am wondering if one of the two following approaches
is better:

1) All in one directory
2) Host supervisor / HTTP utils in one; Utilities in other

Reasons for #1:
a) They are all part of a single application
b) Code upgrades can still occur on a module basis

Reasons for #2:
a) The first directory is really the application
b) Utilities is shareable to other applications

One of my concerns is whether code is compiled and/or
loaded if it is not used.  In other words, if I use the first
approach and dump everything in a single app directory
and later write a new app that uses some utilities, will it
require all the modules in the app directory or only the ones
listed in the script file.

What advantages and disadvantages are there to having
an app directory that contains only code and no processes
as in #2?  Does it make configuration harder with no gain
in code partitioning or loaded binaries?

If I write a 2nd application do I just dump it in the same
directory and write a different release configuration, or
should I go with approach #2 so that I create a new app

Is it best to have as few directories as possible under lib,
but at least one per bootable application?  Is there any
advantage to partitioning the directories on a finer scale
so that they are equivalent to libraries of related modules,
or should there be one big utilities library (code-only app)
containing all shareable code (a la stdlib)?


More information about the erlang-questions mailing list