安装erlang

yum install zlib-devel
yum install openssl-devel
yum install perl
yum install cpio
yum install expat-devel
yum install gettext-devel

接下来,如果你已经安装过Curl了,那么跳过这一步,没有的话,就装一下.

wget http://curl.haxx.se/download/curl-7.18.0.tar.gz
tar xzvf curl-7.18.0.tar.gz
cd curl-7.18.0
./configure --prefix=/usr/local/curl
make
make install

确定一下ld.so.conf文件里有/usr/local/lib,这个是为git-http-push准备的.

vi /etc/ld.so.conf
#插入下面的代码
/usr/local/lib

保存文件,接着运行:

/sbin/ldconfig

最好,我们下载Git并安装它

wget http://www.codemonkey.org.uk/projects/git-snapshots/git/git-latest.tar.gz
tar xzvf git-latest.tar.gz
cd git-{date}
autoconf
./configure --with-curl=/usr/local
make
make install

这就是所有的安装步骤,不算是太麻烦吧.

 

由于最终部署的生产环境是Centos，所以我需要在Centos中安装Erlang B13R04 ，第一次做这件事情破费周折，主要是对Erlang依赖的库不熟悉，总是编译不过；这里梳理一下安装过程中的细节：

    Erlang依赖哪些库？

     A fully working GCC compiler environment
     Ncurses development libraries
     OpenSSL development libraries （如果使用mysql必须安装）
    安装了这些库之后，必须要重新执行configure命令，configure之后会有提示哪些依赖的库没有安装，可以根据你的需要放弃安装一些库；上面的操作可以使用下面的命令实现：

   

> sudo yum -y install make gcc gcc-c++ kernel-devel m4 ncurses-devel openssl-devel
> wget http://www.erlang.org/download/otp_src_R13B04.tar.gz
> tar xfvz otp_src_R13B04.tar.gz
> cd otp_src_R13B04/
> ./configure --with-ssl
> sudo make install
   注意，如果你遇到下面的错误：

 

{error,
{load_failed,
"Failed to load NIF library: '/usr/local/lib/erlang/lib/crypto-2.0/priv/lib/crypto.so: undefined symbol: enif_make_new_binary'"}}
    那么极有可能是两个原因：

      没有安装OpenSSL
      你安装了多版本的Erlang，R14A和R13B04冲突造成的，删除erlang相关的文件夹，重新安装即可

本篇文章来源于 Linux公社网站(www.linuxidc.com)  原文链接：http://www.linuxidc.com/Linux/2011-07/39156p2.htm

 

 

 

 

rebar工具使用备忘录
rebar是一个开源的erlang应用自动构建工具。basho的tuncer开发。它实际上是一个erlang脚本（escript）的工具，因此在不同平台间迁移起来比较方便。

1.安装

可以去github下载源代码编译
Bash代码 
git clone git://github.com/basho/rebar.git 

构建rebar工具
Bash代码 
cd rebar 
make 

把编译好的rebar放到系统目录中完成安装：
Bash代码 
sudo cp rebar /usr/local/bin 

查看rebar的版本检查一下安装：
Bash代码 
$ rebar -V 

rebar version: 2 date: 20110827_060830 vcs: git 8376693

不过通过源代码得到的是不稳定的版本，使用时会出现些小问题。
也有现成的稳定rebar下载:
Bash代码 
curl -o rebar http://cloud.github.com/downloads/basho/rebar/rebar 

2. 使用

2.0 rebar的帮助文档

最基本的文档是README。
有段rebar作者的rebar使用介绍视频, fxxk墙浏览。

rebar的官方文档不是很全，而且rebar的进化也很快，所以最好从rebar本身的帮助开始：通过rebar -h查看rebar帮助。

rebar版本库中有提供实现自动补全的脚本（在目录priv/shell-completion/bash/下），然后在.bashrc（或者.bash_profile)添加一行：
Bash代码  source $rebar_home/priv/shell-completion/bash/rebar 

以后在命令行窗口中输入rebar命令连按两次tab键会自动列出可用的rebar子命令。当然也可以通过rebar -c 查看每个子命令的详细解释。

在rebar安装目录的priv/templates目录下有所有缺省模板的源代码，查看这些模板的源码有时候能帮助我们理解rebar所做的工作。

当然也可以订阅rebar的邮件列表获得在线帮助

2.1 rebar的工程配置文件

每个erlang工程会有一个rebar.config控制rebar的使用，当然rebar.config不是必须的，没有的话一切都按rebar缺省的来。

rebar安装路径下有一个rebar.config.sample的文件，研究这个文件可以发现许多rebar的使用诀窍。例如这句
Rebar.config代码  {pre_hooks, [{clean, "./prepare_package_files.sh"}, 
     {compile, "escript generate_headers"}]}. 

这显然是用来控制rebar子命令的前置钩子，也就是说在rebar clean子命令执行之前执行prepare_package_files.sh脚本；在compile子命令执行之前执行
escript generate_headers脚本。

当然相应的还有post_hooks后置钩子

一个诀窍：在使用rebar时加上-v参数可以详细的打印出rebar构建过程时的相关命令和参数，这有助于我们查看rebar.config文件的配置是否正确。

2.2 rebar管理的工程目录结构

rebar管理的erlang工程应该遵循erlang OTP的约定，项目的文件结构如下，子目录src, include下分别放置erlang源代码和hrl包含文件，priv和ebin目
录分别放置编译好的lib库共享文件（或可执行文件）和beam文件（和其他文件例如app文件），这两个目录由rebar自动生成并清理，不要把重要的代码放在
这两个目录下，虽然不会被rebar clean自动删掉，（不过编译好的beam文件都会删掉），但是也影响不好哈。

此外对port drive和nif的开发，它们的c源程序应该放在c_src目录下。目前port driver和nif是被rebar无区别对待，因此有着同样的rebar控制参数。

总结：源代码应该组织到src, include和c_src三个目录结构中，此外，eunit单元测试代码放在test目录下。rebar控制priv和ebin目录，源码或文档不要
在这两个目录下。

2.3 rebar模板的使用

rebar list-templates 子命令可以查看rebar缺省提供的工程模板（当然也可以创建自己的模板）

模板是针对某种有着固定模式或结构的代码的，例如OTP的3个著名模式都有着各自的程序骨架，每次写一个srv或者fsm的模块，我们都得重复写许多固定的
骨架代码，rebar通过模板帮我们省下了这些重复工作，我们只管往里面填应用的逻辑代码就行了。

显然，simplesrv，simplefsm，simpleapp这三个模板是用来创建OTP的服务器模式，有限状态机模式和app应用模式的。

注意在rebar中，这三个模式的约定名称：srv, fsm和app
相应的，这些模板都有一个约定的控制变量，分别是srvid, fsmid和appid

下面做些实验看看
可以试试创建一个application：
Bash代码  $ rebar create template=simpleapp 

也可以创建一个fsm的模块：
Bash代码  $ rebar create template=simplefsm 

再来一个server模块：
Bash代码  $ rebar create template=simplesrv 

然后在src查看这些自动生成的代码就能理解所谓的rebar 自动生成模板是怎么回事了。

每类模板都有它们自己的生成控制变量，没有这些变量，一切都是默认的。例如上面的实验里，都没有指定模块的控制变量，所以生成的模块都是叫myxxx之
类的缺省名字。

在rebar源代码目录的priv/templates目录下有所有缺省模板的源程序，查阅这些模板的源码可以帮助我们理解rebar的这些模板创建命令的变量是如何工作的：
A) simplefsm.template模板
Simplefsm.template代码  {variables, [{fsmid, "myfsm"}]}. 
{template, "simplefsm.erl", "src/`fsmid`.erl"}. 

这说明fsm模板提供了一个fsmid的变量控制着fsm模块的生成，自定义一个：
Bash代码  rebar create template=simplefsm fsmid=cat 

就在src下创建了一个fsm的cat模块

B） simplemod.tempalte模板
Simplemod.tempalte代码  {variables, [{modid, "mymod"}]}. 
{template, "simplemod.erl", "src/`modid`.erl"}. 
{template, "simplemod_tests.erl", "test/`modid`_tests.erl"}. 

可以通过这个模板创建一个普通的erlang模块，同时它会自动生成该模块的单元测试代码：
该模板提供的控制变量是modid

下面创建一个叫fish的erlang模块：
Bash代码  rebar create template=simplemod modid=fish 

C）basicnif.template模板
Basicnif.template代码  {variables, [{module, "mymodule"}]}. 
{template, "basicnif.erl", "src/`module`.erl"}. 
{template, "basicnif.c", "c_src/`module`.c"}. 

这个模板是用来生成nif模块的，它提供了一个叫module的控制变量
试着生成一个叫dragon的nif模块看看：
Bash代码  rebar create template=basicnif module=dragon 

nif的c代码和erl代码分别放在c_src和src目录下了。

D) simpleapp.template模板
Simpleapp.template代码  {variables, [{appid, "myapp"}]}. 
{template, "simpleapp.app.src", "src/`appid`.app.src"}. 
{template, "simpleapp_app.erl", "src/`appid`_app.erl"}. 
{template, "simpleapp_sup.erl", "src/`appid`_sup.erl"}. 

这说明simpleapp模板提供了一个叫appid的变量，
下面自定义一个叫anmial的应用：
Bash代码  rebar create template=simpleapp appid=anmial 

然后发现src下多了3个和dog application相关的erl源代码

实际上，rebar提供了一个直接创建application的子命令create-app：
Bash代码  rebar create-app appid=anmial 

效果一样。不过命令更短，帮助也详细（至少告诉我们模板变量名是 appid)

下面是以上例子创建了的文件：
Bash代码  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

用rebar自动编译一下：
Bash代码  rebar compile 

可以发现源代码分别编译到ebin和priv两个目录下了，erlang是跨平台的，这没什么好说的。神奇的是nif（包括port driver）的动态共享库（so文件）也
自动编译好了，而且对linux，mac 等自动跨平台支持。所有这些编译都由rebar compile一个命令搞定了。

我们可以通过加个-v参数详细查看编译过程中rebar都做了什么：
Bash代码  rebar compile -v 

控制台上会详细打印出编译过程中用到的命令和参数，还有相关的环境变量。

如前所述，这些命令参数我们可以通过rebar.config进行指定。例如生成nif动态共享库的链接参数，如果动态共享库还需要链接第三方库，那么需要为链接
器指定相关链接参数

比较坑爹的是，如果上面的例子中没有创建applicaton，compile默认是无法编译fsm，server或nif等模块的。整个工程必须有一个app
Bash代码  rebar create-app appid=animal 

对于nif模块也是如此。

可以在rebar.config中通过为port_envs设置环境变量CFLAGS和LDFLAGS指定编译或链接的参数：

在port_envs哪些变量可以定制，似乎没有什么在线文档，所以直接看rebar的源代码程序：rebar_port_compiler.erl。开头的注释中就说明了可以定制哪
些参数，有编译的也有链接的。

举个例子，我最近写的一个nif模块c代码用到了c99的一些特性，还使用到了一个第三方共享库gdal。linux下nif动态库的编译并链接的命令是这样的：
Bash代码  gcc -std=c99 -fPIC -shared -o gdal_nifs.so gdal_nifs.c -I$ERL_HOME/usr/include -lgdal 

mac下的的编译链接命令是这样：
Bash代码  gcc -std=c99 -fPIC -bundle -undefined suppress -flat_namespace -o gdal_nifs.so gdal_nifs.c -I$ERL_HOME/usr/include -lgdal 

rebar已经考虑了跨平台编译链接的不同参数问题，我还需要定制以下两个参数：
1） 指定 c99 标准编译； -std=c99
2） 指定gdal动态库的链接： -lgdal

因此，我的rebar.config定制文件就是
Rebar.config代码  {port_envs, [ 
    {"CFLAGS", "$CFLAGS -std=c99"}, 
    {"LDFLAGS", "$LDFLAGS -lgdal"} 
    ]}. 

以后就可以通过rebar compile跨各种平台编译了。

清理编译好的文件：
Bash代码  rebar clean 

刚才rebar自动编译好的目标文件（beam和so）都会自动删掉。

注：该命令不会清除所有目标文件，它只清除由rebar生成的文件。

rebar的模板很简单，我们也可以自己建模板。自己的代码模板可以放在工程的priv/templates目录下。rebar list-templates会自动列出该目录下的所有
模板，模板格式自己看一下例子，简单的说就是模板变量的字符串替换，也没啥高深的。

要是觉得自己的模板不错也可以提交上去有可能会成为官方模板哦。

3.其它
rebar有着erlang的并行处理能力，缺省情况下每个子命令有3个job worker并行处理，可以通过-j参数控制并行处理的worker数量。

不过由于这种并行处理能力，有时候发现会出现灵异现象，比如有次我想同时清理然后编译：
Barh代码  rebar clean; rebar compile 

发现新的改写代码没有起作用，改成
Bash代码  rebar clean 
rebar compile 

就没有问题了。

因为rebar文档不全，而且几乎每天都有代码修改，处于不断的快速进化中，早期的文档现在看来有的陈旧了，比如网上许多文档都提到了rebar的dialyzer
静态分析，实际上最新的rebar已经不再有这个子命令了。

遇到问题一般可以去翻翻rebar.config.sample，这个配置模板提供了rebar.config的几乎所有配置变量及其说明。比如我的需求中需要写好几个nif模块，
每个nif模块都有自己对应的so.在rebar.config.sample中找到这几行代码:
Rebar.config.sample代码  %% so_specs - useful for building multiple *.so files 
%%            from one or more object files 
{so_specs, [{"priv/so_name.so", ["c_src/object_file_name.o"]}]}.