LWN:让Autoconf重焕生机!

关注了就能看到更多这么棒的文章哦~

Rejuvenating Autoconf

October 23, 2020
This article was contributed by Sumana Harihareswara
DeepL assisted translation
https://lwn.net/Articles/834682/

GNU Autoconf,是一款广泛使用的编译工具,尤其有利于与各种 Unix 兼容。自 2012 年最后一个版本发布以来,已经积累了许多改进,而且还有一些补丁在等待 review。虽然很多项目已经转投其他编译系统了,但人们仍然对 Autoconf 存有兴趣。现在,一个小团队(关联信息声明:我也在这个团队内)正在为它重新注入活力,我们正努力完成一些延迟了的维护工作,以及代码 review 工作。目前已经发布了一个可供测试的 beta 版本,新的稳定版将在 11 月初发布,感兴趣的人可以在此基础上进一步更新 GNU 构建系统(也就是 Autotools)中的其他部分。

A widely used default

GNU Autoconf 是一个用于生成 configure 脚本的工具,用来在 POSIX 系统上对软件进行构建(build)、安装(install)和打包(package)。它是 GNU Build System 的核心组成部分。当用户在命令行上通过编译源代码来安装一个软件包时,他们通常会被要求执行下面的命令:。

$ ./configure; make; make install

这些步骤主要做以下工作:

  • configure:检测系统具有的功能来确保是否满足移植条件,准备、生成需要的文件(包括 makefile)和目录,等等。

  • make:使用 makefile 作为依据来构建软件包,执行必要的编译步骤。

  • make install: 将构建生成的二进制文件和其他需要的文件放置在适当的位置

configure 是一个移植性很好的 shell 脚本,需要能跨平台执行。手工编写 configure 脚本可能会很繁琐困难,因此 Autoconf 帮助让这一过程能自动化。软件开发人员编写一个 configure.ac 文件,指定软件要求系统具备的功能(例如 "是否安装了 X Windows System,如果是,安装在哪里了?")。每一个系统功能的检测都是用 GNU M4 语言编写的宏。Autoconf 自带了开发者可能需要的许多宏,还有一个库实现了许多额外的宏("autoconf-archive"),提供了更多的宏。

因此,通常来说,一个程序员想要发布用 GNU Build System 构建的代码,只需要在 configure.ac 中写一点 M4,并且很可能只需要使用一两个来自 autoconf-archive 的额外的宏就够了。如果他们需要 configure 来检测一个没有现成的宏可以进行检测的系统功能,那么他们确实需要学习更多的 M4 语言知识。

Autoconf 内置了对各种编译语言的支持。C, C++, Objective C, Objective C++, Fortran, Erlang, 还有 Go。更关键的是,它在执行特征检测时会根据各种 POSIX 平台的特点来进行。如果你要构建的新软件没有什么神秘依赖关系,而你的用户都在比较现代的 Linuxes 或者 FreeBSD 环境中,或者你想编写 Ninja 的构建文件,也许你使用 CMake、SCons 或 Meson 这样的替代方案可能更加合适。事实上,多年来许多项目已经不再使用 GNU 构建系统,包括 GTK+和 KDE 这样的项目。多年来,关于 GNU 编译系统缓慢、复杂和难以使用的抱怨,一直在被人们提起( LWN 的评论中也总有人这么说)。然而,如果你的客户需要能够在 Solaris、AIX、HP-UX、IRIX 以及所有 BSD 变种上编译出一个共享库,那么 Autoconf 就很适合了。

From 1991 to the present

Autoconf 成立于 1991 年,后续的历史就记录在其手册和《The GNU Project Build Tools》一书中了。在 20 世纪 90 年代和 2000 年初,它主要是在弥合那些不断增加的 Unix 变种之间的差异。Autoconf 最后一次大改动是在 2001 年,从 2.13 版本跳转到 2.50 版本,这个版本导致许多现有的 configure 脚本无法使用,所以后续几个小版本进行了修复。2.50 版本对包括 autoupdate 在内的几个组件进行了广泛的整改,并改变了交叉编译的默认值。这是一个具有破坏性的版本,以至于一些用户仍然在使用 2.13,从而避免旧脚本的移植工作。

然而,近几年来,Autoconf 渐渐变得没那么热门了。Linux 的崛起,使得开发者开始忽视各种 Unix 之间的可移植性了。而 GNU Build System 在 Windows 上的集成也不是很好用,所以无法帮助那些需要移植软件到三大桌面操作系统的开发者。但是,旧的、更复杂的项目包含了已经依赖于 Autoconf 的旧代码,要是将其转换为 Autoconf 的话会耗费时间,也可能引入新问题。此外,那些竞争对手也不能涵盖 Autoconf 能搞定的所有细节场景。

使用自己的 package management 管理工具的这些语言不断兴起,包括 Python、Perl、Go 和 Rust 等,这意味着编写一种语言的代码库的开发人员完全可以避免使用系统级的构建工具。另一方面,如果你正在编写结合了 C++、Fortran、Python、Perl 和 Erlang 的软件,GNU Build 系统可以让这些多语言的软件项目很好地结合起来。比起 setup.py,GNU 编译系统更不依赖特定的语言,你可以用内置的宏加上 autoconf-archive 包来指定"我需要能够使用 2011 年的 C++方言,我需要安装这个特定的 Python 模块"这类特定需求。

GNU Build System 的用户需要稳定性、多语言编译和跨语言的兼容性,因此 Autoconf 在 2.50 后的版本中进行了渐进式的改进和 bug 修复来实现这些目标。自 2012 年以来,Autoconf 的用户一直使用 2.69 版本,后续一直没有稳定版本发布出来。然而,开发并没有停止,仍在不断有工作提交到 Git 仓库。用户还在使用 autoconf-patches 邮件列表和 Savannah 系统提交 patch。据我们估计,截至 2020 年中期,有数百个这样的补丁在等待 review。(现在少了,后面我们会说到为什么。)维护者 Eric Blake 一直打算发布一个新版本,但一直没有时间。正如他在 2016 年所说。"最多的时间耗费在挖掘邮件历史,以确保提出的所有仍然有用的补丁都已被合入"。

Fresh momentum and work in progress

我对 Autoconf 的参与是从 Keith Bostic 在一月份给 autoconf 邮件列表发邮件时开始的,他问:"是否有人愿意提供有偿服务,来帮忙给 autoconf 发布一个新版本?" Autoconf 的贡献者 Zack Weinberg 将这个信息转发给了我。

Bostic 对 Autoconf 的未来很感兴趣,因为他在一个项目使用了 Autoconf。他资助 Weinberg 和我来评估还剩多少工作。在我们进行的过程中,我们与 Autoconf 的维护者(包括 Blake 和 Paul Eggert)讨论过,他们同意我们可以做接下来的发布工作。然后,从几个月前开始,Bostic 以及 Bloomberg 和 FSF 的 GNU Toolchain Fund 一起进一步资助了我们的工作,这样我们就可以努力争取在 11 月初发布 2.70 版本。

Weinberg 在 7 月发布了一个可测试的 beta 版(尽管这是 2.70 的 beta 版,但 beta 版的 tag 名字是 2.69b),并在 9 月发布了第二个 beta 版 2.69c。我们现在已经完成了这个资助下的项目的部分目标:

  • 与其他用户一起,我们已经开始用真实的一些复杂项目中的 Autoconf 脚本来测试即将发布的版本,但还没有完成对 Emacs、GCC 和 CPython 的测试。

  • 由于 Autoconf 目前还没有持续集成(CI)支持,我们将搭建合适的 CI 系统来发现 regression 问题,至少在 Linux 上。可能会用 sourcehut。

  • 我们已经得到了数百个各种各样的补丁和 bug 报告中的一小部分,所以 Autoconf 的贡献者们可以对我们积压的工作进行优先级排序和评估。不幸的是,我们没有足够的时间,目前整理出来的补丁和 bug 报告哪怕连一半都不到。

  • 我们已经 review 了几个高优先级的补丁,这些补丁已经被下游的发行版提供方(如 Arch Linux 和 Yocto Project)包含了,我们将这些补丁也合并到了 mainline 版本库中。

  • 我们已经开始与现有的维护者、贡献者和用户合作,让项目走上一条更可持续的道路。

幸运的是,这些活动在现有维护者和贡献者的测试和 review 的帮助下,加上新的志愿者的帮助下,取得了更多的进展。而新的 review 和测试也推进了相关工具的修复,比如修复了 portability library Gnulib。

Speedups, bugfixes and stricter parsing

2.70 版本的发布说明和 NEWS 文件,还正在撰写中,其中会介绍一些性能提升,几个小的新功能,以及许多将在新版本中修复的 bug。仅仅是这些 bug 修复,就是一个吸引人升级的理由。例如,由新的 Autoconf 生成的配置脚本将能够正确地与当前版本的 C 和 C++编译器一起配合工作,这些脚本的内容不再依赖于源代码 tree 之外的东西(这对于构建的可重复性 reproducibility 很重要)。

不幸的是,2.70 中包含了一些无法与 2.69 兼容的地方。特别是,Autoconf 现在对 M4 引号语法更加严格了(这是 Autoconf 用户常年感到头疼的问题),而且一些宏没有像以前那样执行那么多的检查,虽然这加快了配置的过程,但可能会破坏例如“假设某个 shell 变量已经被设置而没有实际调用设置它的宏”的 configure 脚本。此外,现在有更多的 configure 脚本需要辅助脚本 config.sub、config.guess 和 install-sh。(完整的列表请参见 release note)。

维护着复杂的 Autoconf 脚本的开发者会发现很需要对这个 beta 版进行测试,并且非常值得将遇到的任何问题报告给 Autoconf 邮件列表。

Beyond this release: future resilience

在 10 月和 11 月初,Weinberg 和我很可能会用完我们收到的最后一笔资金。我们打算募集更多的资金,并让更多的企业贡献者来承诺会帮助测试和代码 review 等等。毕竟,一个巨大的悬而未决的问题是:谁会承诺来协调并负责发布 Autoconf 2.71?目前看起来下一次比较合理的发布时间是在 12-18 个月后。在 Autoconf 2.50 之后,不断有用户报告问题,而贡献者们也在接下来的几个版本中进行了修复。如果我们有一个人能有动力来分发这些 bug,并优先处理和 review 补丁,那么再次发布一个版本会是很有意义的。尤其是在 2.70 版本之后肯定会有新的 bug 报告出来,包括新引入的、在这个 beta 版本中没有被发现的 bug。

此外,还有一个悬而未决的问题,那就是由谁来整理大量积压的补丁和错误报告,以便维护者能够正确地评估、确定优先级和分配工作。即使我们完成了已经收到资金的工作,仍然会有许多 bug 滞留在各种邮件列表和/或补丁集中,这些补丁目前由各个发行版(如 OpenEmbedded 和 BSDs)携带着,但还没有被合并回 mainline。把所有这些补丁放到 Savannah 或者新的 GNU forge 中,将对贡献者有所帮助。如果能在多个操作系统和环境中进行适当的 CI 那也会很有帮助。将所有提交的补丁集中到一个 forge 中,也将帮助下游的发行版提供方挑选特定的 bug fix patch,在 Autoconf 发布新版本之前就可以用上。

Autoconf 之所以能够重振旗鼓,离不开赞助商的资助。未来几个月的讨论将揭示他们以及其他企业用户是否还能继续投资,以及意愿有多强烈,这样才能保持 Autoconf 的稳定。当然,这并不是自由软件所一来的唯一一个老旧软件,也不是唯一一个遗留有大量维护工作需要做的软件。还有一些密切相关的项目也可以重新焕发活力,Automake 就是一个例子。Libtool 可以被废弃了,并把它的功能加入到更快更强大的 Automake 中去。

无论如何,如果能成为现实的话,会有助于帮助突破瓶颈,让开源生态中广泛使用、甚至是至关重要的一部分,能够继续给用户提供这八年来所积累的改进,从而帮助用户受益。并且让 Autoconf 处于了更好的状态,使得未来的发布周期也能更好地进行。

[感谢 Zack Weinberg 对本文的审阅。]

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作~

长按下面二维码关注,关注 LWN 深度文章以及开源社区的各种新近言论~

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:大白 设计师:CSDN官方博客 返回首页
评论
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值