Question

In my app, I have dir structure close to the following:

src/
  api/
    server.erl
    model.erl
  common/
    common_stuff.erl
    util.erl
  some_app.erl
  some_server.erl
  something_else.erl
  some_app.app.src

Files that reside in subdirs (common, api etc) are namespaced in a usual package style.
For example, src/common/util.erl is declared as:

-module(common.util).

src/api/server.erl is declared as:

-module(api.server).

and so on.

rebar compile works perfectly and generates appropriate subdir tree in ebin:

ebin/
  api/
    server.beam
    model.beam
  common/
    common_stuff.beam
    util.beam
  some_app.beam
  some_server.beam
  something_else.beam
  some_app.app

But, rebar generate only copies top-level files to the rel dir:

rel/some_app/lib/some_app-0.0.2/ebin/
  some_app.beam
  some_server.beam
  something_else.beam
  some_app.app

Everything that resides in subdirs is not copied over to release. Thus, when I try to start generated release, I immediately get this kind of error message:

{"init terminating in do_boot",{'cannot load','api.server',get_files}}

Crash dump was written to: erl_crash.dump
init terminating in do_boot ()

My rebar-generated ebin/some_app.app does list all the required modules:

{application,some_app,
             [{description,"0.0.2"},
              {vsn,"0.0.2"},
              {registered,[]},
              {applications,[kernel,stdlib,sasl]},
              {mod,{some_app,[]}},
              {env,[]},
              {modules,['api.server','api.model','common.common_stuff',
                        'common.util', some_app, some_server,
                        something_else]}]}.

Does anybody know how to make “rebar generate” respect ebin’s subdirs? I believe this could be reltool’s problem as well.

Thanks.

Answer 1

Only flat application structures are well supported by erlang·

“Packages has since it was introduced more than 5 years ago been an experimental feature. Use it at your own risk, we do not actively maintain and develop this feature. It might however be supported some day.

In spite of this packages work quite well, but there are some known issues in tools and other parts where packages don’t work well.”

http://www.erlang.org/doc/man/packages.html