Rebar tool usage Memorandum

Reprinted: http://cryolite.iteye.com/blog/1159448

I mean you: http://www.haogongju.net/and www.ask3.cn/

Rebar is an open-source automatic building tool for Erlang applications. Basho tuncer development. It is actually an Erlang script (escript) tool, so it is easier to migrate between different platforms.

1. Install

You can download source code compilation from GitHub.

Bash code

1. Git clone git: // github.com/basho/rebar.git

Construct the bash code of the rebar Tool

1. CD rebar
2. Make

Put the compiled rebar in the system directory to complete the installation: Bash code

1. Sudo CP Rebar/usr/local/bin

Check the rebar version and check the bash code.

1. $ Rebar-V

Rebar version: 2 Date: 20151127_060830 VCs: git 8376693

However, the source code is an unstable version, which may cause minor problems during use.
There are also ready-made stable rebar downloads: Bash code

1. Http://cloud.github.com/downloads/basho/rebar/rebar curl-O rebar

2. Use

2.0 rebar help document

The most basic document is readme.
There is a video about the use of rebar by the rebar author, and fxxk wall browsing.

The official rebar documentation is not comprehensive, and the rebar has evolved fast, so it is best to start with the help of the rebar itself: view the rebar help through rebar-H.

The rebar version Library provides scripts for Automatic completion (under the priv/Shell-completion/bash/directory), and then adds a line in. bashrc (or. bash_profile): Bash code

1. Source $ rebar_home/priv/Shell-completion/bash/Rebar

In the future, enter the rebar command in the command line window and press the tab twice to automatically list the available rebar sub-commands. You can also view the detailed explanation of each sub-command through rebar-C.

The priv/templates directory in the rebar installation directory contains the source code of all default templates. Viewing the source code of these templates sometimes helps us understand what rebar does.

You can also subscribe to the rebar email list for online help.

2.1 rebar project configuration file

Each Erlang project has a rebar. config to control the use of the rebar. Of course, rebar. config is not a must. If there is no rebar, everything will be implemented by default.

There is a rebar. config. sample file under the rebar installation path. Studying this file can find many tips for using rebar. For example, the rebar. config code

1. {Pre_hooks, [{clean, "./prepare_package_files.sh "},
2. {Compile, "escript generate_headers"}]}.

This is obviously a front hook used to control the rebar sub-command, that is, the prepare_package_files.sh script is executed before the rebar clean sub-command is executed, and the escript generate_headers script is executed before the compile sub-command is executed.

Of course, there are post_hooks posthooks.

TIPS: adding the-V parameter when using the Rebar can print out the relevant commands and parameters during the rebar building process in detail, which helps us to check whether the configuration of the rebar. config file is correct.

2.2 project directory structure managed by rebar

The Erlang project managed by rebar should follow the Erlang OTP conventions. The file structure of the project is as follows. The subdirectories SRC and include are respectively placed with the Erlang source code and HRL inclusion files, the priv and Ebin directories place the compiled lib library shared files (or executable files) and beam files (and other files such as APP files), which are automatically generated and cleared by the rebar, do not put important code in these two directories, although it will not be rebar
Clean is automatically deleted (but all compiled beam files are deleted), but it does not affect the performance.

In addition, for Port Drive and nif development, their C source programs should be placed under the c_src directory. Currently, port driver and NIF are treated differently by rebar, so they have the same rebar control parameters.

Summary: The Source Code should be organized into three directory structures: SRC, include, and c_src. In addition, the eunit unit test code is stored in the test directory. The rebar controls the priv and Ebin directories. The source code or document should not be in these two directories.

2.3 use of rebar templates

Rebar list-templates sub-command can view the default Project template provided by rebar (of course, you can also create your own template)

A template is for code with a fixed mode or structure. For example, three famous OTP models have their own program skeleton. Each time you write a module of SRV or FSM, we have to repeat a lot of fixed skeleton code. The rebar template helps us save the repetitive work. We just need to fill in the logic code of the application.

Obviously, simplesrv, simplefsm, and simpleapp templates are used to create the OTP server mode, finite state machine mode, and app application mode.

Note that in the rebar, the three modes are named SRV, FSM, and app.
Correspondingly, these templates all have a set of control variables, namely srvid, fsmid, and appid.

Let's do some experiments.
Try to create an application: Bash code

1. $ Rebar create template = simpleapp

You can also create a FSM module: Bash code

1. $ Rebar create template = simplefsm

Another Server Module: Bash code

1. $ Rebar create template = simplesrv

Then you can view the automatically generated code in SRC to understand what the so-called automatic rebar template is.

Each type of template has its own generation control variables. Without these variables, everything is default. For example, no control variables are specified in the above experiment, so the generated modules are all default names such as myxxx.

The priv/templates directory in the rebar source code directory contains all the source code of the default template. The source code of these templates can help us understand how the variables of these rebar template creation commands work:
A) simplefsm. template simplefsm. template code

1. {Variables, [{fsmid, "myfsm"}]}.
2. {Template, "simplefsm. erl", "src/{fsmid}. erl "}.

This indicates that the FSM template provides a fsmid variable to control the generation of the FSM module. You can customize a bash code.

1. Rebar create template = simplefsm fsmid = cat

A cat module of FSM is created under SRC.

B) simplemod. tempalte template simplemod. tempalte code

1. {Variables, [{modid, "mymod"}]}.
2. {Template, "simplemod. erl", "src/{modid}. erl "}.
3. {Template, "simplemod_tests.erl", "test/{modid }}_ tests. erl "}.

You can use this template to create a common Erlang module, and it will automatically generate the unit test code for this module:
The control variable provided by this template is modid

Create an Erlang module named fish: Bash code

1. Rebar create template = simplemod modid = fish

C) basicnif. template basicnif. template code

1. {Variables, [{module, "mymodule"}]}.
2. {Template, "basicnif. erl", "src/{module}. erl "}.
3. {Template, "basicnif. c", "c_src/{module}. c "}.

This template is used to generate the NIF module. It provides a control variable called module.
Try to generate a nif module named Dragon and see the bash code.

1. Rebar create template = basicnif module = Dragon

The nif c code and ERL code are placed under the c_src and SRC directories respectively.

D) simpleapp. template simpleapp. template code

1. {Variables, [{appid, "MyApp"}]}.
2. {Template, "simpleapp. App. SRC", "src/{appid}. App. SRC "}.
3. {Template, "simpleapp_app.erl", "src/{appid} _ app. erl "}.
4. {Template, "simpleapp_sup.erl", "src/{appid }}_ sup. erl "}.

This indicates that the simpleapp template provides a variable named appid,
The following is a custom application called anmial: Bash code

1. Rebar create template = simpleapp appid = anmial

Then we found that three ERL source codes related to dog application are added to SRC.

In fact, rebar provides a subcommand to directly create an application: Create-app: Bash code

1. Rebar create-app appid = anmial

The effect is the same. However, the command is shorter and the help is detailed (at least tell us that the template variable name is appid)

The following is the file created in the above example: Bash code

1. Find.

.
./C_src
./C_src/Dragon. c
./Src
./Src/anmial_app.erl
./Src/cat. erl
./Src/anmial_sup.erl
./Src/anmial. App. SRC
./Src/fish. erl
./Src/myfsm. erl
./Src/Dragon. erl
./Test
./Test/fish_tests.erl

Use rebar to automatically compile the bash code.

1. Rebar compile

We can find that the source code is compiled to the Ebin and priv directories respectively. Erlang is cross-platform, which is nothing to say. What's amazing is that the dynamic shared library (So files) of NIF (including port driver) is also automatically compiled, and it also supports automatic cross-platform support for Linux and Mac. All these compilations are done by the rebar compile command.

We can add a-V parameter to view in detail what rebar has done during compilation: Bash code

1. Rebar compile-V

The console will detail the commands and parameters used in the compilation process, as well as related environment variables.

As mentioned above, we can specify these command parameters through rebar. config. For example, to generate a link parameter for the NIF dynamic shared library, if the dynamic shared library also needs to be linked to a third-party library, you must specify the relevant link parameters for the linker.

If applicaton is not created in the preceding example, compile cannot compile FSM, server, or nif modules by default. The entire project must have an appbash code

1. Rebar create-app appid = animal

This is also true for NIF modules.

You can set the environment variables cflags and ldflags for port_envs in rebar. config to specify the compilation or link parameters:

Which variables can be customized in port_envs, and there seems to be no online documentation, so let's look at the source code program of rebar: rebar_port_compiler.erl. The comments at the beginning indicate which parameters can be customized, which are compiled and linked.

For example, a nif Module C code I recently wrote uses some features of c99 and a third-party shared library gdal. The command for compiling and linking NIF dynamic library in Linux is as follows: Bash code

1. Gcc-STD = c99-FPIC-shared-O gdal_nifs.so gdal_nifs.c-I $ erl_home/usr/include-lgdal

The command used to compile the link on Mac is as follows: Bash code

1. Gcc-STD = c99-FPIC-bundle-undefined suppress-flat_namespace-O gdal_nifs.so gdal_nifs.c-I $ erl_home/usr/include-lgdal

The rebar has considered different parameters for cross-platform compilation links. I also need to customize the following two parameters:
1) specify c99 standard compilation;-STD = c99
2) link to the specified gdal dynamic library:-lgdal

Therefore, the rebar. config custom file is the rebar. config code.

1. {Port_envs ,[
2. {"Cflags", "$ cflags-STD = c99 "},
3. {"Ldflags", "$ ldflags-lgdal "}
4. ]}.

Later, you can use rebar compile to compile data across various platforms.

Clear compiled files: Bash code

1. Rebar clean

The target files (beam and so) automatically compiled by rebar will be deleted.

Note: This command does not clear all target files. It only clears files generated by rebar.

The rebar template is simple. You can also create a template by yourself. Your code template can be placed in the project'sPriv/templatesDirectory. Rebar list-templates will automatically list all templates in this directory. Let's take a look at the template format. Simply put, the template variable string is replaced, which is nothing advanced.

If you think your template is good, you can submit it to become an official template.

3. Others
Rebar has the parallel processing capability of Erlang. By default, each sub-command has three job workers for parallel processing, and the number of workers for parallel processing can be controlled through the-J parameter.

However, due to this parallel processing capability, sometimes it is found that there will be a strange phenomenon. For example, I want to clean up and compile the Barh code at the same time.

1. Rebar clean; rebar compile

The new rewrite Code does not work. It is changed to bash code.

1. Rebar clean
2. Rebar compile

No problem.

Because rebar documents are incomplete and code modifications are made almost every day, they are constantly evolving rapidly. Early documents seem outdated, for example, many documents on the Internet mentioned the dialyzer Static Analysis of rebar. In fact, the latest rebar no longer has this subcommand.

In general, you can flip through rebar. config. sample. This configuration template provides almost all the configuration variables of rebar. config and their descriptions. For example, I need to write several NIF modules in my requirements. Each NIF module has its own so. Find these lines of code in rebar. config. sample: Rebar. config. sample code.

1. % So_specs-useful for building multiple *. So files
2. % From one or more object files
3. {So_specs, [{"priv/so_name.so", ["c_src/object_file_name.o"]}.

It's easy, right.