[erlang-questions] Ability to add app directories explicitly for reltool

Garret Smith garret.smith@REDACTED
Tue Dec 20 20:25:17 CET 2011


My rebar/reltool setup is doing close to what you describe as the "ideal"
way.

Relevant project structure is:

apps/
    app1
    app2

deps/
    <rebar-managed deps here>

rel/
    reltool.config

My rebar.config looks like:
{lib_dirs, ["apps"]}.

{sub_dirs, [
        "apps/app1",
        "apps/app2",
        "rel"]}.

{deps, [...]}.

My reltool.config looks like (cut-n-pasted pieces here):

{sys, [
       {lib_dirs, ["../apps", "../deps"]},
       {rel, "start", "1",
        [
         app1,
         app2,
         dependent_app1,
         dependent_app1
        ]},
       {rel, "start_clean", "",
        [
         kernel,
         stdlib
        ]},
       {app, app1, [{incl_cond, include}]},
       {app, app1, [{incl_cond, include}]},
       {app, dependent_app1, [{incl_cond, include}]},
       {app, dependent_app2, [{incl_cond, include}]}
}.


With this setup, rebar & reltool take the apps under apps/ and deps/ and
creates a target release for me.

Is this what you are looking for?

-Garret

On Tue, Dec 20, 2011 at 11:12 AM, Dmitry Demeshchuk <demeshchuk@REDACTED>wrote:

> Hello, Siri and everyone.
>
> Recently I've been trying to start using OTP releases in our projects
> with help of rebar. However, I faced the following problem.
>
> Rebar expects that *all* Erlang code resides in some directory
> (generally, "deps" folder) or several directories. This is a reltool
> strict requirement, as far as I understand. Unlike, Riak, all our
> applications have the following directory structure:
>
> .
> ..
> deps/
> ebin/
> include/
> priv/
> src/
>
> So, we pull some libraries (and sometimes smaller applications) as
> deps, but the main application's code resides in the root application
> folder. And there's no way to make reltool include this code into the
> generated release, or at least I don't see it.
>
> For now, there are 2 ways for me to solve this without affecting reltool
> itself:
>
> 1. For all apps, make another repository that just pulls our
> application and all its deps, so the actual application code resides
> in the deps/ dir as well, and generate the release package from it.
> However, this seems like an overhead to me. Moreover, this isn't
> convenient for development.
>
> 2. I made a hack that creates symlinks in the deps/ dir, so that it
> seems to reltool that the core application actually resides in the
> deps/ folder, so it's included into the release. Obviously, this is
> kinda ugly and potentially buggy, forget total Windows
> incompatibility. Initially, this was a pull request to rebar but after
> some thinking me and one of rebar's maintainers agreed that it's
> better to make this code a rebar plugin.
>
> So, as you can see, both of the solutions aren't perfect. The ideal
> way I can see is an ability to set explicit app directories in
> reltool.config, like:
>
> {explicit_app_dirs, ["/apps/myapp1"]}.
>
> Probably, it won't make any other use besides the problem I'm
> describing here, but at least it's quite general and doesn't seem like
> a hack. Maybe there's a better way that I didn't come up with. Or
> maybe reltool can do what I want, and I just don't know about such an
> ability.
>
> This seems like a very useful feature. I know that many people use
> just the same directory structure in their projects. Also, rebar
> maintainers already gave me their +1 to this. I'll be glad to work on
> the patch if we come up with a good solution.
>
> Thank you.
>
>
> --
> Best regards,
> Dmitry Demeshchuk
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111220/2d808f9c/attachment.htm>


More information about the erlang-questions mailing list