4

在我的 Erlang 项目中使用依赖项时，我多次遇到过这个问题，例如

{rabbit_common, "3.7.8"}

对比

{rabbit_common, ".*", {git, "https://github.com/rabbitmq/rabbitmq-common.git", {tag, "v3.7.8"}}

使用 git 时，我必须进入 lib 文件夹中的每个依赖项应用程序并在其上运行 make，而使用 hex 一切正常。

此外，当对我的应用程序进行 docker 化时，我发现出现错误

未找到版本

使用任何 git deps 时，但是当我全部切换到十六进制时，它工作正常。git为rebar3死了吗？

4

2 回答 2

4

默认情况下，rabbit_common在其 github 存储库中仅支持erlang.mk作为构建工具，并且不包含 rebar3 需要（在 rebar.config 中）成功构建它的数据。

Rebar3 能够进入并尝试编译一个看起来像遵守 OTP 的应用程序，但在这种情况下，特别是因为缺少 deps，rebar3 将无法知道某些组件没有到位。

然而，就像 Mix 和 Rebar3 一样，erlang.mk 可以发布到十六进制。这样做时，一些额外的元数据被添加到库中，包括依赖项。其他信息仍未添加（例如编译器选项）。总的来说，由于库是十六进制的，并且显然格式正确，rebar3 能够很好地构建它及其依赖项，但只能在十六进制上构建一次。

在可预见的未来，Rebar3 对 git 的支持预计将继续下去。当前的候选版本还添加了对许多混合依赖项的支持（以及作为插件的https://github.com/tsloughter/rebar_mix），但我们目前没有开放计划以原生支持 erlang.mk 项目。此时，十六进制和一些运气是您最好的选择。

于 2018-10-15T14:32:06.697 回答
2

git为rebar3死了吗？

不，它仍然有效，我希望继续支持它。

于 2018-10-12T15:44:50.183 回答