I was wondering what was the reason behind the following behaviour of reltool:
If my reltool.config uses default mod_cond and incl_cond options and if one of my included applications has a module which also happens to be a part of some application installed on my machine but NOT included in my release reltool:get_target_spec/1 returns:
{error, "Module <some_module> potentially included by two different applications: <system_app> and <my_app>."}
Which is annoying since <system_app> is NOT a part of my release (neither directly nor indirectly). Can't reltool actually figure out that <system_app> will not be included in my release? Is that why it is "potentially included"?
Anyway, in order to generate my release I have to either explicitly exclude <system_app> via {app, <system_app> [{incl_cond, exclude}]} which is ugly since this <system_app> is just happens to be installed in the root_dir of the Erlang/OTP system of the machine where I do the build (it may not be installed on other build machines) and has nothing to do with my release. The actual example: tsung-1.4.3 includes mochijson2 module so I have a problem building my own release which should include mochiweb app on the machine that has tsung installed (but not on other machines).
Another option would be to change top-level incl_cond from {incl_cond, derived} to {incl_cond, exclude} and then manually include all application which I want to be a part my release which is better (will work on any build machine) but still not great since it has to be done manually (I want to rely on relltool to figure out the dependencies).
So the question is why do we have such a situation? Why just a mere presence of some application on the build machine lead to the above reltool error?
PS As a side-note I believe the line 907-909 of the current version of reltool_server.erl contains a bug: it will generate bad argument should it ever be called.