autotools可以创建多平台makefile吗

Question

我有一个插件项目，我已经开发了几年，该插件可以与[主应用程序版本、第 3 方库版本、32 位与 64 位]的多种组合一起使用。 有没有一种（干净的）方法使用 autotools 创建一个构建所有版本插件的 makefile。

据我通过浏览 autotools 文档得知，最接近我想要的就是拥有该项目的 N 个独立副本，每个副本都有自己的 makefile。 这对于测试和开发来说似乎有点次优，因为（a）我需要在所有不同的副本之间不断传播代码更​​改，并且（b）多次复制项目会浪费大量空间。 有没有更好的办法？

编辑：

我已经滚动自己的解决方案一段时间了，我有一个精美的 makefile 和一些 perl 脚本来寻找各种第 3 方库版本等。因此，我对其他库持开放态度非自动工具解决方案。 对于其他构建工具，我希望最终用户能够非常轻松地安装它们。 这些工具还需要足够智能，能够轻松地找到各种第 3 方库和标头。 我主要是在寻找一种 Linux 解决方案，但如果一个也适用于 Windows 和/或 Mac 的解决方案将是一个额外的好处。

Answer 1

如果你的问题是：

我可以在某些机器 A 上使用自动工具来创建一个可在所有其他机器上运行的通用 makefile 吗？

那么答案是“否”。 自动工具甚至不假装试图做到这一点。 它们被设计为包含可移植代码，这些代码将确定如何在目标机器上创建可用的 makefile。

如果你的问题是：

我可以使用自动工具来配置需要在不同机器上运行的软件，以及我的插件所使用的主要软件的不同版本以及各种第三方库，更不用说 32 位与 64 位问题了？

那么答案是“是”。 自动工具旨在能够做到这一点。 此外，它们还可以在 Unix、Linux、MacOS X、BSD 上运行。

我有一个程序，SQLCMD（它比 Microsoft 的同名程序早十多年），它与 IBM Informix 数据库配合使用。 它检测安装的客户端软件（称为 IBM Informix ESQL/C，IBM Informix ClientSDK 或 CSDK 的一部分）的版本，以及它是 32 位还是 64 位。 它还检测安装的软件版本，并根据支持产品中的可用功能调整其功能。 它支持已发布约 17 年的版本。 它是自动配置的——我必须为 Informix 功能和其他一些小玩意（高分辨率计时、/dev/stdin 的存在等）编写一些 autoconf 宏。 但这是可行的。

另一方面，我不会尝试发布一个适合所有客户机器和环境的 makefile； 有太多的可能性使这种做法变得不明智。 但自动工具会为我（和我的用户）处理细节。 他们所做的就是：

./configure

这比弄清楚如何编辑 makefile 更容易。 （哦，在前 10 年里，程序是手动配置的。尽管我设置了相当好的默认值，但人们很难做到这一点。这就是我转向自动配置的原因：它使人来安装。）

---

福兹先生评论道：

我想要介于两者之间的东西。 在我的例子中，客户将在同一台计算机上使用同一基础应用程序的多个版本和位数。 我不担心交叉编译，例如在 Linux 上构建 Windows 二进制文件。

您是否需要为 32 位和 64 位版本单独构建插件？ （我认为是的 - 但你可能会让我感到惊讶。）因此，你需要为用户提供一种机制

./configure --use-tppkg=/opt/tp/pkg32-1.0.3

（其中 tppkg 是第三方包的代码，并且位置可由用户指定。）但是，记住可用性：用户提供的此类选项越少越好； 与此相反，不要对应该可选的内容进行硬编码，例如安装位置。 无论如何，请查看默认位置 - 这很好。 并默认你找到的东西的细节。 也许如果您同时找到 32 位和 64 位版本，那么您应该构建两者 - 但这需要仔细构建。 您始终可以回显“正在检查 TP 包...”并指出您发现了什么以及在哪里找到它。 然后安装程序可以更改选项。 确保在“./configure --help”中记录了选项的内容； 这是标准的自动工具实践。

但不要做任何互动的事情； 配置脚本应该运行，并报告它的作用。 Perl Configure 脚本（注意大写字母 - 它是一个完全独立的自动配置系统）是剩下的少数几个密集交互的配置系统之一（这可能主要是因为它的遗产；如果重新开始，它很可能是非交互式的）。 与非交互式系统相比，此类系统的配置更加麻烦。

交叉编译很难。 我从来不需要这样做，谢天谢地。

---

福兹先生还评论道：

感谢您的额外评论。 我正在寻找类似的东西：

./configure --use-tppkg=/opt/tp/pkg32-1.0.3 --use-tppkg=/opt/tp/pkg64-1.1.2

它将在一个 makefile 中为当前平台创建 32 位和 64 位目标。

嗯，我确信这是可以做到的； 我不太确定与两次单独的配置运行（其间进行了完整的重建）相比是否值得这样做。 您可能想要使用：

./configure --use-tppkg32=/opt/tp/pkg32-1.0.3 --use-tppkg64=/opt/tp/pkg64-1.1.2

这表示两个单独的目录。 您必须决定如何进行构建，但大概您有两个子目录，例如“obj-32”和“obj-64< /code>' 用于存储单独的目标文件集。 您还可以按照以下方式安排您的 makefile：

FLAGS_32 = ...32-bit compiler options...
FLAGS_64 = ...64-bit compiler options...

TPPKG32DIR = @TPPKG32DIR@
TPPKG64DIR = @TPPKG64DIR@

OBJ32DIR = obj-32
OBJ64DIR = obj-64

BUILD_32 = @BUILD_32@
BUILD_64 = @BUILD_64@

TPPKGDIR =
OBJDIR   =
FLAGS    =

all:    ${BUILD_32} ${BUILD_64}

build_32:
    ${MAKE} TPPKGDIR=${TPPKG32DIR} OBJDIR=${OBJ32DIR} FLAGS=${FLAGS_32} build

build_64:
    ${MAKE} TPPKGDIR=${TPPKG64DIR} OBJDIR=${OBJ64DIR} FLAGS=${FLAGS_64} build

build:  ${OBJDIR}/plugin.so

这假设该插件将是一个共享对象。 这里的想法是，自动工具将检测第三方软件包的 32 位或 64 位安装，然后进行替换。 如果需要 32 位包，则 BUILD_32 宏将设置为 build_32，否则留空； BUILD_64 宏的处理方式类似。

当用户运行“make all”时，它将首先构建 build_32 目标，然后构建 build_64 目标。 要构建 build_32 目标，它将重新运行 make 并配置 32 位构建的标志。 同样，要构建 build_64 目标，它将重新运行 make 并配置 64 位构建的标志。 重要的是，受 32 位与 64 位构建影响的所有标志都在 make 的递归调用上设置，并且仔细编写构建对象和库的规则 - 例如，将源代码编译为对象的规则必须小心，将对象文件放置在正确的对象目录中 - 例如，使用 GCC，您可以指定（在 .co 规则中）：

${CC} ${CFLAGS} -o ${OBJDIR}/$*.o -c $*.c

宏 CFLAGS 将包括处理位的 ${FLAGS} 值（例如，FLAGS_32 = -m32 和 FLAGS_64 = -m64，因此在构建 32 位版本时，FLAGS = -m32将包含在CFLAGS`宏中。

自动工具中的剩余问题是如何确定 32 位和 64 位标志。但是，我希望（没有研究过）您可以使用自动工具套件中的标准设施来完成它，

除非您自己创建一个仔细（甚至无情）的对称 makefile，否则它不会。工作可靠。

Answer 2

据我所知，你不能这样做。 但是，您是否被自动工具困住了？ 既不是 CMake 也不是 SCons 一个选项？

Answer 3

我们尝试过，但行不通！ 所以我们现在使用SCons。

有关此主题的一些文章：1 和 2

编辑：
一些我喜欢 SCons 的小例子：

env.ParseConfig('pkg-config --cflags --libs glib-2.0')

使用这行代码将 GLib 添加到编译环境 (env)。 不要忘记用户指南学习 SCons 真是太棒了（你真的不必了解 Python！）。 对于最终用户，您可以尝试使用 SCons 和 PyInstaller 或类似的东西。

与 make 相比，您使用的是 Python，这是一种完整的编程语言！ 记住这一点，你就可以做任何事情（或多或少）。

Answer 4

您是否考虑过使用具有多个构建目录的单个项目？
如果您的 automake 项目以正确的方式实现（即：不像 gcc），则

可以执行以下操作：

mkdir build1 build2 build3
cd build1
../configure $(YOUR_OPTIONS)
cd build2
../configure $(YOUR_OPTIONS2)
[...]

您可以传递不同的配置参数，例如包含目录和编译器（交叉编译器，即）。

然后你甚至可以通过运行在一个 make 调用中运行它

make -C build1 -C build2 -C build3