rebar3使用介绍（六）用户自定义文件配置

依赖和配置文件
依赖永远按照prod模式对应的profile进行编译，不会有其他（当然不包括default）任何东西会被额外的套用上来，即使它们是为prod依赖项配置的，仍然会将其提取到其声明的配置文件的配置文件目录中。例如，顶层的依赖关系deps将放在_build/default/lib下，test将放在_build/test/lib下，并且两者都将在prod应用其配置文件配置的情况下进行编译。

在任何项目中，根据任务运行或运行任务的人员的角色，总会有一组所需的选项。
例如，在Erlang项目中，最常见的示例是仅针对测试运行所需的依赖项，例如模拟库或特定测试工具或框架。

rebar3使用配置文件的概念来满足这些要求。配置文件是一组配置设置，仅在这些特定上下文之一中使用，覆盖或补充常规配置。他们的目标是能够支持多个开发用例，同时保持可重复性，而无需外部工具或环境值来完成这项工作。

可以通过三种不同方式指定运行的配置文件：

1. 修改REBAR_PROFILE环境变量
2. 使用 rebar3 as <profile> <command>或rebar3 as <profile1>,<profile2> <command>
3. 特殊的rebar3命令，例如ct和eunit总是会添加test项的配置内容

任何这些形式（甚至是所有这些形式）都会让rebar3知道它应该作为特殊配置文件之一运行并相应地修改其配置。

可以在主rebar.config文件中指定配置文件配置：

{profiles, [{ProfileName1, [Options, ...]},
            {ProfileName2, [Options, ...]}]}.

例如，meck仅为测试运行添加依赖关系的测试配置文件可以定义为：

{profiles, [{test, [{deps, [meck]}]}]}.

任何配置值都可以包含在配置文件中，包括插件，编译器选项，发行选项等。

例子

更完整的示例如下所示：

{deps, [...]}.
{relx, [
    ...
]}.

{profiles, [
    {prod, [
        {erl_opts, [no_debug_info, warnings_as_errors]},
        {relx, [{dev_mode, false}]}
    ]},
    {native, [
        {erl_opts, [{native, o3}]}
    ]},
    {test, [
        {deps, [meck]},
        {erl_opts, [debug_info]}
    ]}
]}.

因此，这样一个项目有四个不同的模式：

1. default, 所有执行模式下的基础配置，对应于整个rebar.config中的配置
2. prod， 生产环境，可能会去掉符号链接，或者加入更严格的编译检查之类
3. native, 强制使用HiPE进行编译，以获得更快的数学代码
4. test，它可以加载模拟库，并允许在测试运行期间将调试信息保存在文件中。

这些可能在很多场景下结合在一起。以下是示例运行：

1. rebar3 ct：将运行项目的常见测试套件。按顺序，应用的配置文件将是default，然后test，因为ct要求使用test配置文件。
2. rebar3 as test ct：将像以前一样运行。配置文件不会重复应用多次。
3. rebar3 as native ct：将以纯本地运行测试。配置文件的顺序是’default’，然后是’native’，最后是’test’（最后由命令运行指定）。
4. rebar3 as test,native ct：将与上述相同。在应用配置文件时，rebar3首先将它们全部展开，然后按正确的顺序应用它们。所以为了在这里会default，然后test，然后native，然后test再次（因为的ct命令）。由于配置文件可应用于idempotently，这仅相当于调用rebar3 as native ct。
5. rebar3 release 将仅作为default配置文件构建版本。
6. rebar3 as prod release 将使用更严格的编译器选项来构建没有开发模式的版本。
7. rebar3 as prod, native release 将使用最后一个命令构建发行版，但同时还将模块编译为本机模式。
8. rebar3 as prod release而REBAR_PROFILE=native在环境中将像上一个命令一样构建发布，但native将在prod之前应用。

因此，配置文件的应用顺序如下：

1. default
2. REBAR_PROFILE值，如果有的话
3. as命令行部分中指定的配置文件
4. 每个命令指定的配置文件

通常，配置文件因此应该是可组合的，用于配置要使用的配置子集。

依赖锁定

只有主的rebar.config文件中定义的依赖项会被锁定，而依赖项的依赖项则不会
如果有人想“锁定”编译（使用生产配置），答案是使用releases（参见[[Releases]]），它允许生成可以在任何时间重用的编译工件，如果用于部署可以以rebar3 tar进行打包部署。

选项合并算法

尝试自动合并所有配置选项通常很棘手。不同的工具或命令会以不同的方式期望它们，或者将lists of tuples, proplists, key/value pairs转换为某种字典。

为了支持尽可能最通用的形式，rebar3将它们作proplists 和 tuple lists的松散组合来处理。这意味着以下选项都被视为具有密钥native：

• native
• {native, o3}
• {native, still, supported}

即使其中一些工具可能支持也可能不支持。例如，Erlang编译器支持将宏定义为{d, 'MACRONAME'}或者{d, 'MACRONAME', MacroValue}，但单独的d不行，而它确实支持native和{native, o3}。

rebar3正确支持所有这些表单并以功能方式合并它们。我们以下面的配置文件为例：

{profiles, [
    {prod, [
        {erl_opts, [no_debug_info, warnings_as_errors]},
    ]},
    {native, [
        {erl_opts, [{native, o3}, {d, 'NATIVE'}]}
    ]},
    {test, [
        {erl_opts, [debug_info]}
    ]}
]}.

以不同的顺序调用这些配置将生成不同的erl_opts列表:

• rebar3 as prod,native,test <command>： [debug_info, {d, ‘NATIVE’}, {native, o3}, no_debug_info, warnings_as_errors]
• rebar3 as test,prod,native <command>： [{d, ‘NATIVE’}, {native, o3}, no_debug_info, warnings_as_errors, debug_info]
• rebar3 as native,test,prod <command>： [no_debug_info, warnings_as_errors, debug_info, {d, ‘NATIVE’}, {native, o3}]
• rebar3 as native,prod,test <command>： [debug_info, no_debug_info, warnings_as_errors, {d, ‘NATIVE’}, {native, o3}]

请注意，应用的最后一个配置文件会生成列表中的第一个元素，并且每个配置文件列表中的元素将根据其键进行排序。

这将允许rebar3命令以正确的顺序拾取元素，同时仍然支持需要许多元素共享相同键的多值列表（例如[{d, ‘ABC’}, {d, ‘DEF’}]，这是两个独立的宏！）。不支持重复元素的命令可以在第一个元素之后停止处理它们，而那些构建字典（或映射）的命令可以选择按原样插入它们，或者可以安全地反转列表（如果最后处理的元素变为maps中的最后一个）。

所有配置文件合并规则都以这种方式安全处理。插件编写者应该了解这些规则并做出相应的计划。