Directory structure for a release
Sun Apr 27 20:30:21 CEST 2003
(I had a longer answer to this almost ready, but Outlook Express
segfaulted and left nothing of it, so here's a short answer)
- Unless you run with the '-mode embedded' flag, erlang will not
load modules unless they are actually called.
- How you want to organize your code is pretty much up to you
and your administrative routines, but OTP's release handler
likes to upgrade code on a per-application basis. This is
rather an argument for _more_ applications than fewer.
- I would try to create my applications so that each module in
an application logically belongs there. Typically, I would try to
have one interface module (possibly a few) for one application,
and keep only modules in there that are specific to implementing
- It is perhaps useful to have a 'utilities' grab-bag application for
those modules that don't seem to belong anywhere else, but I
personally don't think it should be the norm.
- It's perfectly OK to have several code roots (several lib/ directories),
if you feel that that's a more comfortable way to organize your code.
- To build different "systems", I'd create different "release" directories,
under which I'd collect database, logs, application-specific files, and
OTP release handler scripts. All the code might well reside in one
place, under one lib (just be careful then with
----- Original Message -----
From: "Jay Nelson" <jay@REDACTED>
Sent: den 27 april 2003 01:10
Subject: Directory structure for a release
> 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