Directory structure for a release

[Chris Pressey]

On Sat, 26 Apr 2003 16:10:15 -0700
Jay Nelson <jay@REDACTED> wrote:

> [...]
> 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.

For what it's worth, my thought is that if those utilities are really
shareable and they aren't in a seperate application, that will force
other systems that do share them to include the entire ensemble.

In your case, does it make sense to make all systems that use bin_utils,
also have the host supervisor installed?  If so, package them together,
and if not, don't.  Not always that simple of course, but like that.

Library applications do seem a bit non-intuitive, but aside from that I
don't think there's any reason not to use them.

I would, however, recommend against grouping all utilities together
simply because they're all utilities.  I now have a monolithic shared
library application that is bigger than most of the applications that
use it, and most of them only use a fraction of what's in it.

I sometimes wonder if it wouldn't be better to have a global "grab bag"
of handy, pre-tested, generic functions to be copy-pasted into code...

-Chris