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

[Siri Hansen]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120113/603a62bc/attachment.htm>