☰

自动工具：代码片段 (AM_MAINTAINER_MODE)

tag-icon • tag-icon autotools
自动工具：代码片段 (AM_MAINTAINER_MODE)

至于这段代码片段：

AM_MAINTAINER_MODE
if test "x$enable_maintainer_mode" = xyes; then
    AC_PATH_PROG(PERL,perl)
    if test -z "$PERL"; then
        AC_MSG_ERROR([perl not found])
    fi
fi

# This should be checked before AC_PROG_CC
if test "x$CFLAGS" = x; then
    default_CFLAGS=yes
fi

if test "x$host_cpu" = xx86_64; then
    CFLAGS="-m32 $CFLAGS"
fi

我找不到有关正在测试的三个变量（x$enable_maintainer_mode、x$CFLAGS、x$host_cpu）的任何信息。这些变量是执行宏AM_MAINTAINER_MODE后生成的吗？如果是这样，我在哪里可以找到有关它们的更多信息？

另外，AM_MAINTAINER_MODE 模式的目的是什么？

据我了解，默认情况下它是禁用的：

  • 如果用户运行“configure”并且不满足所有依赖项（Automake 版本、工具、库等），它将终止并且不会进一步继续。
  • 如果用户运行“configure”并且满足所有依赖关系，它将创建并运行 config.status 脚本，该脚本生成“make”文件
  • 用户可以使用 –enable-maintainer-mode 选项覆盖此设置。这将允许他们修改不同的 Autotool 文件（例如 configure.ac、Makefile.am），并且构建系统将尝试重新生成需要更新的文件以反映这些更改（Autotools 将查找任何过时的文件并更新它们）因此）。

我明白为什么禁用此模式可能更好。您有什么理由想要启用此功能？

答案1

背后的总体思想AM_MAINTAINER_MODE是两种处理项目的方式：一种是用户“仅”想要构建和安装项目（使用基于源的工件进行安装），并且可能对项目的代码进行更改而不触及其构建系统，另一个用户希望在项目中的任何位置所做的任何更改都反映在构建输出中。

因此，当AM_MAINTAINER_MODE禁用时，即使相应的源文件（ 等）发生更改，诸如 等的文件也configure不会重建。这样做的优点是，它避免了要求用户拥有必要的构建工具，并且避免了必须处理工具本身的更改（询问任何尝试使用当前自动工具重建旧的复杂项目的人）。缺点是对某些文件所做的更改会被忽略，因此用户需要确保手动更新所有适当的文件...（这就是为什么您在互联网上看到的许多补丁都包含对Makefile.inconfigure.acMakefile.amMakefile.am 和 Makefile.in有时甚至Makefile。）

启用的优点AM_MAINTAINER_MODE是对文件所做的所有更改都会被考虑在内。缺点是用户需要知道真正的源文件是什么：如果您对维护者模式进行更改Makefile.in并重建，您可能会丢失更改！

现在的普遍共识似乎是从真实来源重建更好，而维护者模式并不是一个好主意。 （汽车制造商常见问题解答提供参考。）这并不意味着所有用户突然需要拥有重建所需的所有工具一切;如果项目在其发布工件中提供生成的文件，只要时间戳良好，那么用户就不需要重建它们。

答案2

这里的变量是添加了“x”的 shell 变量。

当您传递选项 --enable-maintainer-mode 进行配置时，x$enable_maintainer_mode 将设置为 xyes；当您传递选项 --disable-maintainer-mode 进行配置时，x$enable_maintainer_mode 将设置为 xno。否则，变量将为“x”。

变量 CFLAGS 可以通过 ./configure CFLAGS='compiler flag options' 设置。否则，如果未设置任何内容，则 default_CFLAGS=yes。 x$host_cpu 可以从 AC_CANONICAL_HOST 宏中获取。这里有一个相关的关联用于 host_cpu 和 AC_CANONICAL_HOST 宏调用。

相关内容