【问题标题】：Advantages of using autotools and alternates使用自动工具和替代工具的优势
【发布时间】：2013-08-18 10:33:07
【问题描述】：

我有一个中等的 C++ 项目。我正在尝试使用自动工具，但发现其复杂性不堪重负。

什么时候使用自动工具以及什么时候可以不用它？什么是（简单的）替代方案？

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

理想情况下，我想要 Eclipse CDT 支持的东西。

【问题讨论】：

stackoverflow.com/questions/1052759/eclipse-cdt-scons

标签： c++ c linker makefile autotools

【解决方案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 工具非常有用。您编写一个简单的脚本来测试您使用的系统头文件和系统库是否存在。如果没有找到，您要么给出错误，要么使用包中提供的副本。

【讨论】：

哇，这很简单。外部共享库呢，它们去哪儿了？
@SRobertJames 将它们附加到 LIBS 变量中，更新了我的示例。
另外，libtool 值得一提；弄清楚如何链接动态库和静态库确实很神奇。
我只是补充一点，而不是使用noinst_HEADERS，头文件应该（理想情况下）列在hello_SOURCES中。

【解决方案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 以预期的方式填充空白。

它当然没有解决依赖跟踪问题，也没有检查系统功能。非平凡项目的一个常见问题是与系统交互：确保某些库可用，以及安装/卸载。大多数工具在两者上都失败了。

这里有几个我有经验的例子：

预制

它为不同的 IDE 生成一致的项目文件（如果您只需要构建代码，还可以生成 Makefiles）。不做任何其他事情（没有安装目标，无法检查库的可用性）。仅当您需要为不使用的 IDE 提供项目文件时才有用（例如，您使用 Eclipse 并且其他人想在 Visual Studio 上编译它）。任何重要的事情都需要 LUA 脚本。

CMAKE

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

SCons

似乎 CMAKE 和 Premake 做得更好：没有宏，使用著名的编程语言 (Python) 来提供大量有用的功能。在很多方面仍然失败；指定一个非硬编码的安装前缀需要不小的努力，因为它不是内置的。

自动工具

远远超过上面提到的工具。其中大多数，方便。有健全的默认值；一些亮点：

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（如果你指定@ 987654331@ 程序），make dist-gzip（将源文件打包成 tar.gz），make distcheck（创建一个 tar.gz 并确保一切都正确构建并且所有测试都通过）。更好的是，它与 checkinstall 配合得很好，因此您可以从中创建和分发 .rpms 和 .debs。
如果需要，您可以在 automake Makefile 中混合使用旧的 Makefile 规则。
Autotools 文件与源文件一样被跟踪，因此如果需要，只需调用 make 即可再次生成帮助脚本和 Makefile。

是的，学习起来“很难”，但在我看来，只不过是学习在 CMAKE/SCons 中调用的所有特定宏/函数。项目的初始Makefile.am只是分配给变量的文件列表，初始configure.ac可以由autoscan生成；我发现即使是更琐碎的项目也很方便。

autobook 是我所知道的学习它的最佳来源，但不幸的是它已经过时了（autoconf 会抱怨很多关于使用已弃用的宏）。

【讨论】：

好的答案，只有一条关于 PKG_CHECK_MODULES 的评论：这是邪恶的，不要使用它：tirania.org/blog/archive/2012/Oct-20.html
米格尔还有意义吗？他指出的唯一问题可以通过分发正确打包的 tarball（已生成配置）或将 pkg.m4 复制到项目中（并让 autoconf 版本控制启动）来轻松解决。后者不是那么有用，因为没有 pkg-config，用户将不得不在 _CFLAGS 和 _LIBS 变量中手动指定所有路径和标志。
WRT 相关性：这是人身谬误。 WRT“手动”，你读过整篇博文吗？它清楚地表明，节省 4 行代码（设置 CFLAGS 和 LIBS 所需的代码）并不能证明 ACLOCAL 和朋友的所有复杂性。
他声音很大，有时会被误导，该博客文章显示了这一点。是的，我读过，他没有直接说明问题是什么，而且他似乎对 PKG_CHECK_MODULES 的作用一无所知。提示：它允许您通过提供自己的覆盖来抑制 pkg-config 调用；它有信息丰富的错误消息；它在声明模块不存在之前检查 pkg-config 是否存在。 pkg.m4 中的那 200 行有相当多的错误消息和 cmets；随时给我精确的错误检查和诊断“膨胀”，通过几行可能会静默失败。
您的评论与他博客文章中的一位 cmets 几乎相同，而 Miguel 回复了它，我认为他的回答也是对您的评论的有效答案

【解决方案3】：

您可以选择要使用的自动工具部件。许多项目只使用autoconf，这是自动工具的一部分，它会生成configure 脚本，如果您只想生成带有install 目标的Makefile，并且可以由最终用户配置，那么这可能就是您的全部了需要。

【讨论】：

【解决方案4】：

我不知道这是否离答案太远了，但我会考虑 scons。开始需要一点时间，但会自动完成许多必须使用 make 手动调侃的事情。

【讨论】：