[erlang-questions] Reltool error: "Module potentially included by two different applications"

[Eduard Sergeev]

Hi Siri,

Thank you for responding to my post!

Since you haven't included your reltool config file
>

Fair enough. To simplify things I've now created a simple project which 
illustrates my first post with a real code: 
https://github.com/EduardSergeev/potentially_included/tree/error
If you have *rebar* installed you can build the entire thing with: *rebar 
clear compile *then *cd* to *./rel* and do *rebar generate -f* (runs 
reltool) which will demonstrate the original error.
This project basically contains only two custom apps 'main' and 'library' 
where 'main' uses (depends) on 'library' and 'library' also includes dummy 
module 'eunit_lib' - to simulate a duplication with the original module 
from the system app 'eunit'. Apart from that 'main' also includes some 
other standard apps to make it more 'real' (but *not* 'eunit').
 

>  I'm just guessing that it looks (maybe simplified) something like this:  
>
{sys,[{lib_dirs,["<my_lib_dir>"]},
>       {incl_cond,derived},
>       {app,<my_app>,[{incl_cond,include}]}
>      ]}.
>

Pretty much so: 
https://github.com/EduardSergeev/potentially_included/blob/error/rel/reltool.config (with 
some rebar flavour in the form of '{target_dir, "main"}')
 

> and that <system_app> exists in <my_lib_dir>.
>

Not exactly. The <system_app> is only happened to be installed on my local 
'target system' but is not a part of this project, so it is not in 
<my_lib_dir>, but it is apparently included by reltool from my 
`code:root_dir/0` due to default settings {incl_cond, derived} on 'sys' 
level. At least this is my understanding.
 

> If this is close to correct, then what you ask reltool to do is
>
> "Take my erlang installation and also look in <my_lib_dir> and figure out 
> which applications and modules I need to include in my release so that all 
> dependencies of <my_app> are taken care of."
>
> And to be very strict - it could(!!) be that you want <my_app> to use the 
> <some_module> from <system_app> and not from <my_app> itself... but I 
> realize that it is not very likely. At least not if <some_module> is the 
> only relation between <my_app> and <system_app>... So the question is if 
> this is ALWAYS the case??
>

Yes, now after your explanation I think I understand that if the 
application from both `{sys,[{lib_dirs,["<my_lib_dir>"]} ..]}` and from 
target system (`code:root_dir/0`) has the same 'priorities' there is no way 
reltool can be sure which app to include <my_app> from "lib_dirs" or 
<system_app> from the target system. The current error definitelly makes 
sense here.
 

> A simple workaround for the above config file would be to skip the system 
> level lib_dirs parameter, and specify directory per application instead:
>
> {sys,[{incl_cond,derived},
>       {app,<my_app>,[{incl_cond,include},{lib_dir,"<my_lib_dir>/<my_app>"]}
>      ]}.
>
> This will of course only work as long as there are no other dependecies 
> from <my_app> towards other applications in <my_lib_dir>...
>

Hm. First of all this option seems to available only from R15B01 (the 
latest release as of today) and we are yet to switch to this version. But 
anyway, I did some experiments with this approach and probably I 
misunderstood you suggestion but I failed to make reltool to build the 
release via this workaround... You can see my understanding of your 
suggestion here: 
https://github.com/EduardSergeev/potentially_included/blob/proposed_solution/rel/reltool.config
But when I try to build this configuration it throws the error:
*{'EXIT',{{badmatch,{error,"library: Application version clash. Multiple 
directories contains version \"0.2.0\"."}},*
 
Not sure why.

So I am still see only two ways to solve this problem described in my first 
post:
1. The bad one: 
https://github.com/EduardSergeev/potentially_included/blob/first_solution/rel/reltool.config
 
2. And the verbose one: 
https://github.com/EduardSergeev/potentially_included/blob/second_solution/rel/reltool.config

So unless I got your workaround wrong (please correct my 'reltool.config' 
if this is the case!) I think that the only option for me is still 2. - to 
explicitly specify all dependent apps.

I guess the feature which I would ideally like to see in reltool is an 
ability to somehow *prioritise* the <my_lib_dirs> over target system: i.e. 
when searching to an app which includes a specific <module>, first look in 
<my_lib_dirs> and only then if not found in there look in 'target system' 
(`code:root_dir/0`) dir. Exactly as now, if a given <module> is included in 
more then one app from <my_lib_dirs> - throw the error but if there is only 
one app in <my_lib_dirs> which has this <module> just use this app even if 
another <system_app> from 'target system' includes this <module> too (well, 
unless this <system_app> is included for any reason).
Apart from being  obviously more complicated than the current process 
wouldn't this approach work?

Or still maybe there is a simpler way to solve the original problem?

Thanks!
Eduard

PS By the way, it looks that the lines 907-909 of the current revision of 
'reltool_server' will cause `bad argument` should they ever be called: 
https://github.com/erlang/otp/blob/maint/lib/reltool/src/reltool_server.erl#L907-909
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120717/8ddd0d3b/attachment.htm>