当前位置: 首页 > 工具软件 > Rebar > 使用案例 >

Rebar3使用介绍(一)基础用法

景鸿晖
2023-12-01


本文基本都是按照 rebar3官方文档翻译加上自己的理解整理而成,可能有纰漏,疑惑部分请查看原文订正。

安装


  • 使用源码安装
$ git clone https://github.com/erlang/rebar3.git
$ cd rebar3
$ ./bootstrap
  • 直接下载编译好的二进制文件
$ wget https://s3.amazonaws.com/rebar3/rebar3 && chmod +x rebar3

如果要在windows下使用的话,需要额外制作一个rebar3.bat rebar3.cmd用来调用

@echo off
setlocal
set rebarscript=%~f0
escript.exe "%rebarscript:.cmd=%" %*

当然要求erlang环境,escript必须在path中,如果用过rebar,和以前的rebar.bat rebar.cmd作用是一样的,不过现在IDEA的erlang插件已经支持了,如果使用IDEA就不用通过脚本调用


加入到环境变量中

./rebar3 local install

后续更新,可以通过命令直接更新到最新稳定版本

rebar3 local upgrade

基础用法


  • 创建一个新的app或者release
  • 加入deps依赖
  • 编译
  • 输出配置
  • 测试
  • 发布

创建一个新的app或者release

rebar3推荐两种主流方式管理项目:单个app结构的管理或者伞状管理

单个app方式是根目录中只有一个app,源代码存放在src目录,这种格式主要用来做库,处于共享的目的,例如recon,虽然一般把这种目录方式认为成一个库项目,但是这种结构还是可以发布

伞状项目的特点是包含了多个独立的OTP app,通常位于apps/ 或者 lib/目录中,这些app都可以有自己的rebar.config这种格式一般用于项目开发,项目可以拥有一个或多个主app,不一定只能有一个

rebar3提供了命令用来新建任意类型的模板,可通过rebar3 new <template> <project-name>命令调用。该<template>值可以是下面的任意值:

  • app: 具有监督树和state维护的一个OTP application,作为一个单独的app
  • lib: 没有监督树的OTP application,一般用来将多个模块组合起来作为一个单独的项目
  • release: 准备发布的伞状项目,比app项目多了config目录下的sys.config,和vm.args,用来描述运行环境
  • escript: 一种基于app的项目,将来可以构建成escript脚本
  • plugin: 用于支持rebar3脚本

加入deps依赖

{deps, [
        {cowboy, "1.0.1"}, % package
        {cowboy, {git, "git://github.com/ninenines/cowboy.git", {tag, "1.0.1"}}} % alternatively, source
        ]
}.

上面两种方式都可以获取依赖,对于第二种,使用过rebar的同学应该很熟悉,变化并不大
对于第一种,是用hex管理的erlang库完成的归类,例如上面的cowboy,最后就是通过https://repo.hex.pm/tarballs/cowboy-1.0.1.tar 这种地址从已经归类的服务端进行下载后管理的,至于hex的用法,比较复杂。如果想了解可以点这里

总的来说,一般比较常用的库hex都会有归档,不需要提供git仓库地址,但是如果不配置就没法完成的话,就得按照第二种格式配置上vsn地址了。当然也可以通过更新hex的归档目录实现,不过吧,我只是猜可以,没实践过。。

rebar的老配置格式,例如{cowboy, ".*", {git, "git://github.com/ninenines/cowboy.git", {tag, "1.0.1"}}}这种在rebar3也是兼容的,但是第二个字段".*",会被忽略

添加完deps目录后,记得将新加的application加入到你的主app的.app.src文件中,这样就不用手动额外进行application调用了

编译

和rebar一样,在项目的根目录下执行rebar compile就可以完成编译,不过和rebar不同的是,使用rebar我们得先执行rebar get-deps先主动获取依赖才行,rebar3不需要直接执行compile即可,而且可以保证deps目录是最新的,即使deps库有了变更。

输出配置

默认的输入目录为_build目录,和rebar不同

  • _build
    • default
      • lib
        • cowboy
        • cowlib
        • ranch

测试

测试用例默认是存放在test/目录下,eunit允许按照模块组织打包目录存放
如果测试用例需要额外的依赖,可以做单独配置,只有在运行测试用例的时候才getdeps指定依赖

{profiles, [
   {test, [
       {deps, [
           {meck, {git, "git://github.com/eproxus/meck.git", {tag, "0.8.2"}}}
       ]}
   ]}
]}.

现在第一次调用rebar3 ct 会更新meck到_build/test/lib/.下,但是不会被加到rebar.lock文件中

发布

rebar3使用relx进行构建
可以使用rebar3 new release myrel 直接新建一个发布目标,该项目的rebar.config就会有一个推荐的relx配置如下

{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}]}
     ]}
]}.

你可以将上面的内容复制到你的rebar.config中,当然记得将myrel该成你自己的项目,就可以调用rebar3 release 进行发布

由于默认配置dev_mode为true,那么_build/rel/myrel/lib是符号连接_build/lib和apps/myrel。因此,在开发和重新编译应用程序时,您无需重新创建发行版,只需重新启动节点或重新加载模块即可。

使用命令rebar3 as prod tar 可以将发布的文件打包成tar包方便拷贝

 类似资料: