Erlang/OTP 构建体系中的 autoconf 辅助文件erts/autoconf目录的角色、更新机制与迁移指南【免费下载链接】otpErlang/OTP项目地址: https://gitcode.com/gh_mirrors/ot/otp导读在 Erlang/OTP 源码仓库中erts/autoconf 目录存放着一组 Autoconf 辅助脚本config.guess、config.sub、install-sh等它们是整个 OTP 构建系统中被众多子项目 configure 脚本所依赖的关键设施。本文以该目录的 README.md 为骨架系统讲解这些文件的真实身份——它们只是 make/autoconf 主目录中原始文件的同步副本用于兼容历史外部脚本同时结合otp_build update_configure的源码实现完整说明这些副本如何被自动刷新、为什么要以make/autoconf为准以及未来移除该目录的迁移路径。读完本文你将理解 OTP 仓库中主文件—副本的维护模式掌握手动更新 configure 脚本的正确姿势并能在自己的开发流程中避免踩到副本目录的坑。一、erts/autoconf目录里到底有什么在 OTP 源码树中erts/autoconf 目录下实际存放着以下文件config.guess—— GNU 工具链中用于猜测构建/宿主系统三元组的脚本config.sub—— 用于规范化canonicalize系统三元组的脚本install-sh—— 可移植的install命令替代脚本vendor.info—— 记录 Autoconf 依赖组件版本与许可证元数据的清单文件当前记录 Autoconf 2.72版权方 Free Software Foundation许可证为MIT AND (GPL-3.0-or-later WITH Autoconf-exception-generic-3.0)见 make/autoconf/vendor.info。需要特别强调除 README 之外该目录中的所有文件都不是这里的原生文件而是位于$ERL_TOP/make/autoconf目录下原始文件的副本。README 的原话是All files in this directory except for the README.md files are copies of primary files located in the$ERL_TOP/make/autoconfdirectory.这些副本之所以存在唯一的目的是兼容那些可能依赖该路径的外部脚本——历史上一些第三方工具链和 CI 脚本习惯从erts/autoconf下寻找config.guess/config.sub/install-sh为了不让它们立即失效OTP 保留了这份镜像。README 同时明确指出日常开发中应该使用$ERL_TOP/make/autoconf目录下的文件而不是本目录的副本本目录的文件最终将被移除The files in this directory will eventually be removed.。因此理解这一目录的正确姿势是把它当作一个兼容性镜像看待而不是 OTP 构建的权威来源。二、副本如何被自动更新otp_build update_configure工作机制erts/autoconf下的副本不是手工维护的而是由 OTP 顶层构建脚本 otp_build 的update_configure子命令自动同步的。README 原文Files in this directory are updated automatically when executing$ERL_TOP/otp_build update_configure [--no-commit].2.1 入口与版本校验在 otp_build 的do_update_configure ()函数中脚本首先固定 Autoconf 版本export AUTOCONF_VERSION$USE_AUTOCONF_VERSION ac_ver_blobautoconf --version # ... 校验 autoconf 版本必须与 USE_AUTOCONF_VERSION 一致其中USE_AUTOCONF_VERSION2.72见 otp_build且各子项目的configure.ac也通过AC_PREREQ([2.72])声明了同样的最低版本要求例如 erts/configure.ac 与 make/configure.ac。如果 PATH 中autoconf --version的版本不是 2.72脚本会打印ERROR: autoconf of version ... found in path!并立即退出——这是为了保证生成的 configure 脚本具备一致、可复现的行为。2.2 辅助脚本的分发同步副本的核心逻辑版本校验通过后脚本将make/autoconf下的三个主文件复制到所有辅助目录中otp_buildinstall_shbasename $install_sh_master # install-sh config_guessbasename $config_guess_master # config.guess config_subbasename $config_sub_master # config.sub for dir in $autoconf_aux_dirs; do $install_sh_master -d $dir $install_sh_master -t $dir $install_sh_master out_files$out_files $dir/$install_sh $install_sh_master -t $dir $config_guess_master out_files$out_files $dir/$config_guess $install_sh_master -t $dir $config_sub_master out_files$out_files $dir/$config_sub done关键的路径变量定义在 otp_build变量值含义autoconf_aux_dirs./erts/autoconf ./lib/common_test/test_server需要接收副本的辅助目录install_sh_master./make/autoconf/install-shinstall-sh 主文件config_guess_master./make/autoconf/config.guessconfig.guess 主文件config_sub_master./make/autoconf/config.subconfig.sub 主文件可以看到erts/autoconf只是两个分发目标之一另一个是lib/common_test/test_server。也就是说凡是需要 Autoconf 辅助脚本的目录都会从make/autoconf同步一份而make/autoconf才是唯一的数据源头。2.3 重新生成各子项目的 configure 脚本同步辅助脚本之后do_update_configure遍历AUTOCONF_SUBDIRS值为lib lib/* lib/common_test/test_server make erts见 otp_build对每个包含configure.ac的目录执行( cd $d autoconf -B $ERL_TOP/make/autoconf) || exit 1-B $ERL_TOP/make/autoconf指定 Autoconf 的预包含文件目录使各子项目可以通过m4_include([otp.m4])使用 OTP 本地宏如果该configure.ac中包含AC_CONFIG_HEADER还会继续执行autoheader生成config.h.inotp_build。最后脚本基于 configure.src 模板生成仓库根目录的./configure包装脚本otp_build其中BOOTSTRAP_LIB_APP_DIRS占位符会被替换为 bootstrap 阶段所需的应用目录列表。这里有一个值得注意的约束configure.src 头部明确警告不要直接编辑生成的configure文件所有修改都应落在configure.src上再通过update_configure重新生成。2.4 提交行为不带参数执行./otp_build update_configure时脚本会用git add暂存所有更新后的文件并自动提交提交信息为Update configure scripts带--no-commit参数时只更新文件、不提交并在终端打印Updated: 文件列表otp_build。三、正确使用姿势以make/autoconf为主目录3.1 何时会碰到erts/autoconf作为普通用户你几乎不需要关心erts/autoconf的内容——OTP 源码发行版已经预生成了所有configure脚本直接./configure即可开始构建。OTP 官方在 otp_build 中也明确宣布./otp_build autoconf已经不再需要执行它只会打印提示信息——所有 configure 脚本都已提交进仓库随时可用。真正需要接触这两个目录的场景是OTP 核心开发者修改了configure.ac/otp.m4/configure.src需要重新生成并提交 configure 脚本时第三方脚本或打包工具为了探测系统三元组习惯性读取erts/autoconf/config.guess时这正是该目录至今保留的原因。3.2 推荐的更新流程作为 OTP 仓库的维护者正确流程是# 1. 确保 PATH 中的 autoconf 版本为 2.72 autoconf --version # 2. 更新所有 configure 脚本、config.h.in 以及辅助目录中的副本 ./otp_build update_configure --no-commit # 3. 人工检查更新后的 diff git diff # 4. 确认无误后再提交 git add -u git commit -m Update configure scripts该命令会一次性完成三类产物的一致性更新make/autoconf主文件分发到erts/autoconf与lib/common_test/test_server的副本、各子项目由autoconf/autoheader生成的configure/config.h.in、以及仓库根的./configure包装脚本。3.3 迁移提醒README 明确指出erts/autoconf下的文件最终将被移除。因此如果你在维护依赖 OTP 仓库的外部脚本建议尽快将硬编码的erts/autoconf/...路径迁移到make/autoconf/...避免未来目录清理导致脚本失效。四、源码级佐证OTP 的 Autoconf 设施全景为了更完整地理解这份 README 所处的上下文可以从仓库源码中梳理出 OTP 的 Autoconf 设施全景主目录make/autoconfconfig.guess、config.sub、install-sh—— 三个由 Free Software Foundation 提供、随 Autoconf 2.72 分发的辅助脚本otp.m4 —— OTP 本地 Autoconf 宏库包含大量ERL_*/LM_*前缀的宏例如ERL_CANONICAL_SYSTEM_TYPE规范化并处理 Windows 遗留 hack、LM_WINDOWS_ENVIRONMENT探测 MSYS/Cygwin/WSL 混合环境、LM_FIND_EMU_CC寻找能处理 jump table 的编译器以编译beam_emu.c、ERL_MONOTONIC_CLOCK为不同平台挑选单调时钟源等各子项目的configure.ac通过m4_include([otp.m4])引入参见 erts/configure.ac 与 make/configure.acvendor.info—— 组件版本与许可证元数据用于 SBOM 溯源4 个win*.config.cache.static—— Windows 平台专用的静态 config cache因为并行 configure 时禁用通用 cacheWindows 上不用静态 cache 会慢到难以接受。分发目标erts/autoconf —— 本文主题兼容性镜像lib/common_test/test_server —— 另一个分发目标为 Common Test 的 test_server 提供同样的辅助脚本。根目录包装脚本configure.src →./configure这是一个手写的包装脚本负责并行驱动各个子项目的真实 configure除非传入--disable-parallel-configure它还负责在 Windows 上为每个子 configure 使用静态 cache并默认禁用通用 config cache因为并行执行多个 configure 时 cache 反而容易出问题见 configure.src 的注释。版本锁定USE_AUTOCONF_VERSION2.72otp_build与各configure.ac的AC_PREREQ([2.72])双重约束确保全仓库生成的 configure 脚本行为一致。从源码结构可以推断OTP 采用单一主目录 自动分发的模式来维护 Autoconf 辅助脚本erts/autoconf是这一模式下的历史遗留产物其存在价值纯粹是向后兼容。五、常见问题Q1我修改了erts/autoconf/config.guess为什么构建没有生效因为该文件只是副本真正起作用的是 make/autoconf/config.guess。任何针对辅助脚本的修改都应以主目录为准然后通过./otp_build update_configure --no-commit重新分发。Q2erts/autoconf会被删除吗README 明确声明will eventually be removed。它只是为兼容外部脚本而保留不属于 OTP 构建系统的必要组成部分。Q3为什么 otp_build 强制要求 autoconf 2.72一方面各configure.ac通过AC_PREREQ([2.72])声明依赖另一方面OTP 希望任何开发者重新生成的 configure 脚本与仓库中已提交的脚本行为完全一致从而避免不同 autoconf 版本生成不同 configure的不可复现问题。Q4普通用户构建 OTP 需要运行otp_build update_configure吗不需要。源码发行版已包含全部预生成的 configure 脚本直接运行根目录 ./configure 即可只有修改了 configure 相关源文件的开发者才需要执行该命令。六、结语erts/autoconf是 Erlang/OTP 构建体系中的一个兼容性镜像目录它的文件全部来自 make/autoconf 主目录由 otp_build 的update_configure子命令自动同步分发且已被官方标记为最终将移除。理解这一目录的关键在于认清主文件—副本的关系日常开发与外部脚本都应优先使用$ERL_TOP/make/autoconf而erts/autoconf只是过渡期的向后兼容措施。本文所涉及的更新命令、版本约束与源码调用链均可直接在 otp_build、make/autoconf/otp.m4 与 configure.src 中逐一验证。【免费下载链接】otpErlang/OTP项目地址: https://gitcode.com/gh_mirrors/ot/otp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Erlang/OTP 构建体系中的 autoconf 辅助文件：`erts/autoconf` 目录的角色、更新机制与迁移指南
Erlang/OTP 构建体系中的 autoconf 辅助文件erts/autoconf目录的角色、更新机制与迁移指南【免费下载链接】otpErlang/OTP项目地址: https://gitcode.com/gh_mirrors/ot/otp导读在 Erlang/OTP 源码仓库中erts/autoconf 目录存放着一组 Autoconf 辅助脚本config.guess、config.sub、install-sh等它们是整个 OTP 构建系统中被众多子项目 configure 脚本所依赖的关键设施。本文以该目录的 README.md 为骨架系统讲解这些文件的真实身份——它们只是 make/autoconf 主目录中原始文件的同步副本用于兼容历史外部脚本同时结合otp_build update_configure的源码实现完整说明这些副本如何被自动刷新、为什么要以make/autoconf为准以及未来移除该目录的迁移路径。读完本文你将理解 OTP 仓库中主文件—副本的维护模式掌握手动更新 configure 脚本的正确姿势并能在自己的开发流程中避免踩到副本目录的坑。一、erts/autoconf目录里到底有什么在 OTP 源码树中erts/autoconf 目录下实际存放着以下文件config.guess—— GNU 工具链中用于猜测构建/宿主系统三元组的脚本config.sub—— 用于规范化canonicalize系统三元组的脚本install-sh—— 可移植的install命令替代脚本vendor.info—— 记录 Autoconf 依赖组件版本与许可证元数据的清单文件当前记录 Autoconf 2.72版权方 Free Software Foundation许可证为MIT AND (GPL-3.0-or-later WITH Autoconf-exception-generic-3.0)见 make/autoconf/vendor.info。需要特别强调除 README 之外该目录中的所有文件都不是这里的原生文件而是位于$ERL_TOP/make/autoconf目录下原始文件的副本。README 的原话是All files in this directory except for the README.md files are copies of primary files located in the$ERL_TOP/make/autoconfdirectory.这些副本之所以存在唯一的目的是兼容那些可能依赖该路径的外部脚本——历史上一些第三方工具链和 CI 脚本习惯从erts/autoconf下寻找config.guess/config.sub/install-sh为了不让它们立即失效OTP 保留了这份镜像。README 同时明确指出日常开发中应该使用$ERL_TOP/make/autoconf目录下的文件而不是本目录的副本本目录的文件最终将被移除The files in this directory will eventually be removed.。因此理解这一目录的正确姿势是把它当作一个兼容性镜像看待而不是 OTP 构建的权威来源。二、副本如何被自动更新otp_build update_configure工作机制erts/autoconf下的副本不是手工维护的而是由 OTP 顶层构建脚本 otp_build 的update_configure子命令自动同步的。README 原文Files in this directory are updated automatically when executing$ERL_TOP/otp_build update_configure [--no-commit].2.1 入口与版本校验在 otp_build 的do_update_configure ()函数中脚本首先固定 Autoconf 版本export AUTOCONF_VERSION$USE_AUTOCONF_VERSION ac_ver_blobautoconf --version # ... 校验 autoconf 版本必须与 USE_AUTOCONF_VERSION 一致其中USE_AUTOCONF_VERSION2.72见 otp_build且各子项目的configure.ac也通过AC_PREREQ([2.72])声明了同样的最低版本要求例如 erts/configure.ac 与 make/configure.ac。如果 PATH 中autoconf --version的版本不是 2.72脚本会打印ERROR: autoconf of version ... found in path!并立即退出——这是为了保证生成的 configure 脚本具备一致、可复现的行为。2.2 辅助脚本的分发同步副本的核心逻辑版本校验通过后脚本将make/autoconf下的三个主文件复制到所有辅助目录中otp_buildinstall_shbasename $install_sh_master # install-sh config_guessbasename $config_guess_master # config.guess config_subbasename $config_sub_master # config.sub for dir in $autoconf_aux_dirs; do $install_sh_master -d $dir $install_sh_master -t $dir $install_sh_master out_files$out_files $dir/$install_sh $install_sh_master -t $dir $config_guess_master out_files$out_files $dir/$config_guess $install_sh_master -t $dir $config_sub_master out_files$out_files $dir/$config_sub done关键的路径变量定义在 otp_build变量值含义autoconf_aux_dirs./erts/autoconf ./lib/common_test/test_server需要接收副本的辅助目录install_sh_master./make/autoconf/install-shinstall-sh 主文件config_guess_master./make/autoconf/config.guessconfig.guess 主文件config_sub_master./make/autoconf/config.subconfig.sub 主文件可以看到erts/autoconf只是两个分发目标之一另一个是lib/common_test/test_server。也就是说凡是需要 Autoconf 辅助脚本的目录都会从make/autoconf同步一份而make/autoconf才是唯一的数据源头。2.3 重新生成各子项目的 configure 脚本同步辅助脚本之后do_update_configure遍历AUTOCONF_SUBDIRS值为lib lib/* lib/common_test/test_server make erts见 otp_build对每个包含configure.ac的目录执行( cd $d autoconf -B $ERL_TOP/make/autoconf) || exit 1-B $ERL_TOP/make/autoconf指定 Autoconf 的预包含文件目录使各子项目可以通过m4_include([otp.m4])使用 OTP 本地宏如果该configure.ac中包含AC_CONFIG_HEADER还会继续执行autoheader生成config.h.inotp_build。最后脚本基于 configure.src 模板生成仓库根目录的./configure包装脚本otp_build其中BOOTSTRAP_LIB_APP_DIRS占位符会被替换为 bootstrap 阶段所需的应用目录列表。这里有一个值得注意的约束configure.src 头部明确警告不要直接编辑生成的configure文件所有修改都应落在configure.src上再通过update_configure重新生成。2.4 提交行为不带参数执行./otp_build update_configure时脚本会用git add暂存所有更新后的文件并自动提交提交信息为Update configure scripts带--no-commit参数时只更新文件、不提交并在终端打印Updated: 文件列表otp_build。三、正确使用姿势以make/autoconf为主目录3.1 何时会碰到erts/autoconf作为普通用户你几乎不需要关心erts/autoconf的内容——OTP 源码发行版已经预生成了所有configure脚本直接./configure即可开始构建。OTP 官方在 otp_build 中也明确宣布./otp_build autoconf已经不再需要执行它只会打印提示信息——所有 configure 脚本都已提交进仓库随时可用。真正需要接触这两个目录的场景是OTP 核心开发者修改了configure.ac/otp.m4/configure.src需要重新生成并提交 configure 脚本时第三方脚本或打包工具为了探测系统三元组习惯性读取erts/autoconf/config.guess时这正是该目录至今保留的原因。3.2 推荐的更新流程作为 OTP 仓库的维护者正确流程是# 1. 确保 PATH 中的 autoconf 版本为 2.72 autoconf --version # 2. 更新所有 configure 脚本、config.h.in 以及辅助目录中的副本 ./otp_build update_configure --no-commit # 3. 人工检查更新后的 diff git diff # 4. 确认无误后再提交 git add -u git commit -m Update configure scripts该命令会一次性完成三类产物的一致性更新make/autoconf主文件分发到erts/autoconf与lib/common_test/test_server的副本、各子项目由autoconf/autoheader生成的configure/config.h.in、以及仓库根的./configure包装脚本。3.3 迁移提醒README 明确指出erts/autoconf下的文件最终将被移除。因此如果你在维护依赖 OTP 仓库的外部脚本建议尽快将硬编码的erts/autoconf/...路径迁移到make/autoconf/...避免未来目录清理导致脚本失效。四、源码级佐证OTP 的 Autoconf 设施全景为了更完整地理解这份 README 所处的上下文可以从仓库源码中梳理出 OTP 的 Autoconf 设施全景主目录make/autoconfconfig.guess、config.sub、install-sh—— 三个由 Free Software Foundation 提供、随 Autoconf 2.72 分发的辅助脚本otp.m4 —— OTP 本地 Autoconf 宏库包含大量ERL_*/LM_*前缀的宏例如ERL_CANONICAL_SYSTEM_TYPE规范化并处理 Windows 遗留 hack、LM_WINDOWS_ENVIRONMENT探测 MSYS/Cygwin/WSL 混合环境、LM_FIND_EMU_CC寻找能处理 jump table 的编译器以编译beam_emu.c、ERL_MONOTONIC_CLOCK为不同平台挑选单调时钟源等各子项目的configure.ac通过m4_include([otp.m4])引入参见 erts/configure.ac 与 make/configure.acvendor.info—— 组件版本与许可证元数据用于 SBOM 溯源4 个win*.config.cache.static—— Windows 平台专用的静态 config cache因为并行 configure 时禁用通用 cacheWindows 上不用静态 cache 会慢到难以接受。分发目标erts/autoconf —— 本文主题兼容性镜像lib/common_test/test_server —— 另一个分发目标为 Common Test 的 test_server 提供同样的辅助脚本。根目录包装脚本configure.src →./configure这是一个手写的包装脚本负责并行驱动各个子项目的真实 configure除非传入--disable-parallel-configure它还负责在 Windows 上为每个子 configure 使用静态 cache并默认禁用通用 config cache因为并行执行多个 configure 时 cache 反而容易出问题见 configure.src 的注释。版本锁定USE_AUTOCONF_VERSION2.72otp_build与各configure.ac的AC_PREREQ([2.72])双重约束确保全仓库生成的 configure 脚本行为一致。从源码结构可以推断OTP 采用单一主目录 自动分发的模式来维护 Autoconf 辅助脚本erts/autoconf是这一模式下的历史遗留产物其存在价值纯粹是向后兼容。五、常见问题Q1我修改了erts/autoconf/config.guess为什么构建没有生效因为该文件只是副本真正起作用的是 make/autoconf/config.guess。任何针对辅助脚本的修改都应以主目录为准然后通过./otp_build update_configure --no-commit重新分发。Q2erts/autoconf会被删除吗README 明确声明will eventually be removed。它只是为兼容外部脚本而保留不属于 OTP 构建系统的必要组成部分。Q3为什么 otp_build 强制要求 autoconf 2.72一方面各configure.ac通过AC_PREREQ([2.72])声明依赖另一方面OTP 希望任何开发者重新生成的 configure 脚本与仓库中已提交的脚本行为完全一致从而避免不同 autoconf 版本生成不同 configure的不可复现问题。Q4普通用户构建 OTP 需要运行otp_build update_configure吗不需要。源码发行版已包含全部预生成的 configure 脚本直接运行根目录 ./configure 即可只有修改了 configure 相关源文件的开发者才需要执行该命令。六、结语erts/autoconf是 Erlang/OTP 构建体系中的一个兼容性镜像目录它的文件全部来自 make/autoconf 主目录由 otp_build 的update_configure子命令自动同步分发且已被官方标记为最终将移除。理解这一目录的关键在于认清主文件—副本的关系日常开发与外部脚本都应优先使用$ERL_TOP/make/autoconf而erts/autoconf只是过渡期的向后兼容措施。本文所涉及的更新命令、版本约束与源码调用链均可直接在 otp_build、make/autoconf/otp.m4 与 configure.src 中逐一验证。【免费下载链接】otpErlang/OTP项目地址: https://gitcode.com/gh_mirrors/ot/otp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考