linux之autoconf(1)基础介绍

2023-12-14 08:40:37

Linux之autoconf(1)基础介绍

Author：Onceday Date：2023年2023年12月10日

漫漫长路，才刚刚开始…

本文主要内容翻译自Autoconf官方文档，仅供学习交流之用。

全系列文章请查看专栏: buildroot编译框架_Once_day的博客-CSDN博客。

参考文档：

文章目录

1. 概述
1.1 介绍

Autoconf 是一个为了生成可以自动配置的源代码包而设计的工具。它的主要目的是创建一个脚本，通常叫做 configure 脚本，它可以在软件安装前检测目标系统的特性并自动调整软件以适应这些系统。Autoconf 是自由软件基金会的 GNU 项目的一部分，广泛应用于 Unix-like 系统上的开源软件中。

Autoconf 使用 M4 宏处理语言生成 configure 脚本。软件开发者编写一个名为 configure.ac 或 configure.in 的模板文件，其中包含了检测特定功能，库文件，编译器选项等的宏调用。Autoconf 处理这个模板文件，并创建一个可移植的 shell 脚本 configure。

主要功能包括：

  • 检测系统特性：检查编译器选项、库函数、系统服务等是否存在。
  • 跨平台支持：通过生成的脚本可以适应多种不同的操作系统和环境。
  • 生成 Makefile：通常与 Automake 结合使用，根据 Makefile.am 模板文件生成 Makefile.in，然后 configure 脚本会进一步生成最终的 Makefile。
  • 用户友好：生成的配置脚本通常支持像 --prefix 等标准配置选项，以及检测过程中的有用提示和错误信息。

使用 Autoconf 的基本步骤如下：

  1. 编写 configure.ac：定义宏和测试，指定生成的文件等。
  2. 运行 autoconf：生成 configure 脚本。
  3. 分发源代码：将源代码包含 configure 脚本一起分发。
  4. 构建软件：用户下载源代码包后，运行 configure 脚本并接着使用 make 构建软件。

Autoconf 通常与其他工具一起使用，如 Automake（生成规范的 Makefile 文件）和 Libtool（处理共享库的生成）。这些工具的结合使用构成了一个强大的自动化构建系统，它可以处理许多编译和安装软件时可能出现的复杂性。

Autoconf解决了一个重要的问题，可靠地发现特定于系统的构建和运行时信息，但这只是可移植软件开发难题的一部分。为此，GNU项目开发了一套集成的实用程序来完成Autoconf启动的工作: GNU构建系统，其最重要的组件是Autoconf、Automake和Libtool。

GNU构建系统，有时也被称为 Autotools，是一套由 GNU 项目开发的编程工具，它们的目的是协助创建跨平台的软件包。这套工具包括 Autoconf, Automake, Libtool 和一些其他辅助工具，它们各自承担不同的职责，协同工作以简化构建过程。

整体性学习Autotools使用和流程，可以参考下面两本书(都可以免费查看):

1.2 Autotools之Automake介绍

make的普遍性意味着makefile几乎是分发软件自动构建规则的唯一可行方法，但很快就会遇到它的众多限制。它缺乏对自动依赖跟踪、子目录中的递归构建、可靠的时间戳(例如，对于网络文件系统)等等的支持，这意味着开发人员必须为每个项目痛苦地(通常是不正确的)重新发明轮子。

由于make在许多系统上的特性，可移植性是非常重要的。最重要的是，实现用户期望的许多标准目标(make install、make distclean、make uninstall等)所需的手工劳动。当然，由于使用的是Autoconf，因此还必须在Makefile.in中插入重复的代码。以识别CC、CFLAGS和configure提供的其他替换，从这里开始，Automake便步入了这个混乱的世界。

Automake允许在Makefile.am中指定构建需求，使用比普通makefile更简单和更强大的语法生成一个可移植的makefile.in，并在Autoconf中使用。例如，使用Makefile.am构建和安装一个简单的“Hello world”程序，如下所示:

bin_PROGRAMS = hello
hello_SOURCES = hello.c

生成的Makefile.in(大概400行代码)自动支持所有标准目标、Autoconf提供的替换、自动依赖项跟踪、VPATH构建等功能。Make构建hello程序，make install将其安装在/usr/local/bin中(如果不是/usr/local，也可以是配置的前缀路径)。

对于较大的包(特别是带有子目录的包)，Automake的好处会增加，但即使对于小程序，增加的便利性和可移植性也是非常重要的。

1.3 Autotools之Gnulib介绍

GNU软件可以在许多不同类型的系统上运行。虽然主要目标是为GNU系统编写软件，但许多用户和开发人员是通过他们已经在使用的系统被介绍给我们的。

Gnulib是公共GNU代码的中心位置，旨在在自由软件包之间共享。它的组件通常在源代码级别共享，而不是作为构建、安装和链接的库。其思想是将文件从Gnulib复制到您自己的源代码树中。没有分发包，开发者只需要从存储库中获取源模块。源文件可在网上，在各种许可证，主要是 GNU GPL 或 GNU LGPL。

Gnulib模块通常包含C源代码以及用于配置源代码的Autoconf宏。例如，Gnulib的stdalign模块实现了一个几乎符合C11的stdalin.h标准头文件，即使在缺乏stdalin .h的老式主机上也是如此。该模块包含替换头文件的源文件，以及一个Autoconf宏，该宏安排在老式系统上使用替换头文件。

1.4 Autotools之Libtool介绍

通常，人们不仅希望构建程序，还希望构建库，以便其他程序可以从您的劳动成果中受益。理想情况下，人们希望生成共享的(动态链接的)库，它可以被多个程序使用，而不会在磁盘或内存中复制，并且可以独立于链接的程序进行更新。然而，可移植地生成共享库是一场噩梦：每个系统都有自己不兼容的工具、编译器标志和魔法咒语。幸运的是，GNU提供了一个解决方案: Libtool。

Libtool可以处理构建共享库的所有需求，并且目前似乎是实现可移植性的唯一方法。它还处理许多其他令人头痛的问题，例如:Make规则与共享库的变量后缀的交互，在超级用户安装共享库之前与它们可靠地链接，以及提供一致的版本控制系统(以便可以在不破坏二进制兼容性的情况下安装或升级库的不同版本)。虽然Libtool，像Autoconf一样，可以在没有Automake的情况下使用。但它与Automake结合使用非常简单：Libtool在需要共享库时自动使用，而不需要知道它的语法。

2. Autotools使用流程

本处流程示例参考知乎问答: 感觉autoconf真不太好用，有何替代方案？ - 知乎 (zhihu.com)，其中宅学部落-王利涛(嵌入式C语言自我修养)的回复，欲了解详情，请访问以上链接，特别是原作者王利涛的文章。

2.1 Autotools工具、项目、库文件关系图

在这里插入图片描述

虽然上面的图看起来非常复杂，但是Autotools的发展并非是一蹴而就，其中有则漫长的岁月和时间积累，是在软件开发过程中不断解决问题的积累。图中不同颜色代表了不同的工具作用，下面按照发展历程总结它们的出现原因。

  • Makefile时代，这是最早期的情况，Makefile都是手写。现在的程序员，更多只是要求能读懂Makefile，毕竟如cmake和meson等现代化构建工具，比起Makefile，好用多了。

    手写Makefile时，只需要Makefile、源代码，便可以编译出目标执行程序，中间所有Autotools步骤都不需要，但是随着Unix类系统越来越复杂，Makefile也变得异常复杂，且难以阅读和调试(真的很难调试)。另外一方面，没有足够的经验(对于绝大部分人都是如此)，Makefile很难符合标准，因此难以移植，往往换个项目和平台，又要改一堆内容。

    因此，后来出现了configure脚本，先用脚本生成配置变量，再调用Makefile，脚本比起Makefile，更好调试。

  • 随着linux操作系统的出现，Unix系统类别更多，不同系统之间差异越来越大，为了减少程序员在configure脚本上的无用功(多半是重复操作)，因此出现了Autoconf工具，用于自动生成configure脚本。

    对于自动生成configure脚本，其代码量依旧不少，但是属于固定模板代码，不容易出错(相对于人工编写而言)。用户仍然可以定义项目特定的宏变量参数，放在configure.ac文件里，甚至于configure.ac文件都可以通过autoscan自动扫描项目文件来生成。

  • 随着项目的庞大，Makefile手工编写也越来越复杂，因此除了使用autoconf自动生成配置变量之外，也开发出了automake来自动生成标准的Makefile文件。

    用户只需手工编写一个makefile.am文件，定义生成目标和需要编译的源文件，然后automake便可以自动生成Makefile.in文件，其中包含程序编译、链接的基本规则。再通过configure脚本配置一下，便可以在当前特定平台上执行。

    Makefile.in是面向于通用平台的Makefile文件，在autoconf生成特定平台的配置脚本configure之后，通过该配置脚本，便可以生成特定平台的Makefile文件(实现一些标准变量定义，以符合特定平台的需求)。

  • Automake和autoconf都会自行定义一些宏变量，这些宏变量需要进行互通，因此便采用M4宏语言实现，即aclocal.m4文件，其中还包含用户项目自定义的宏参数。

    aclocal工具可以自行收集automake和autoconf以及用户自定义宏放在aclocal.m4文件里面，这样就无须手动复制这些宏到M4文件中。

    最终还有一个autoheader工具，该工具可以把configure.ac中的宏配置转换为C语言的#define宏，这样在代码里的宏能根据实际平台的值进行对应操作。configure脚本最终会生成一个config.h文件，很多配置框架都有类似的文件，比如kconfig这种。

  • 随着动态库/静态库越来越多，之间差异也逐渐增大，包括符号版本控制等。为此，出现了libtool工具，对动态库进行抽象，统一生成.la的形式，这样就可以跨平台支持(告诉Makefile如何操作)。

附录
附录: Autotools介绍

(1) M4 宏处理器，M4 是一种通用的宏处理器，是一种用来在文本文件中定义和扩展宏（即预设的文本片段）的工具。它是 Autoconf 的核心组件，因为 Autoconf 的模板文件(configure.ac 或 configure.in)是用 M4 宏语言编写的。M4 特别适用于生成代码和自动化文本替换，也可以用来生成 HTML 或 XML 文件。M4 能处理复杂的文本替换和序列，支持条件语句、循环和递归宏调用等。

(2) Automake， Automake 是一个生成 Makefile 文件的工具，它使得管理 Makefile 文件更加简单。它与 Autoconf 紧密集成，使用者仅需编写一个相对简单的 Makefile.am 文件，其中包括了程序需要的源文件和编译指令。然后 Automake 会生成适用于不同平台的 Makefile.in，这个文件随后会被 Autoconf 生成的 configure 脚本处理，最终生成用于实际编译软件的 Makefile。

(3) Libtool，Libtool 是一个用于统一库文件编译的脚本。在 Unix-like 系统中，共享库和静态库的处理方式往往因操作系统的不同而有很大差异。Libtool 抽象了这些差异，允许开发者以统一的方式创建可移植的共享库。它与 Autoconf 和 Automake 结合使用，使得开发者可以忽略库文件编译时的复杂性。

这三个工具经常一起使用，创建了一个强大的构建系统：

  1. Autoconf (configure.ac): 生成配置脚本（configure），用于检测系统特性并配置软件包以适合当前系统。
  2. Automake (Makefile.am): 生成 Makefile.in 模板，定义了如何编译和安装程序。
  3. Libtool: 处理库文件的创建和使用。

当开发者准备好了 configure.ac 和 Makefile.am 文件后，他们会按照下面的步骤使用这些工具：

  • 使用 autoconf 生成 configure 脚本。
  • 使用 automake 生成 Makefile.in。
  • 在构建时，运行 configure 脚本，它会检测系统特性并使用来自 Makefile.in 的指令生成 Makefile。
  • 最后，使用 make 命令来构建和安装软件。

这个过程隐藏了许多平台差异，使得开发者可以专注于代码本身，而不必为各种系统上的构建问题操心。

附录: Gnulib介绍

Gnulib, 通常称为 “GNU Portability Library”, 是一个由宏、脚本和代码组成的库，用于提高各种 GNU 和其他系统上的软件包的可移植性。Gnulib 包含了一系列的模块，每个模块都提供一种功能，比如提供标准 C 库中不存在的函数，或者提供一些平台特有的功能的可移植替代实现。

  • 可移植性: Gnulib 的主要目标是解决各种操作系统之间的兼容性问题，特别是 Unix-like 系统和类似于 GNU 系统的环境。
  • 模块化: 它包含了许多独立的模块，每个模块都可以单独使用。这些模块通常包括函数、宏、类型定义和其他可以在多个项目之间共享的代码。
  • 自动化工具: Gnulib 配有一个脚本，可以自动将所选择的模块集成到你的项目中。
  • 广泛的功能: 它包括了大量的功能，从基本的字符串处理和文件操作到更高级的系统服务和抽象。
  • 与 Autotools 的集成: Gnulib 设计为与 GNU 构建系统（Autotools）紧密集成，方便在使用 Autoconf 和 Automake 的项目中利用 Gnulib。

使用 Gnulib 通常涉及以下步骤：

  1. 选择模块: 项目维护者首先确定他们的软件需要哪些 Gnulib 模块来解决可移植性问题或补充缺失功能。
  2. 集成模块: 使用 Gnulib 提供的 gnulib-tool 脚本，将这些模块的源代码和其他必要文件复制或链接到主项目中。
  3. 配置构建系统: 更新项目的 configure.ac 和 Makefile.am 文件（如果使用 Autotools），以便在构建过程中包含和编译 Gnulib 模块。

与其他标准库（如 glibc）不同，Gnulib 更侧重于跨平台的可移植性而不是系统特定的性能优化。此外，Gnulib 不是作为一个共享库来安装的，而是作为源代码直接集成到你的项目中，这意味着它不会引入运行时依赖。

Gnulib 是许多 GNU 软件和其他开源项目的基础设施组件，因为它解决了许多在广泛的环境中编写可移植代码时遇到的常见问题。

附录: Gettext介绍

gettext 是一个国际化（i18n）和本地化（l10n）的工具集，它是 GNU 项目的一部分，用于使软件能够根据不同的语言和文化背景来适配其文本输出。国际化通常指的是将软件设计得能够适应多种语言的过程，而本地化是指实际适配软件到特定语言的过程。

  • 提取文本: gettext 工具可以从源代码中提取出需要翻译的字符串。
  • 编写和管理翻译: 它允许翻译人员在不改变源代码的情况下编写翻译（通常是以 .po 文件格式）。
  • 编译翻译: 翻译完成后，gettext 可以将 .po 文件编译成二进制的 .mo 文件，以便软件在运行时使用。
  • 运行时支持: gettext 运行时库支持软件在运行时查找和使用正确的翻译字符串。

在源代码中，需要翻译的字符串会被特殊的宏包围，如 gettext("Message") 或简写的 _() 宏，例如 _ ("Message")。这些宏是标记这些字符串在运行时需要被翻译的方式。

开发者使用 gettext 相关的工具来处理这些标记过的字符串：

  • xgettext: 从源代码文件中提取带有 gettext 标记的字符串，并创建 .pot（Portable Object Template）文件，这是一个包含所有待翻译文本的模板。
  • msginit: 初始化一个新的 .po（Portable Object）文件，基于 .pot 文件，为特定语言准备翻译。
  • msgmerge: 更新已有的 .po 文件，合并新的字符串变化。
  • msgfmt: 将 .po 文件编译成 .mo（Machine Object）文件，让软件可以使用翻译后的字符串。

本地化使用流程:

  1. 提取: 在开发过程中，通过 xgettext 从源代码中提取所有需要翻译的字符串。
  2. 初始化: 对于每种目标语言，使用 msginit 来初始化一个 .po 文件。
  3. 翻译: 翻译人员翻译 .po 文件中的每个字符串。
  4. 编译: 使用 msgfmt 将翻译好的 .po 文件编译成 .mo 文件。
  5. 安装和使用: 将 .mo 文件安装到系统的适当位置，软件在运行时会自动使用这些文件中的翻译字符串。

文章来源:https://blog.csdn.net/Once_day/article/details/134917187
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。