Autotools, Cmake和Scons之间有什么区别?

小开

了解Autotools的重要一点是，它们不是一个通用的构建系统——它们只实现GNU编码标准。如果您想要制作一个遵循所有GNU标准的包，那么Autotools是一个很好的工具。如果你没有，那么你应该使用Scons或CMake。(例如，参见这个问题。)这个常见的误解是使用Autotools的大部分挫败感的来源。

小开

这与GNU编码标准无关。

autotools目前的好处——特别是与automake一起使用时——是它们与构建Linux发行版集成得非常好。

以cmake为例，它总是“我需要的是-DCMAKE_CFLAGS还是-DCMAKE_C_FLAGS ?”不，都不是，它是"-DCMAKE_C_FLAGS_RELEASE"。或-DCMAKE_C_FLAGS_DEBUG。这很令人困惑-在autoconf中，它只是。/configure CFLAGS="- o0 -ggdb3"然后你就有了它。

在与构建基础设施集成时，scons存在不能使用make %{?_smp_mflags}的问题，在这种情况下，_smp_mflags是一个RPM宏，它大致扩展到(管理员可以设置它)系统功率。人们把- jncpu之类的东西放在他们的环境中。使用scons是不行的，所以使用scons的包只能在发行版中被序列化。

小开

必须对使用这些工具的人进行重要区分。Cmake是用户在构建软件时必须使用的工具。autotools用于生成发行版tarball，该tarball可用于仅使用任何SuS兼容系统上可用的标准工具构建软件。换句话说，如果您正在从使用autotools构建的tarball中安装软件，则不使用自动工具. exe将被删除。另一方面，如果你正在安装使用Cmake的软件，那么你使用Cmake 是，并且必须安装它来构建软件。

绝大多数用户不需要在他们的机器上安装自动工具。从历史上看，由于许多开发人员分发了格式不正确的tarball，迫使用户运行autoconf来重新生成配置脚本，这是一个打包错误，因此造成了许多混乱。大多数主要的linux发行版都安装了多个版本的autotools，而默认情况下它们不应该安装其中任何一个，这引起了更多的混乱。如果开发人员试图使用版本控制系统(例如cvs、git、svn)来分发他们的软件，而不是构建tarball，就会造成更大的混乱。

小开

事实上，Autotools唯一真正的“可取之处”是它是所有GNU项目都在大量使用的。

Autotools的问题:

真正的奥坎m4宏语法结合详细，扭曲的shell脚本测试“兼容性”等。

 

 高

在这个时代， 没人目前在几乎所有产品中使用的旧的、坏的编译器进行了大量的测试。除非你是在真正的 古代版本的Solaris、AIX或类似版本上构建glibc、libstdc++或GCC之类的东西，否则这些测试是浪费时间的，而且是上面提到的许多潜在破坏的来源。
在Windows系统上安装Autotools来构建可用的代码是非常痛苦的经历。(虽然我很少使用Windows，但如果你正在开发据称是跨平台的代码，这是一个严重的问题。)
当它崩溃时，你将花费< 小时/ em >来追踪你的尾巴，试图整理那些编写脚本的人错误的东西，以整理你的构建(事实上，这就是我正在尝试做的事情(或者，更确切地说，完全删除Autotools -我怀疑这个月剩下的时间是否有足够的时间来整理混乱……)Apache Thrift有一个不会交叉编译的破构建系统。)
“正常”用户实际上是不 只做“./configure”;make”-对于很多事情，他们会提取某人提供的包，比如PPA或他们的分销供应商。“正常”用户不是开发人员，在很多情况下不会抓取tarball。这对每个人来说都是势利的，因为他们认为情况会是这样。tarball的典型用户是开发人员，所以他们会因为它的损坏而受到冲击。

它的工作原理……大多数时候……这就是你对Autotools的全部看法。它是一个解决了几个真正与GNU项目有关的问题的系统……它们的基础、核心工具链代码。(编辑(05/24/2014):应该注意的是，这种类型的担忧是一种潜在的坏 需要担心的事情- Heartbleed部分源于这种想法，在正确的现代系统中，你真的 没有任何业务处理Autotools更正的大部分内容。GNU可能需要对代码库做一个简单的移除，根据发生在Heartbleed的事情)你可以使用它来做你的项目，它可能会很好地工作在一个小项目上，你不期望在任何地方工作，除了Linux或GNU工具链清楚地正确工作。它“与Linux很好地集成”的说法是是，粗体的说法，相当 不正确。它很好地集成了GNU工具套件，并解决了It在实现其目标时遇到的问题。

这并不是说本文讨论的其他选项没有问题。

SCons更像是Make/GMake等的替代品。从各方面来看，看起来都很不错。

它仍然只是一个POSIX工具。你可能更容易让MinGW用它来构建Windows的东西，但它仍然更适合做POSIX的东西，你需要安装Python 和 SCons来使用它。
它在进行交叉编译时存在问题，除非您使用的是Scratchbox2之类的东西。
无可否认，从他们自己的比较来看，比CMake慢和不稳定。他们提出了半心半意的(POSIX方面需要make/gmake来构建…)CMake与SCons相比的负面意见。(顺便说一句，如果你需要 比其他解决方案更大的可扩展性，你应该问问自己你的项目是否太复杂了…)

在这个线程中给出的CMake的例子有点假。

然而……

你需要学习一门新的语言。
如果你习惯了Make、SCons或Autotools，就会有一些反直觉的事情。
您需要在正在构建的系统上安装CMake。
如果没有预先构建的二进制文件，则需要一个可靠的c++编译器。

事实上，你的目标应该决定你在这里的选择。

你需要处理破碎工具链的 很多来产生有效的工作二进制文件吗?如果是的话，你可能会考虑使用Autotools，要知道我上面提到的缺点。CMake可以处理很多这样的问题，但是它比Autotools担心的要少。可以扩展SCons来担心这个问题，但它并不是一个开箱即用的答案。
你有必要担心Windows目标吗?如果是这样的话，Autotools应该完全被淘汰了。如果是这样，SCons可能是/可能不是一个好的选择。如果是这样，CMake是一个可靠的选择。
你需要担心交叉编译(通用应用程序/库，像谷歌Protobufs, Apache Thrift等。 应该关心这个…)?如果是这样，Autotools  可能为你工作，只要你不需要担心Windows，但你将花费大量的时间来维护你的配置系统，因为事情发生了变化。SCons目前几乎是不可能的，除非你使用Scratchbox2——它真的不能处理交叉编译，你将需要使用这种可扩展性，并以与Automake相同的方式维护它。如果是这样，你可能会考虑使用CMake，因为它支持交叉编译，而不用担心从沙盒中泄露出来，并且可以使用/不使用Scratchbox2这样的东西，并将很好地 与OpenEmbedded这样的东西集成在一起。

这是很多很多项目抛弃qmake、Autotools等而转向CMake的原因。到目前为止，我可以清楚地看到一个基于CMake的项目要么陷入交叉编译的情况，要么进入VisualStudio设置，或者只需要少量的清理，因为该项目不考虑代码库中仅支持windows或仅支持osx的部分。我真的不能指望基于SCons的项目能做到这一点——而且我完全希望1/3或更多的Autotools项目都犯了 的东西错误，这就排除了它在任何上下文上的正确构建，除非主机构建一个或Scratchbox2一个。

小开

虽然从开发人员的角度来看，cmake是目前最容易使用的，但从用户的角度来看，autotools有一个很大的优势

Autotools生成单个文件配置脚本，生成该脚本的所有文件都随发行版一起提供。在grep/sed/awk/vi的帮助下，它很容易理解和修复。与此相比，Cmake中有许多文件位于/usr/share/cmak*/Modules中，除非用户拥有管理员权限，否则无法修复这些文件。

因此，如果有些东西不能正常工作，通常可以通过使用标准Unix工具(grep/sed/awk/vi等)以一种大锤式的方式来“修复”，而不需要了解构建系统。

您是否曾经在您的cmake构建目录中查找错误的地方?与可以从上到下读取的简单shell脚本相比，跟踪生成的Cmake文件来了解发生了什么是相当困难的。此外，与CMake，适应FindFoo。cmake文件不仅需要了解cmake语言，还可能需要超级用户权限。