把应用磨成命令

用 rebar3 profile 分开环境，再构建可执行 escript。

01 · 先看完整例子

写一个最小入口模块

在 rebar.config 设置 escript 名与主应用，运行 rebar3 escriptize。

Erlang

-module(hello_cli).
-export([main/1]).

%% main/1 接收终端参数 charlist 列表
main([Name]) ->
  io:format("hello, ~ts~n", [Name]);
main(_) ->
  io:format(standard_error, "usage: hello_cli NAME~n", []).

先对照结果

_build/default/bin/hello_cli A-Qing 打印 hello, A-Qing。

02 · 回头拆代码

从第一行往下读

两个函数子句分别处理一个参数与错误参数。
~ts 按 Unicode 文字输出参数。
测试 profile 只放测试专用配置，避免污染默认构建。

03 · 认清新符号

符号不是暗号

{profiles, [...]}.

在 rebar.config 声明环境配置。

rebar3 as test ...

在指定 profile 下运行任务。

rebar3 escriptize

构建项目 escript。

04 · 代码里的概念

把名字和意思对上

profile

rebar3 中按环境覆盖依赖或配置的一组设置。

escript

可由 Erlang 运行时执行的单文件脚本包。

05 · 再说清楚

这些写法为什么有用

profile 让测试、开发等环境使用不同配置，不把临时工具带进正式构建。

escript 把应用代码包装成一个终端入口。入口模块导出 main/1，参数是字符串 list。

构建前依次格式化、测试、分析。命令还要处理参数错误并给出用法。

06 · 自己改一次

合上答案，动手

补全最小 profile，让测试环境定义宏 TEST。

练习起点

{profiles, [
  {test, [
    {erl_opts, [____]}
  ]}
]}.

目标结果： 在 test profile 的 erl_opts 中加入 {d, 'TEST'}。

卡住了，再看提示

编译宏选项使用 tuple {d, 'TEST'}。

运行过以后，再看一种答案

一种答案

{profiles, [
  %% 只在 test profile 定义 TEST 宏
  {test, [
    {erl_opts, [{d, 'TEST'}]}
  ]}
]}.

想一想：escript 是否包含一套完全独立的 Erlang 运行时？

通常不包含。目标机器仍需要可用的 Erlang 运行时。

带走

记住三句

1
profile 隔离环境配置。
2
escript 入口是 main/1。
3
构建命令也要处理错误参数。

本课结束代码也跑过一次，就把这一课收好。