Re: reltool dependencies ignored

Siri Hansen <[email protected]>
Newsgroups gmane.comp.lang.erlang.bugs
Message-ID <CAGqERUErFaynemZ6j-g5G6y1wuAwr+H_+me5+RMnokYjRFCE1w@mail.gmail.com>
Hi Michael, I do agree that this is a bug. I've written a ticket which will
be prioritized along with the other tasks in our backlog.
Thanks for reporting!
Best Regards
/siri


2014-05-08 18:18 GMT+02:00 Michael Truog <[email protected]>:

>  Hi Siri,
>
> Thanks for determining this.  I am not sure how the dependencies are used,
> it is possible syntax_tools wasn't being used where it is mentioned.
> However, it really seems like this should be a bug simply due to the Erlang
> application startup.  I know the release (script/boot files) generated by
> this particular reltool file doesn't start these applications (with the
> problematic dependencies), but anything else that starts the applications
> would do so by the dependencies mentioned.  So, I don't see how this can't
> be a bug.  If xref determined that the dependencies were not called, it
> could remove the application dependencies from the .app file dependencies
> list, but having dependencies culled should be an option that you can turn
> off like it can be with modules selected with reltool.  I think culling the
> dependencies is a bit dangerous (especially by default) because it should
> be possible to have dependencies xref is unable to see (though I don't have
> a good example of this).
>
> Thanks,
> Michael
>
>
> On 05/08/2014 08:20 AM, Siri Hansen wrote:
>
> 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 <[email protected]>:
>
>> ok, thanks! I will try this and continue digging :)
>> /siri
>>
>>
>> 2014-05-08 10:41 GMT+02:00 Michael Truog <[email protected]>:
>>
>>  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 <[email protected]>:
>>
>> 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-L89
>> shows 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
>>
>>
>>
>

_______________________________________________
erlang-bugs mailing list
[email protected]
http://erlang.org/mailman/listinfo/erlang-bugs
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.