Rebar3中REBAR_SRC_DIRS环境变量的行为解析与改进建议

在Erlang生态系统中，Rebar3作为主流的构建工具，其环境变量机制为开发者提供了丰富的扩展能力。本文将深入分析REBAR_SRC_DIRS环境变量的当前行为、存在的问题以及可能的改进方向。

REBAR_SRC_DIRS的现状

在Rebar3的hook机制中，REBAR_SRC_DIRS环境变量目前存在一个特殊现象：当在pre_hook中尝试访问该变量时，返回的是空字符串。这与开发者期望的包含源代码目录列表的行为不符。

这种行为的根源在于Rebar3内部实现机制。虽然Erlang编译器默认使用"src"目录，但这仅适用于Erlang编译器(erl、yrl和xrl)。其他编译器(如mib或插件)会指定不同的默认目录。

技术背景分析

Rebar3的源代码目录处理逻辑具有以下特点：

1. 默认情况下，Erlang编译器使用src目录作为源代码目录
2. 不同编译器可以覆盖默认的源代码目录设置
3. REBAR_SRC_DIRS参数主要来自可以覆盖默认目录的配置选项
4. 该参数可以全局配置，但特定编译器会覆盖全局设置

改进建议

经过深入分析，我们建议对REBAR_SRC_DIRS进行以下改进：

1. 默认传递Erlang编译的默认值，即包含"src"目录
2. 考虑递归选项的处理，虽然这可能会带来一些复杂性
3. 确保路径解析的一致性，特别是对于依赖项中的源代码目录

递归处理的挑战

递归处理源代码目录存在一些特殊挑战：

1. src_dirs默认是递归的，而extra_src_dirs默认不是递归的
2. 递归设置可能会意外包含不需要的目录
3. 不同上下文中的递归规则可能不一致

路径解析方案

对于路径解析，我们有以下几种可选方案：

1. 相对于构建目录(_build)中的应用程序路径
2. 返回纯相对路径，让用户自行决定如何处理
3. 扩展源代码目录的递归性(需谨慎考虑)

最佳实践建议

基于当前分析，我们建议开发者：

1. 不要过度依赖REBAR_SRC_DIRS的递归行为
2. 明确指定需要的源代码目录，而不是依赖默认值
3. 注意环境变量值的时机敏感性(插件编译后可能改变)

总结

REBAR_SRC_DIRS环境变量的当前行为虽然有其历史原因，但确实与开发者预期存在差距。通过合理的默认值设置和清晰的路径解析策略，可以显著改善这一状况，同时保持与现有构建系统的兼容性。对于需要精确控制构建过程的开发者，建议直接指定完整的源代码目录路径，而不是依赖环境变量的隐式行为。