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

[Dmitry Demeshchuk]

Also, answering your last question: no, I'm not expecting reltool to
automatically include deps (but this is a thing to consider, maybe
it's not bad). I expect to be able to add a certain app dir, so
reltool.config from my previous example will be something like this:

{lib_dirs, ["../deps"]}.
{explicit_lib_dirs, [".."]}.

Thank you.

On Fri, Jan 13, 2012 at 8:18 PM, Dmitry Demeshchuk <demeshchuk@REDACTED> wrote:
> Here's a more certain example.
>
> =========================================================================================
>
> Say, I clone some repository from GitHub (say, gproc, like in my
> example gist). Now I add some stuff to it and want to build a release.
> Here's how it should look:
>
> some_dir/
>    gproc/
>        src/
>        include/
>        ebin/
>        priv/
>        deps/
>        rel/
>           reltool.config
>           files/      (this contains starting bash scripts, default
> config file and so on)
>           gproc/     (this directory will be actually generated by
> rebar when running "rebar generate"; in fact, most of its content is
> generated by reltool)
>                erts-5.8.5/
>                lib/
>                priv/
>                releases/
>
>
> So, my release will run from "rel/gproc".
>
> Now, if I generate a release upgrade to release 2.0, I make some
> changes, do "rebar generate-appups && rebar generate-upgrade" and a
> new release package is created:
>
> rel/gproc/releases/gproc-2.0.tar.gz
>
> Then I just remsh to my running node and install the new release using
> release_handler.
>
> ================================================================================
>
> What I want here is to be independent from the top-level folder
> (some_dir). Maybe I have more Erlang projects there, maybe just some
> pictures, books and MongoDB logs, it can be anything.
>
> For now, the only thing I can do without doing anything with directory
> structure is adding to reltool.config this:
>
> {lib_dirs, ["../.."]}.
>
> or in an absolute way:
>
> {lib_dirs, ["/home/me/some/path/some_dir"]}.
>
>
> Does this make sense?
>
> On Fri, Jan 13, 2012 at 7:56 PM, Siri Hansen <erlangsiri@REDACTED> wrote:
>> Yes, we are definitely drifting away from the original problem. But I found
>> it quite interesting also... :)
>>
>> Anyway - I'm not against introducing new functionality if it is needed - but
>> I do believe in doing a good investigation in order to ensure (or at least
>> attempt) the best possible solution. The problem for me was that I did not
>> really understand the problem. I'm not sure if I still do (sorry!) - but
>> I'll try to explain what I think you mean. Please correct me if (when) I'm
>> wrong... ;)
>>
>> I think that what you suggest is to be able to point out one specific
>> application directory instead of specifying one or more lib dirs. And the
>> reason for this is that you have several applications stored under the same
>> lib dir, which are not necessarily at all related to each other. And
>> typically - for each core application (which forms the main functionality of
>> a release), you have it's dependency applications stored in the deps
>> directory under the core application itself. Is this correct?
>>
>> How do you handle different version of the core app and of the dep apps?
>> Could you give an example of this? e.g.
>>
>> lib/
>>    coreapp-1.0/
>>       src/
>>       ebin/
>>       include/
>>       priv/
>>       deps/
>>          app1-1.0/
>>              src
>>              ebin
>>        ...
>>    coreapp-2.0/
>>       src/
>>       ebin/
>>       include/
>>       priv/
>>       deps/
>>          app1-1.1/
>>              src
>>              ebin
>>       ...
>>
>> And, when specifying the explicit app dir, would you expect reltool to
>> automatically include the deps directory in the selected coreapp-Vsn as a
>> lib dir?? Or should there be a way to specify that also?
>>
>> I hope I'm not totally on the wrong track here...
>>
>> /siri
>>
>>
>> 2012/1/13 Dmitry Demeshchuk <demeshchuk@REDACTED>
>>>
>>> Hi, Siri.
>>>
>>> I guess, we are moving away from the main conversation.
>>>
>>> Don't you think that it would be good to make reltool do the required
>>> job in a simpler way? The way we are discussing works in most cases,
>>> but it's quite unclear for the people who aren't very familiar with
>>> reltool.
>>>
>>> Using the existing functionalities to solve problems is often good,
>>> but if the solution becomes complicated, maybe a new functionality
>>> should be created instead.
>>>
>>> On Thu, Jan 12, 2012 at 6:47 PM, Siri Hansen <erlangsiri@REDACTED> wrote:
>>> > Ah... this is interesting... a missing test case maybe - but I'm not
>>> > sure if
>>> > it is a bug.
>>> >
>>> > What happens is that the duplicated module erl_parse causes erlson to
>>> > become
>>> > derived since a module with the same name is used by stdlib and several
>>> > other applications. If it was only stdlib, then I guess reltool could
>>> > make
>>> > the assumption that the module to use is the one in the same application
>>> > and
>>> > thus never make erlson derived (because to this module, that is).
>>> > However,
>>> > since the module in this case is also used by other applications, this
>>> > assumption is not that obvious.
>>> >
>>> > The easiest way to get around this right now is to be more specific in
>>> > the
>>> > config file to make sure that erlson (or only the erl_parse module) is
>>> > excluded... e.g. by adding
>>> >
>>> > {app, erlson, [{incl_cond,exclude}]} or
>>> > {app, erlson, [{mod,erl_parse,[{incl_cond,exclude}]}]}
>>> >
>>> > (The latter would allow erlson to be derived if any of it's other
>>> > modules
>>> > were used by other applications)
>>> >
>>> > Regards
>>> > /siri
>>> >
>>> > 2012/1/12 Dmitry Demeshchuk <demeshchuk@REDACTED>
>>> >>
>>> >> Try running this gist: https://gist.github.com/1600020
>>> >>
>>> >> reltool.config will reside in lib/gproc/rel/
>>> >>
>>> >> Thank you.
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Dmitry Demeshchuk
>>
>>
>
>
>
> --
> Best regards,
> Dmitry Demeshchuk



-- 
Best regards,
Dmitry Demeshchuk