This has no real impact on performance[1] but should
make it clear which application can run the broker
and/or publish to Hex.pm. In particular, applications
that we can't run the broker from will now give up
early if we try to.
Note that while the broker can't normally run from the
amqp_client application's directory, it can run from
tests and some of the tests start the broker.
[1] on my machine
... for `rabbit_common` and `amqp_client`.
This should only be used for testing purpose (e.g. dry-run in CI),
otherwise dependency tracking will break: `amqp_client` depends on a
specific version of `rabbit_common`.
However in CI, we want to be able to do a publish dry-run of
`amqp_client`. As it requires `rabbit_common` to be published, we need
to override the version pinning to point it to an already published
version of `rabbit_common` (the corresponding version of `rabbit_common`
was not published either). This is ok because nothing is published in
the end.
[#150482173, #150482202]
When we publish our packages to Hex.pm, we use the simplified
rabbitmq-components.hexpm.mk to replace the regular
rabbitmq-components.mk.
Before commit ba59f969b7,
rabbitmq-components.mk took 3rd-party dependencies from GitHub. Now that
it takes them from Hex.pm, we don't need to override and hard-code them
again in rabbitmq-components.hexpm.mk.
Thus now, we extract them from rabbitmq-components.mk and put them at
the end of rabbitmq-components.hexpm.mk when we publish to Hex.pm.
The other benefit is that we don't have to remember to change version
pinning in both rabbitmq-components.mk and rabbitmq-components.hexpm.mk.
[#150482173]
Loïc Hoguin
Luke Bakken
Philip Kuryloski
Jean-Sébastien Pédron
Gerhard Lazu