使用Autotools和替代工具的优势

Question

我有一个适中的C++项目。我想用autotools来管理它，但是发现使用复杂。

什么时候需要使用autotools？有没有（简单的）替代方案？

我想使用autotools的主要原因是它完整支持make install。有没有更简单的替代方案？

最好是Eclipse CDT支持的某种工具。

- SRobertJames

---

https://dev59.com/p3NA5IYBdhLWcg3wNa6T - Jiminion

Answer 1

对于 make install 支持，您只需要使用 automake。而一个简单的 Makefile.am 文件很容易制作：

LIBS += -lsome-lib -lsome_other_lib

bin_PROGRAMS = hello

noinst_HEADERS = some.h header.h files.h

hello_SOURCES = hello.c some.c other.c source.c file.c

就是这样了。

---

autoconf工具在你想要让程序更加跨平台时非常有用。你可以编写一个简单的脚本来测试你使用的系统头文件和系统库是否存在。如果未找到，你可以报错或者使用你包中提供的副本。

- Some programmer dude

---

哇，那很简单。外部共享库放在哪里？ - SRobertJames

@SRobertJames将它们附加到“LIBS”变量中，更新了我的示例。 - Some programmer dude

此外，libtool 值得一提；它能够轻松地解决动态和静态库的链接问题。 - DanielKO

我想补充一点，与其使用noinst_HEADERS，最好将头文件列在hello_SOURCES中。 - Brett Hale

Answer 2

对于只包含基本部分（无需依赖项，无需安装）的小型项目，包括不超过3个源代码文件，应编写Makefile：

.PHONY: all clean

all: program

clean:
    rm -f *.o

program: sourceA.o sourceB.o
    $(CXX) -o $@ $^ $(LDFLAGS)

你可以为CPPFLAGS、CFLAGS、CXXFLAGS和LDFLAGS定义变量，至少GNU make会按照预期的方式填充空白。当然，这并没有解决依赖跟踪和检查系统功能的问题。对于非平凡项目而言，与系统交互是一个常见问题：确保某些库可用，并进行安装/卸载。大多数工具在这两个方面都失败了。

以下是我有经验的一些例子：

Premake

它可以为不同的IDE（以及如果您只需要构建代码，则为Makefile）生成一致的项目文件。除此之外什么也不做（没有安装目标，没有检查库是否可用的方法）。只有在您需要为您不使用的IDE提供项目文件时才有用（例如，您使用Eclipse，其他人想在Visual Studio上编译它）。任何非平凡的任务都需要LUA脚本。

CMAKE

如果您只需要调用编译器来处理文件，那么它是可以接受的。对于几乎所有事情，您都需要记住（或复制/粘贴）一系列低级宏（形成某种编程语言）。在系统上查找库是复杂而混乱的（某些库已被创建者认可，并且具有硬编码测试以查找它们，因此您可能会很幸运）。考虑到我到目前为止必须处理的大量损坏的cmake脚本，我认为大多数人只是复制/粘贴宏而不尝试理解它。可以安装，但无法卸载。对于一些cmake脚本，您可能需要多次运行cmake，直到它生成正确的输出（例如VTK）。

SCons

似乎比CMAKE和Premake做得更好：没有宏，使用一个众所周知的编程语言（Python）来提供相当多的有用功能。在某些方面仍然失败了；指定非硬编码的安装前缀需要非平凡的努力，因为它没有内置。

Autotools

做的事情比上面提到的工具要多得多。并且大多数都很方便。有合理的默认值；一些亮点：

• AC_CHECK_LIB(foobar, function_to_check_linking) - 这会查找名为 foobar 的库，并将其放入 $LIBS 环境变量中。是的，检测库是一个重要的常见任务；如果你的工具不认为这是一项一流的用例，请放弃它。（使用 PKG_CHECK_MODULES 更方便。）

• 在 ./configure 过程中的每个操作都会记录在 config.log 中，因此您可以实际上找出出了什么问题。对于大多数其他工具，最好的情况只能得到“Boost_dir-NOTFOUND”。

• 已经内置了 make install、make uninstall（你是说，你的工具可以把东西放到我的系统上，但不能删除它们？）、make check（如果指定了 test_ 程序）、make dist-gzip（将源文件打包成 tar.gz），make distcheck（创建一个 tar.gz 并确保一切构建正确且所有测试都通过）。更好的是，它与 checkinstall 配合得很好，因此您可以从中创建和分发 .rpms 和 .debs。

• 如果需要，您可以在 automake Makefile 中混合使用传统的 Makefile 规则。

• Autotools 文件与源文件一样受到跟踪，因此如果需要，可以通过简单地调用 make 来再次生成辅助脚本和 Makefiles。

是的，学习它“困难”，但在我看来，这不比学习 CMAKE/SCons 中所有特定的宏/函数调用更难。对于项目的初始 Makefile.am 只是一个分配给变量的文件列表，而初始的 configure.ac 可以通过 autoscan 生成；即使对于更琐碎的项目，我也觉得这很方便。

我所知道的最好的学习资料是 autobook，但不幸的是它已经过时了（autoconf 会抱怨使用了弃用的宏）。

- DanielKO

---

好的回答，只有一个关于PKG_CHECK_MODULES的评论：它是邪恶的，不要使用它：http://tirania.org/blog/archive/2012/Oct-20.html - knocte

Miguel仍然有影响力吗？他指出的唯一问题可以通过正确分发打包好的tarballs（已生成configure）或将pkg.m4复制到项目中（并让autoconf版本控制生效）来轻松解决。后者并不是很有用，因为如果没有pkg-config，用户将不得不手动在_CFLAGS和_LIBS变量中指定所有路径和标志。 - DanielKO

关于相关性：那是人身攻击谬误。关于“手动”，你读完整篇博客文章了吗？它清楚地表明，节省4行代码（设置CFLAGS和LIBS所需的代码）并不能证明ACLOCAL和其它工具的复杂性是合理的。 - knocte

他非常吵闹，有时候也会误导人，那篇博客文章就是这样。是的，我看过了，他没有直接说明问题所在，似乎也不知道 PKG_CHECK_MODULES 是什么。提示：它允许您通过提供自己的覆盖来抑制 pkg-config 调用；它具有信息性错误消息；它检查 pkg-config 是否存在，然后才声称模块不存在。pkg.m4 中的那 200 行代码有相当多的错误消息和注释；给我精确的错误检查和诊断“膨胀”任何时间，而不是几行可以悄悄失败的代码。 - DanielKO

你的评论与他博客文章中的一条评论几乎相同，Miguel 回复了它，我认为他的回答也适用于你在这里的评论。 - knocte

我不明白我的评论与其他人的评论有何相似之处，也不认为Miguel的回答有什么好处，因为他只是称Emmanuele的评论为愚蠢、愚笨和愚蠢的表现。你的评论也大多缺乏内容；所讨论的宏有很多功能可以派上用场；Miguel方便地忽略了这一点，而采用了一个快速的hack，只在Google搜索中指出的问题不发生的情况下才有效。用户不应该从克隆存储库安装，而应该从发布tarball安装。Autoconf不是面向最终用户的工具。 - DanielKO

Answer 3

您可以挑选并选择想要使用的autotools部分。很多项目只使用autoconf，这是生成configure脚本的autotools部分。如果您只想生成一个Makefile，其中包含用户可配置的install目标，那么这可能就是您需要的全部内容。

- caf

Answer 4

我不确定这个答案是否离题太远，但我会考虑使用scons。它需要一些时间来启动，但可以自动完成许多手工制作的make操作。

- Jiminion