rebar3使用介绍（二）配置项

本篇主要介绍rebar3的配置部分

全局配置

rebar3支持全局配置，这也配置生效于环境中的所有rebar3，配置在操作系统的环境变量中，有以下内容：

Alias 别名

别名允许你根据现有命令，创造一个新的命令出来，当然他们必须有固定的执行顺序才行，比如

{alias, [{check, [eunit, {ct, "--sys_config=config/app.config"}]}]}. 

配置中的元素可以是check这种单个atom代表一个动作，也可以是 {ct, “–sys_config=config/app.config”} 这种代表一个带参的动作，执行顺序永远是从左到右串行执行。

Artifacts

相对路径于取决于它是否在伞状项目的顶层定义。例如，假设我们有一个项目my_project包含应用程序my_app在apps/my_app/下，my_app会创建一个escript。在rebar3不要在意配置在my_project/rebar.config中，因为它是整个项目的顶级rebar.config。该artifact会相对profile_dir，默认情况下是_build/default/：

{artifacts, ["bin/rebar3"]}. 

相反的如果项目不是伞状项目，即使my_app是在顶层，rebar.config在根目录下，Artifacts项的相对目录也是_build/default/lib/my_app/

rebar3提供了几个宏来扩展相对目录如下：

再举一个实例，eleveldb

{overrides, [{override, eleveldb, [{artifacts, ["priv/eleveldb.so"]}, ... ] }]}. 

因为这个是eleveldb自己的rebar.config，所以"priv/eleveldb.so" 就相当于"{
{out_dir}}priv/eleveldb.so"

Compilation

编译选项定义在erl_opts字段下，具体可使用的字段和值参照erlang的编译选项

{erl_opts, [ debug_info, {parse_transform, lager_transform}, warn_export_all, warn_unused_import, {i, "include"}, {src_dirs, ["src"]}]}. 

除此之外，还可以设置特定于平台的选项。

 {erl_opts, [{platform_define, "(linux|solaris|freebsd|darwin)", 'HAVE_SENDFILE'}, {platform_define, "(linux|freebsd)", 'BACKLOG', 128}, {platform_define, "R13", 'old_inets'}] }. 

这里支持匹配例如

{platform_define, "^((?!R1[456]).)*$", 'maps_support'} 

一个单独的编译选项是声明模块在所有其他模块之前编译的选项：

{erl_first_files, ["src/lager_util.erl"]}. 

还有一些额外的单独编译选项

{validate_app_modules, true}. % Make sure modules in .app match those found in code {app_vars_file, undefined | Path}. % file containing elements to put in all generated app files %% Paths the compiler outputs when reporting warnings or errors %% relative (default), build (all paths are in _build, default prior %% to 3.2.0, and absolute are valid options {compiler_source_format, relative}. 

其他与Erlang相关的编译器支持自己的配置选项：

• Leex编译器与{xrl_opts, […]}
• SNMP MIB编译器与{mib_opts, […]}
• Yecc编译器与{yrl_opts, […]}

测试选项

{ct_first_files, [...]}. % {erl_first_files, ...} but for CT {ct_opts, [...]}. % same as options for ct:run_test(...) {ct_readable, true | false}. % disable rebar3 modifying CT output in the shell 

ct_opts支持的字段可以在这里找到

Cover

具体看这

Dialyzer

{dialyzer, [Opts]} 

支持选项看这

Distribution

多个功能和插件可能需要支持分布式Erlang。通常，所有此类命令（例如ct和shell）的配置都遵循以下配置值：

{dist_node, [ {setcookie, 'atom-cookie'}, {name | sname, 'nodename'}, ]}. 

Directories 目录

可支持选项和默认值如下:

%% directory for artifacts produced by rebar3 {base_dir, "_build"}. %% directory in ' 
   
     / 
    
      /' where deps go {deps_dir, "lib"}. %% where rebar3 operates from; defaults to the current working directory {root_dir, "."}. %% where checkout dependencies are to be located {checkouts_dir, "_checkouts"}. %% directory in ' 
     
       / 
      
        /' where plugins go {plugins_dir, "plugins"}. %% directories where OTP applications for the project can be located {project_app_dirs, ["apps/*", "lib/*", "."]}. %% Directories where source files for an OTP application can be found {src_dirs, ["src"]}. %% Paths to miscellaneous Erlang files to compile for an app %% without including them in its modules list {extra_src_dirs, []}. %% Paths the compiler outputs when reporting warnings or errors %% relative (default), build (all paths are in _build, default prior %% to 3.2.0, and absolute are valid options {compiler_source_format, relative}. 
       
      
     
   

EDoc

配置项看这里

Escript

参看

EUnit

{eunit_first_files, [...]}. % {erl_first_files, ...} but for CT {eunit_opts, [...]}. % same as options for eunit:test(Tests, ...) {eunit_tests, [...]}. % same as Tests argument in eunit:test(Tests, ...) 

opts选项参看这里

最小OTP版本检查

{minimum_otp_vsn, "17.4"}. 

Overrides

覆盖是出于自己的项目需要对依赖项目作出改动，但是这个改动又不想套用到库上，所以选作上层覆盖，Overrides支持add, override, del操作

{overrides, [{add, app_name(), [{atom(), any()}]}, {del, app_name(), [{atom(), any()}]}, {override, app_name(), [{atom(), any()}]}, {add, [{atom(), any()}]}, {del, [{atom(), any()}]}, {override, [{atom(), any()}]}]}. 

app_name有的时候只会对指定app进行操作，如果没有指定，则会对所有app进行指定

这个特性允许你在不修改库的前提下，强制同意一些编译配置之类，或者针对自己的项目或者平台进行扩展

Hook 钩子

有两种类型的钩子：shell钩子和功能钩子

shell钩子

{pre_hooks, [{clean, "./prepare_package_files.sh"}, {"linux", compile, "c_src/build_linux.sh"}, {compile, "escript generate_headers"}, {compile, "escript check_headers"}]}. {post_hooks, [{clean, "touch file1.out"}, {"freebsd", compile, "c_src/freebsd_tweaks.sh"}, {eunit, "touch file2.out"}, {compile, "touch postcompile.out"}]}. 

功能钩子

{provider_hooks, [{pre, [{compile, clean}]} {post, [{compile, {erlydtl, compile}}]}]} 

自写功能中可以hook的点

只有部分功能支持附着钩子，

*默认情况下，这些钩子为每个应用程序运行，因为依赖项可以在它们自己的上下文中指定它们自己的钩子。区别在于，在某些情况下（伞形应用程序），钩子可以在许多级别上定义（省略覆盖）：

• 应用程序根目录下的rebar.config文件
• 每个顶级应用程序（在apps/或中libs/）rebar.config
• 每个依赖项的rebar.config

默认情况下，当没有伞形应用程序时，顶级rebar.config中定义的钩子将被归为顶级应用程序的一部分。这允许钩子在以后发布库时继续为依赖项工作。

但是，如果钩子是在具有伞形应用程序的项目的根目录下的rebar.config中定义的，则钩子将在任务运行之前/之后为所有顶级应用程序运行。

要保留伞状项目中的每个应用程序行为，必须在每个应用程序的rebar.config中定义钩子。

RELX

看这里

SHELL

rebar3 shell如果relx找到条目，REPL将自动启动应用程序，但可以使用显式指定由shell启动的应用程序{shell, [{apps, [App]}]}。

以下为扩展配置：

XRef

{xref_warnings,false}. {xref_extra_paths,[]}. {xref_checks,[undefined_function_calls,undefined_functions,locals_not_used, exports_not_used,deprecated_function_calls, deprecated_functions]}. {xref_queries,[{"(xc - uc) || (xu - x - b - (\"mod\":\".*foo\"/\"4\"))", []}]}. {xref_ignores, [{M, F}, {M, F, A}]}.