EMQ X Broker能否使用Elixir插件？编译报mod_vsn未定义错误

核心问题定位 #

两个独立问题共同触发当前编译失败：

• 修改rebar.config时存在Erlang语法错误，破坏relx overlay配置的解析逻辑，导致插件加载路径混乱
• 当前使用的rebar 3.14.3版本与emqx-rel拉取的编译插件存在版本兼容断层，直接触发undefined parse transform 'mod_vsn'报错

具体修正操作 #

1. 修正rebar.config的语法错误 #

你之前对relx overlay块的修改存在结构错误：Erlang配置元组不能直接嵌套{copy}条目，需调整为独立的配置项：

• 保留cuttlefish的copy配置为独立元组：
  {copy, "{{output_dir}}/../../lib/cuttlefish/cuttlefish", "bin/cuttlefish-{{rel_vsn}}"}
• 在overlay列表下新增完全独立的consolidated目录copy规则，不要将其嵌套到原有copy元组中：
  {copy, "{{base_dir}}/consolidated", "releases/{{rel_vsn}}/consolidated"}
• 确认elixir_deps和elixir_relx_apps为顶层独立配置项，不要嵌套到其他配置块内部
• 确认elixir_relx_apps中的应用加载模式为load，不要修改为start，避免release启动时因插件未完成初始化导致启动失败
• 注意：elixir_deps里如果使用SSH格式的git拉取地址，需确保本地SSH鉴权配置正常，否则可替换为对应仓库的HTTPS拉取格式避免拉取失败

2. 解决mod_vsn未定义的兼容问题 #

mod_vsn是早期rebar3内置的版本号解析转换工具，rebar 3.14.0版本开始已将其从核心代码中移除，而当前emqx-rel拉取的旧版编译插件（rebar_mix、rebar3_elixir_compile、relup_helper、port_compiler）仍直接调用该内置实现，因此触发编译失败。可选择以下任意一种修复方案：

• 方案一：将本地rebar3版本降级为3.13.x稳定分支，该版本仍内置mod_vsn实现，与当前插件版本完全兼容
• 方案二：保留当前rebar3版本，在项目的plugins配置块中，将所有触发报错的编译插件替换为最新兼容版本，新版本插件已将mod_vsn声明为显式依赖，不再依赖rebar3内置实现

3. 清理旧编译缓存后重新构建 #

之前的失败编译会在构建目录残留损坏的字节码文件，需先清理缓存再执行编译：

• 删除项目根目录下的_build目录、_checkouts软链接
• 清理本地rebar3全局缓存目录下与当前emqx项目相关的缓存文件
• 先执行rebar3 get-deps完成全量依赖拉取
• 最后执行make命令触发完整编译流程

环境校验 #

你当前使用的OTP 23、Elixir 1.11.3版本组合是官方适配的稳定组合，无需调整版本即可完成插件集成。

内容的提问来源于stack exchange，提问作者sokc