rebar3 自定义编译插件攻略

插件任务：

在用户执行rebar3 compile时，自动运行插件自定义的逻辑。

增加钩子：

在顶层目录的rebar3.config中增加配置(provider hooks的写法）

{provider_hooks, [       
	{pre, [{compile, {auto_config, compile}}]}
]}.

意为 rebar3 compile命令前，自动执行 rebar3 auto_config compile 指令

或者 shell hooks 的写法：
{pre_hooks， [“win32”, compile, “rebar3 auto_config compile”]}

新建插件文件：

在新建插件的目录下执行：
rebar3 new plugin 插件名字
输出为：

===> Writing rebar3_auto_config_plugin/src/rebar3_auto_config_plugin.erl 
===> Writing rebar3_auto_config_plugin/src/rebar3_auto_config_plugin_prv.erl 
===> Writing rebar3_auto_config_plugin/src/rebar3_auto_config_plugin.app.src 
===> Writing rebar3_auto_config_plugin/rebar.config 
===> Writing rebar3_auto_config_plugin/.gitignore 
===> Writing rebar3_auto_config_plugin/LICENSE 
===> Writing rebar3_auto_config_plugin/README.md

_prv文件简介：

文件中有三个回调需要我们实现：

• init(State) - {ok, NewState}，进行插件设置。
• do(State) - {ok, NewState} | {error, Error}，执行实际的工作。
• format_error(Error) - 错误发生时打印错误。

插件设置的内容有：

• name：任务的名称。 module：任务的实现模块。
• bare：用户是否可以运行任务。应该设置为true。
• deps：依赖项列表，不需要包含依赖项的依赖项。[dep | {namespace, dep}]
• desc：任务描述，rebar3帮助使用
• short_desc：任务的一行简短描述
• example：任务用法示例，例如“rebar3 my-provider args”
• opts：执行任务的选项列表。形式为 {Key, $Character, ‘StringName’, Spec, HelpText}，其中：
  • Key 是一个原子，用于通过
    {Args, _} = rebar_state:command_parsed_args(State)
    Arg = proplists:get_value(Key, Args)
    获取选项值；
  • $Character 是选项的缩写形式。如果命令要作为 -c Arg 输入，则Character 应该为 c
  • Spec 可以是类型（atom、binary、boolean、float、integer或string）、默认的类型（{Type、Val}）或 undefined。
• profiles：配置文件。默认为 [default]。
• namespace：注册命名空间。默认为 default。

添加命名空间：

在 rebar3_auto_config_plugin_prv 文件 init函数中，增加namespace的定义，修改后代码如下：

Provider = providers:create([             
	{name, ?PROVIDER},                        
	{namespace, auto_config},   
	......

命名空间的作用是避免?PROVIDER和别的插件或默认命令冲突。
插件的 ?PROVIDER 定义为 compile， 那么当用户执行 rebar3 compile xxx 的时候， rebar3是执行默认的compile指令呢还是插件的指令？ 为了区分这种尴尬的情况，namespace字段就排上用场了。现在我们执行 rebar3 auto_config compile XXX， rebar3就知道需要运行的是aoto_config插件指令。

DEPS的宏需要改为

-define(DEPS, [{default, app_discovery}]).

因为我们当前模块定义了新的命名空间，要使用app_discovery的话，需要指明其来源的命名空间。
如果我们没有定义新的命名空间，那么使用默认的宏定义即可。

获取执行插件的app：

-spec do(rebar_state:t()) -> {ok, rebar_state:t()} | {error, string()}.
do(State) ->     
	Apps = case rebar_state:current_app(State) of   
		undefined -> rebar_state:project_apps(State);                 	
		AppInfo -> [AppInfo]            
	end,     
	[do_some_thing(AppInfo) || AppInfo <- Apps],     
	{ok, State}.

在 do_some_thing 中实现插件的功能即可。