Directory structure for a release

[Jay Nelson]

Chris wrote:

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

This is one of my biggest fears because my goal is to
make an embedded bootable application that runs from
flash or a network loadable image.

Does the boot script list only the modules that are actually
used, or does it list all modules in a given application?  Or
more to the point, in an embedded system, are only the
used modules loaded or all modules loaded that are part
of any application that is loaded?

Is there some sort of tree-shaker utility that eliminates
module functions that are not called from the code?  This
would be difficult in the case of {M, F, A} type calls, but
is there any tool for the static utility code?

I have pretty much settled on one utility application which
has no processes and no included applications for
things like lists, bin_utils and proxies that are all generally
useful, and a separate application for the externally
visible functionality.  I understand why OTP likes to do
things on an application level, but at some point the web
of directories is difficult to maintain so I am trying to
reduce the number of applications as much as possible.

If my catch-all utility application gets too big, I will separate
it into pieces and organize them into a hierarchy of related
utility applications so that my top-level application can often
just include a single utility application (which may include
sub-hierarchy utility applications).  For now I expect I'll end
up with 5-10 utility modules and hope that a particular
application will only load the ones that it uses.

jay