Yes, we are definitely drifting away from the original problem. But I found it quite interesting also... :)<div><br></div><div>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... ;)</div>
<div><br></div><div>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?</div>
<div><br></div><div>How do you handle different version of the core app and of the dep apps? Could you give an example of this? e.g.</div><div><br></div><div>lib/</div><div>   coreapp-1.0/</div><div>      src/</div><div>      ebin/</div>
<div>      include/</div><div>      priv/</div><div>      deps/</div><div>         app1-1.0/</div><div>             src</div><div>             ebin</div><div>       ...</div><div>   coreapp-2.0/</div><div>      src/</div>
<div>      ebin/</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>      include/</div><div>      priv/</div><div>      deps/</div><div>         app1-1.1/</div><div>             src</div><div>             ebin</div>
<div>      ...</div><div>                     </div><div>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?</div>
<div><br></div><div>I hope I'm not totally on the wrong track here... </div><div><br></div><div>/siri</div><div><br></div><div><br><div class="gmail_quote">2012/1/13 Dmitry Demeshchuk <span dir="ltr"><<a href="mailto:demeshchuk@gmail.com">demeshchuk@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, Siri.<br>
<br>
I guess, we are moving away from the main conversation.<br>
<br>
Don't you think that it would be good to make reltool do the required<br>
job in a simpler way? The way we are discussing works in most cases,<br>
but it's quite unclear for the people who aren't very familiar with<br>
reltool.<br>
<br>
Using the existing functionalities to solve problems is often good,<br>
but if the solution becomes complicated, maybe a new functionality<br>
should be created instead.<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Jan 12, 2012 at 6:47 PM, Siri Hansen <<a href="mailto:erlangsiri@gmail.com">erlangsiri@gmail.com</a>> wrote:<br>
> Ah... this is interesting... a missing test case maybe - but I'm not sure if<br>
> it is a bug.<br>
><br>
> What happens is that the duplicated module erl_parse causes erlson to become<br>
> derived since a module with the same name is used by stdlib and several<br>
> other applications. If it was only stdlib, then I guess reltool could make<br>
> the assumption that the module to use is the one in the same application and<br>
> thus never make erlson derived (because to this module, that is). However,<br>
> since the module in this case is also used by other applications, this<br>
> assumption is not that obvious.<br>
><br>
> The easiest way to get around this right now is to be more specific in the<br>
> config file to make sure that erlson (or only the erl_parse module) is<br>
> excluded... e.g. by adding<br>
><br>
> {app, erlson, [{incl_cond,exclude}]} or<br>
> {app, erlson, [{mod,erl_parse,[{incl_cond,exclude}]}]}<br>
><br>
> (The latter would allow erlson to be derived if any of it's other modules<br>
> were used by other applications)<br>
><br>
> Regards<br>
> /siri<br>
><br>
> 2012/1/12 Dmitry Demeshchuk <<a href="mailto:demeshchuk@gmail.com">demeshchuk@gmail.com</a>><br>
>><br>
>> Try running this gist: <a href="https://gist.github.com/1600020" target="_blank">https://gist.github.com/1600020</a><br>
>><br>
>> reltool.config will reside in lib/gproc/rel/<br>
>><br>
>> Thank you.<br>
>><br>
><br>
<br>
<br>
<br>
</div></div><div class="HOEnZb"><div class="h5">--<br>
Best regards,<br>
Dmitry Demeshchuk<br>
</div></div></blockquote></div><br></div>