[erlang-bugs] reltool dependencies ignored

[Siri Hansen]

Michael, it looks like reltool only follows the dependencies in the .app
file (applications tag) for applications that are included in a release in
the reltool config. For other applications that are mentioned in the config
reltool only follows dependencies found with xref. I can not see that any
of the applications that mention syntax_tools in their .app actually call
any of the modules in this application from the erlang code. How is
syntax_tools used?

I'm not sure why reltool behaves this way, so I have to investigate a bit
further to find out if it is a bug or not.

Regards
/siri

torsdagen den 8:e maj 2014 skrev Siri Hansen <erlangsiri@REDACTED>:

> ok, thanks! I will try this and continue digging :)
> /siri
>
>
> 2014-05-08 10:41 GMT+02:00 Michael Truog <mjtruog@REDACTED<javascript:_e(%7B%7D,'cvml','mjtruog@REDACTED');>
> >:
>
>  Hi Siri,
>
> I know the situation there is a bit unusual.  The external CloudI
> dependencies are moved so that the "cloudi_x_" prefix is added to all the
> external Erlang application names, their modules, and their header files.
> The external dependency directory names already have the "cloudi_x_" prefix
> to satisfy include_lib usage within the modules (so that means external
> CloudI dependencies that depend on each other, in a way that uses a header
> file with -include_lib).  This is all done with the script at
> https://github.com/okeuday/reltool_util/blob/master/scope with the
> command line at
> https://github.com/CloudI/CloudI/blob/develop/src/Makefile.am#L7-L66(i.e., atoms are selectively changed within the source code, along with the
> files being moved).  However, that process doesn't impact how the external
> CloudI dependencies work.  The prefix is added to simulate a namespace
> concept which doesn't exist in Erlang to avoid any potential conflicts when
> CloudI shares the Erlang VM with other Erlang applications.
>
> That is unusual, but the reltool usage is the same either way, its just an
> addition of a prefix for referencing the names, as they are now.  The
> compilation process makes sure the prefix is added, so the external
> dependency files do change to satisfy the compilation, testing and release
> requirements.  While it would be natural to assume this process is at fault
> for the reltool issue, I am sure that is not the case.  You should be able
> to see this if you do a "./configure && make" of the root src directory,
> since that will make sure the files are as expected.
>
> Thanks,
> Michael
>
>
> On 05/08/2014 01:05 AM, Siri Hansen wrote:
>
> Hi Michael!
>
>  I haven't spent a lot of time on this yet, but I was just trying to find
> the chain of dependencies that lead to syntax_tools, but I find it a bit
> hard I would appreciate some help...
>
>  I found one way but it didn't really make sense:
>
>  reltool.config includes application 'cloudi_service_db_cassandra', and
> in cloudi_service_db_cassandra.app.src.in you have
> {applications,[...,cloudi_x_erlang_cassandra,...]}
>
>  Under the directory external/cloudi_x_erlang_cassandra/src/ I then
> find erlang_cassandra.app.src, which indeed has
> {applications,[...,syntax_tools,...]} - but this is obviously an
> application named 'erlang_cassandra' and not 'cloudi_x_erlang_cassandra' as
> listed above... so how does this work?
>
>  Regards
> /siri
>
>
> 2014-05-01 19:42 GMT+02:00 Michael Truog <mjtruog@REDACTED>:
>
> Hi,
>
> I believe I found a bug that causes reltool to ignore dependencies when
> generating a release.  I am not sure where the problem is within reltool,
> but I at least have a way to demonstrate it.
> https://github.com/CloudI/CloudI/blob/develop/src/reltool.config.in#L78-L89shows lines that are unnecessary within the reltool.config file. The
> dependencies mentioned there should be found automatically by reltool.  If
> you remove those lines and do a make install (after the autogen.sh and
> configure steps) you will see the dependencies mentioned in these lines are
> not there.
>
> Thanks,
> Michael
> _______________________________________________
> erlang-bugs mailing list
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20140508/ab948651/attachment.htm>