[erlang-questions] Re: [erlang-questions 71] Erlang release generation

[Per Melin]

2011/3/29 Håkan Mattsson <hm@REDACTED>:
> On Mon, Mar 28, 2011 at 10:31 PM, Per Melin <per.melin@REDACTED> wrote:
>
>> (Since R14 I don't think you need the {app, foo, [{incl_cond,
>> include}]} anymore if you list your app in the rel-tuple.)
>
> Yes, this simplification was introduced in reltool 0.5.4 (april 2010). In order
> to include an application in the target system it does now suffice to
> list it in a
> release (rel-tuple). All dependent applications will also be included.
> It is only
> when you want to process an application differently than the others that you
> need to explicitly add it as an application (app-tuple). Further you do not
> need to bother about kernel and stdlib. They are automatically included in
> all releases as they are mandatory.

While we're on the subject, here are a couple of minor gotchas that
could possibly be improved in future versions of reltool:

1. Where the .rel is placed.
A release named "foo" with version "001" created with
reltool:create_target/2 in target directory "foo_001" will get this
.rel file:
foo_001/releases/001/foo.rel

But that is not what release_handler expects. So you need to move and
possibly rename the file to:
foo_001/foo_001.rel

2. start.boot.
For the same release you get a boot file called foo.boot. But
release_handler will barf unless there is a start.boot (which I
believe is really irrelevant unless you run in embedded mode with the
default scripts). So maybe when you include the option {boot_rel,
"foo"} that could mean that foo.boot will instead be called
start.boot?