Directory structure for a release

[Chris Williams]

> 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?
The boot script lists what modules that are defined by the modules
parameter in your application file ("app" file).
(See http://www.erlang.se/doc/doc-5.2/lib/kernel-2.8.0/doc/html/app.html)
This file should be in the "ebin" directory of your application.

When the boot script is generated it fetches the module information from
all "app" files. i.e. all applications files (Including erlangs)
that are defined in your "rel" file.
(http://www.erlang.se/doc/doc-5.2/lib/sasl-1.9.4/doc/html/rel.html)

If you use the flag '-mode embedded' it will only load the modules that
are defined in your generated boot file.
//Chris
ps  You can look in the "script" file that is generated at the same time
as the boot file to see what files are loaded.


On Sun, 27 Apr 2003, Jay Nelson wrote:

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