add p1_utils dependency to fast_tls.app.src

[DenysGonchar]

please add p1_utils dependency to fast_tls.app.src

[badlop]

Hi! Thanks for reporting.

I've checked all P1 libraries, and there are several that lack similar referenes in their app file:

• fast_tls lacks p1_utils
• eimp lacks p1_utils
• esip lacks stun fast_tls p1_utils
• mqtree lacks p1_utils
• p1_acme lacks idna, jose, jiffy, but instead defines fast_yaml which doesn't use
• xmpp lacks p1_utils, fast_xml, fast_tls, ezlib, idna, stringprep

I'll fix all these later this week.

[badlop]

please add p1_utils dependency to fast_tls.app.src

Umm, why exactly must p1_utils be added to applications in fast_tls.app.src?

https://erlang.org/doc/man/app.html

applications

All applications that must be started before this application is allowed to be started. systools uses this list to generate correct start scripts. Defaults to the empty list, but notice that all applications have dependencies to (at least) Kernel and STDLIB.

From what I see, fast_tls only uses p1_nif_utils from p1_utils, and that doesn't require p1_utils to be started.

[prefiks]

Afaik, some tools for bundling/preparing releases are using that to determine what should be included.

[DenysGonchar]

@prefiks yes, that's required for relx (used by rebar3).

it might be enough to add p1_utils to the included_applications list, but I haven't tested it:

included_applications

  All applications included by this application. When this application is started, all
included applications are loaded automatically, but not started, by the application
controller. It is assumed that the top-most supervisor of the included application is
started by a supervisor of this application.

UPDATE: did a quick test, yes - relx analyses included_applications list as well

[weiss]

relx analyses included_applications list as well

In the ejabberd universe, we're somewhat used to starting dependencies manually via calls such as application:ensure_all_started/1. As long as we do it this way, adding dependencies to the included_applications list is mostly equivalent to using the applications list indeed.

The OTP idea is to add dependencies to the applications list though, in which case the application controller will auto-start them. (The included_applications list is only meant for special cases, such as a single software repository holding multiple applications which start each other manually for some reason.) So, unless there's a good reason not to, I'd use the applications list, in order to stick closer to OTP practices.

[badlop]

Thanks for your explanations!