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

[Dmitry Demeshchuk]

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