基本用法
新建应用或发布
使用 rebar3 项目组织代码主要有两种方式：单一应用项目或伞形项目。
单一应用项目在目录的根目录下包含一个独立的顶级应用，其 Erlang 源模块直接位于 src/ 目录中。此格式适用于发布到 GitHub 或 hex 上的库，目的是使它们能够与世界共享，但也可以与发布一起使用，发布允许交付一个直接启动应用的 Erlang 运行时系统。
伞形项目的定义特征是它们可以包含多个顶级 Erlang/OTP 应用，通常位于顶级 apps/ 或 lib/ 目录中。这些应用中的每一个都可以包含它自己的 rebar.config 文件。此格式仅适用于具有一个或多个顶级应用的发布。
Rebar3 带有用于创建这两种项目类型的模板，可以通过 rebar3 new <template> <project-name> 命令调用。<template> 值可以是以下任何一个
app：具有监督树的有状态 OTP 应用，作为单一应用项目lib：库 OTP 应用（无监督树），用于将各种模块组合在一起，作为单一应用项目release：一个准备发布的伞形项目umbrella：release的别名escript：一种特殊的单一应用项目形式，可以构建为可运行的脚本plugin：rebar3 插件的结构cmake：生成c_src目录和Makefile用于构建 C/C++ 代码
例如
$ rebar3 new app myapp
===> Writing myapp/src/myapp_app.erl
===> Writing myapp/src/myapp_sup.erl
===> Writing myapp/src/myapp.app.src
===> Writing myapp/rebar.config
===> Writing myapp/.gitignore
===> Writing myapp/LICENSE
===> Writing myapp/README.md
有关 new 和可用选项的更多信息，请查看命令文档，并了解如何创建和使用自定义模板，请访问模板教程。
添加依赖项
依赖项在 rebar.config 文件的 deps 键下列出
{deps, [
{elli, "~> 3.3.0"}, % package
{elli, {git, "git://github.com/elli-lib/elli.git", {tag, "3.3.0"}}} % alternatively, source
]
}.
现在，您可以将依赖项添加到项目的其中一个应用程序的 .app.src 文件的 applications 部分，以便 Erlang 知道您的应用需要此依赖项才能工作。
{application, <APPNAME>,
[{description, ""},
{vsn, <APPVSN>},
{registered, []},
{modules, []},
{applications, [kernel,
stdlib,
elli]},
{mod, {<APPNAME>_app, []}},
{env, []}
]}.
<APPVSN> 值可以是以下任何一个
| 版本类型 | 结果 |
|---|---|
string() |
使用字符串原样作为版本。例如："0.1.0" |
git | semver |
使用仓库上的最新 Git 标签构建版本。 |
{cmd, string()} |
使用在 shell 中执行 string() 内容的结果。例如，使用文件 VERSION：{cmd, "cat VERSION | tr -d '[:space:]'"} |
{git, short | long} |
使用当前提交的简短（8 个字符）或完整 Git ref。 |
{file, File} |
使用文件的内容。例如，使用 VERSION 文件比使用 cmd 更好的方法是：{file, "VERSION"} |
有关依赖项处理的更多信息，请查看依赖项文档
构建
只需要一个命令 compile 即可获取依赖项并编译所有应用。
$ rebar3 compile
===> Verifying dependencies...
===> Fetching elli v3.3.0
===> Analyzing applications...
===> Compiling elli
===> Analyzing applications...
===> Compiling custom_hex_repos
输出格式
安装依赖项、构建发布以及写入磁盘的任何其他输出都位于项目根目录下的 _build 目录中。
_build/
└── default
└── lib
└── elli
有关配置文件和 _build 目录的更多信息，请参阅配置文件文档页面。
测试
默认情况下，测试预计位于 test/ 目录下，除了位于各个模块内的 eunit 之外。
仅在运行测试时需要的依赖项可以放在 test 配置文件中
{profiles, [
{test, [
{deps, [
{meck, "0.9.0"}
]}
]}
]}.
现在，第一次运行 rebar3 ct 时，meck 将安装到 _build/test/lib/。但它不会添加到 rebar.lock 中。
_build/
└── test
└── lib
└── meck
发布和目标系统
发布使用relx构建。
创建一个具有发布结构的新项目并在 rebar.config 文件中使用默认的 relx 配置，运行
$ rebar3 new release myrel
===> Writing myrel/apps/myrel/src/myrel_app.erl
===> Writing myrel/apps/myrel/src/myrel_sup.erl
===> Writing myrel/apps/myrel/src/myrel.app.src
===> Writing myrel/rebar.config
===> Writing myrel/config/sys.config
===> Writing myrel/config/vm.args
===> Writing myrel/.gitignore
===> Writing myrel/LICENSE
===> Writing myrel/README.md
在 rebar.config 中，我们发现了一些在应用示例中不存在的元素。
{relx, [{release, {myrel, "0.0.1"},
[myrel]},
{dev_mode, true},
{include_erts, false},
{extended_start_script, true}
]
}.
{profiles, [
{prod, [{relx, [{dev_mode, false},
{include_erts, true}]}
]}
]}.
此配置为使用 Relx 构建开发（默认配置文件）和生产（prod 配置文件）的发布提供了一些不错的默认值。在构建用于生产的发布时，我们很可能希望创建一个目标系统（包括 erts），并且绝对不希望发布包含指向应用的符号链接（dev_mode false）。
$ rebar3 release
===> Verifying default dependencies...
===> Compiling myrel
===> Starting relx build process ...
===> Resolving OTP Applications from directories:
_build/default/lib
/usr/lib/erlang/lib
===> Resolved myrel-0.1.0
===> Dev mode enabled, release will be symlinked
===> release successfully created!
使用默认的 rebar.config，将发布作为目标系统创建压缩存档就像将配置文件设置为 prod 并运行 tar 一样简单
$ rebar3 as prod tar
===> Verifying dependencies...
===> Analyzing applications...
===> Compiling relx_overlays
===> Assembling release myrel-0.1.0...
===> Release successfully assembled: _build/prod/rel/myrel
===> Building release tarball myrel-0.1.0.tar.gz...
===> Tarball successfully created: _build/prod/rel/myrel/myrel-0.1.0.tar.gz
更多详细信息，请访问发布部分。