如何把Rebar项目迁移到erlang.mk两大Erlang构建工具对比与兼容性完整清单【免费下载链接】erlang.mkA build tool for Erlang that just works.项目地址: https://gitcode.com/gh_mirrors/er/erlang.mkerlang.mk是 Erlang 生态中一款开箱即用的构建工具基于 GNU Make 编写而Rebar是另一个广泛使用的 Erlang 构建工具。很多团队希望把 Rebar 项目迁移到 erlang.mk以获得更统一的依赖管理与更丰富的插件体系。本文通过两大 Erlang 构建工具对比和一份可落地的兼容性清单带你快速完成 Rebar 到 erlang.mk 的迁移双向兼容一次搞定。 一、Rebar 与 erlang.mk 核心差异速览在动手迁移前先理解两款工具的设计差异迁移时才不会水土不服对比维度Rebar2/3erlang.mk配置文件rebar.configErlang 项列表MakefileMake 变量依赖管理锁文件rebar.lock 依赖锁版本DEPS变量 内置包索引约 500 个包依赖存放_build/default/lib/deps/目录插件体系rebar 插件Erlang 编写Make 插件.mk文件如 EUnit、Cover、Dialyzer版本管理方式语义化版本约束dep_应用名_commit直接锁定提交/标签生态定位独立完整工具链强调与其他工具互相兼容官方定位是合群的孩子 关键认知erlang.mk并非要你二选一——它内置了双向兼容机制源码见core/compat.mk既能直接构建 Rebar 项目也能反向生成rebar.config供 Rebar 使用。 二、迁移路径一零成本体验——直接依赖 Rebar 项目如果你只是想让 erlang.mk 项目引用一个 Rebar 写的依赖库完全不用改对方代码。erlang.mk 的Autopatch自动打补丁机制会在拉取依赖时自动检测 Rebar 项目一旦在依赖目录中发现rebar.config或rebar.lock它会临时引入 rebar3 读取配置然后生成一个 erlang.mk 风格的Makefile把 Rebar 项目翻译成 erlang.mk 项目实现细节位于core/deps.mk的dep_autopatch_rebar部分。对你来说只需在 Makefile 里写一行DEPS cowboy dep_cowboy git https://github.com/ninenines/cowboy 2.9.0下次执行make时自动拉取并编译无需安装 Rebar。️ 三、迁移路径二把手头 Rebar 项目正式迁移到 erlang.mk以下是完整的5 步迁移流程适用于把自有项目从 Rebar 切换到 erlang.mk 构建。第 1 步获取 erlang.mk 并初始化项目在仓库根目录加入 erlang.mk 文件建议提交到版本库git clone https://gitcode.com/gh_mirrors/er/erlang.mk erlang.mk-build cp erlang.mk-build/erlang.mk ./官方推荐做法是下载引导版文件后执行make -f erlang.mk bootstrap让它自我补全为完整版本详见doc/src/guide/getting_started.asciidoc。第 2 步编写 Makefile对照模板参考官方项目模板templates/top_Makefile最小化的 Makefile 形如PROJECT my_app PROJECT_VERSION 1.0.0 include erlang.mk项目名必须与目录名、应用名保持一致后续 release 等功能依赖这一点。第 3 步对照清单转换 rebar.config兼容性清单⭐这是迁移的核心环节。下面这份rebar.config → Makefile 变量对照清单覆盖了绝大多数场景rebar.config 配置erlang.mk 等价写法说明{deps, [{app, 1.0}]}DEPS appdep_app_commit 1.0依赖声明与版本锁定Hex 包依赖{app, 2.1}dep_app hex 2.1支持从 Hex 仓库拉取{erl_opts, [debug_info, warn_unused_vars]}ERLC_OPTS debug_info warn_unused_vars编译选项逐个平迁仅构建期依赖BUILD_DEPS erlando如 parse transform 类库仅测试依赖TEST_DEPS ct_helper运行时依赖之外的隔离OTP 自带应用如 cryptoLOCAL_DEPS crypto无需下载c_src/目录 C NIFC_SRC_TYPE rebar由 Autopatch 自动生成cover测试覆盖率直接执行make cover内置插件无需配置rebar3 profiledev/prod用make的不同 target 表达如make release、make tests{relx, [...]}发布配置make relxrelx.config模板见templates/relx.config⚠️ 细节提醒erlang.mk 在转换编译选项时会自动剔除-Werror避免依赖库因警告而编译失败见core/compat.mk的注释说明。第 4 步确认应用资源文件app.srcRebar 家族构建项目需要两个文件rebar.config和应用资源文件。资源文件位于src/$(PROJECT).app.src或ebin/$(PROJECT).app。如果仓库里已有src/my_app.app.src无需任何操作如果没有erlang.mk 每次编译都会在ebin/下生成.app文件把它提交进仓库即可其他构建工具也能识别。第 5 步双向兼容验证 更新 CI执行一次make rebar.configerlang.mk 会读取DEPS和ERLC_OPTS变量反向生成一份rebar.configGit 分支/标签/ref 都能正确识别。这样你的项目同时被两套工具链支持# 让每次构建自动刷新 rebar.config app:: rebar.config迁移完成后记得提交新生成的rebar.config并把 CI 中的rebar compile替换为make、rebar proper替换为make check。erlang.mk 自带的 CI 插件可生成 Travis 等平台的配置参考plugins/ci.mk。 四、迁移后常见坑与排查清单✅ 迁移完成后对照这份清单逐项验证依赖版本漂移不同构建工具拉取策略不同若某依赖声明了不同版本可能拉取到不同结果。用make query-deps输出完整依赖树核对。cp本地拷贝依赖erlang.mk 特有获取方式如dep_xxx cp 路径Rebar 无法识别这类项目不要指望反向兼容。插件类配置不迁移Rebar 专有插件如自定义 rebar 插件没有直接等价物需改写为 erlang.mk 插件或独立 Make target。验证 Rebar 侧可用性可以用rebar3 compile对生成物做一次交叉验证官方测试套件test/core_compat.mk就是这么做的含依赖分支/标签/Hex 包、编译选项、parse_transform 等多种场景。Windows 用户需在 MSYS2 环境下使用注意文件换行符为 LF详见doc/src/guide/installation.asciidoc。 五、延伸阅读官方兼容性章节doc/src/guide/compat.asciidocRebar 项目互操作权威说明依赖管理详解doc/src/guide/deps.asciidoc获取方式、依赖冲突规则、多应用仓库自动打补丁机制实现core/deps.mkrebar.config 生成实现core/compat.mk兼容性自动化测试test/core_compat.mk新项目脚手架模板templates/top_Makefile、templates/application.app.src✅ 总结把 Rebar 项目迁移到 erlang.mk 并不痛苦依赖型场景零改动Autopatch 自动翻译项目级迁移只需三步——放好 erlang.mk、写一个十几行的 Makefile、按对照清单搬配置。再配合make rebar.config反向生成实现双工具链共存迁移风险降到最低。迁移完成的那天起你就同时拥有了约 500 个包的索引、make shell交互式调试和一套完整的测试插件生态这就是 erlang.mk just works 的底气。【免费下载链接】erlang.mkA build tool for Erlang that just works.项目地址: https://gitcode.com/gh_mirrors/er/erlang.mk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考