在公共测试期间找到lib目录答案

【问题标题】：finding lib directory during common test在公共测试期间找到lib目录
【发布时间】：2017-08-27 08:44:42
【问题描述】：

我的问题是，我的 Erlang 应用程序应该如何可靠地在 priv 目录中找到二进制文件，而不仅仅是在生产环境中；正确安装时，但在普通测试期间？

今天，当我将 travis-ci 配置添加到旧的 Erlang 应用程序并将其推送到 git-hub 时，我意识到它在本地工作的过程比我想象的要脆弱一些。 travis-ci 构建失败了，因为它并非不合理地将我的 repo 检出到以 repo 命名的目录中，该目录的格式为 erlang-APP。不过，我的应用在本地位于一个名为 APP-VSN 的目录中。

这样做的结果是调用code:lib_dir(APP) 在本地的常见测试运行期间返回正确的结果，但是如果我将当前目录重命名为 erlang-APP 而不是 APP-VSN（或者只是 APP 也可以）我的本地构建失败，就像 travis-ci 一样，因为 code:lib_dir(APP) 返回 {error,bad_name}。好像.. 被添加到rebar ct 的库路径中的行为。

将我的 github 存储库从 erlang-APP 重命名为 APP 可以解决 travis-ci 构建失败...但知道构建测试仅通过取决于存储库签出到的目录的名称不适合我。

【问题讨论】：

标签： erlang travis-ci common-test

【解决方案1】：

一种方法是使用软链接（在版本控制下的存储库中，或在初始化测试时创建），并使您的 Erlang 代码路径通过该链接。例如，“./APP” -> “.”，或“./lib/APP” -> “..”。

【讨论】：

对，这是一个很好的建议，我真的应该考虑一下，我的rebar.config 中通常有{lib_dirs, ["deps"]}.，因此链接deps/APP -> .. 可以使构建工作不管当前目录名称。做这件事似乎有点有趣，但我不觉得它令人反感，而且我想不出任何可能会变坏的原因。如果需要，总是可以为此目的向 lib_dirs 添加另一个目录而不是 deps。
对于依赖项（一个 git 子模块）的目录子结构下有一个或多个应用程序目录的情况，我使用了类似的解决方案，因此无法直接在 ERL_LIBS 目录中签出。在这种情况下，我已将子模块附加到侧面的单独目录，以及从 lib/APP 到 subs/PACKAGE/.../APP 的软链接。
是的，将 self 添加为依赖项有点奇怪，而且可以说是错误的...您可以通过 code 模块或 erl -pa 显式添加到代码路径，我猜ebin 是由 rebar 添加的，但实际上，这隐藏了这样一个事实，即在这种情况下添加的代码路径不是从库路径派生的，在某些情况下，这会成为一个缺陷。