Autotools、Cmake 和 Scons 之间有什么区别？答案

【问题标题】：What are the differences between Autotools, Cmake and Scons?Autotools、Cmake 和 Scons 之间有什么区别？
【发布时间】：2011-05-03 13:56:36
【问题描述】：

Autotools、Cmake 和 Scons 有什么区别？

【问题讨论】：

这个话题已经在Scons wiki中讨论过了。我建议您访问以下链接： 1. scons.org/wiki/SconsVsOtherBuildTools 您是否访问过Ubuntu Forum 中非常相似的讨论主题？
您可以查看此pdf www-alt.gsi.de/documents/DOC-2007-Sep-17-1.pdf；它有优点和缺点，也有关于每个工具的一些细节。

标签： build cmake scons autotools build-system

【解决方案1】：

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

Autotools 的问题：

真正的 ARCANE m4 宏语法与冗长、扭曲的 shell 脚本相结合，用于测试“兼容性”等。
如果你不注意，你会搞砸交叉编译能力（它应该清楚地指出，诺基亚提出了 Scratchbox/Scratchbox2 来回避高度损坏的 Maemo/Meego 的 Autotools 构建设置。）如果您出于任何原因已修复，你的测试中的静态路径，你将破坏交叉编译支持，因为它不会遵守你的 sysroot 规范，它会从你的主机系统中提取东西。如果您破坏了交叉编译支持，它会使您的代码无法用于诸如 OpenEmbedded 并让试图在交叉编译器而不是目标上构建其版本的发行版变得“有趣”。
对NOBODY目前在当今几乎所有产品中使用的古老、损坏的编译器的问题进行大量测试。除非您在真正的 ancient 版本的 Solaris、AIX 等上构建诸如 glibc、libstdc++ 或 GCC 之类的东西，否则这些测试是浪费时间并且是上述许多潜在破坏的根源。
获得 Autotools 设置以构建适用于 Windows 系统的可用代码是非常痛苦的经历。（虽然我很少使用 Windows，但如果您正在开发据称是跨平台的代码，这是一个严重的问题。）
当它中断时，您将花费 HOURS 追尾试图理清编写脚本的人错误的东西以理清您的构建（事实上，这就是我正在尝试做的事情（或者，更确切地说，完全淘汰 Autotools - 我怀疑本月剩下的时间是否有足够的时间来解决这个烂摊子......）我现在正在工作输入这个。Apache Thrift 有一个不会交叉编译的BROKEN构建系统。）
“普通”用户实际上不只会执行“./configure; make”- 对于很多事情，他们会拉包由某人提供，例如来自 PPA 或他们的分销供应商。 “普通”用户不是开发人员，在许多情况下也不会抓取 tarball。这对每个人来说都是势利的，因为假设那里会出现这种情况。 tarball 的典型用户是做事的开发人员，所以如果它存在的话，他们会被破坏性的抨击。

它有效...大多数时候...关于 Autotools 的所有信息。它是一个解决了几个问题的系统，这些问题只与 GNU 项目真正相关……因为它们的基础、核心工具链代码。（编辑（2014 年 5 月 24 日）：应该指出，这种类型的担忧可能是一个值得担心的糟糕事情——Heartbleed 部分源于这种想法和使用正确的现代系统，您真的没有任何业务来处理 Autotools 纠正的大部分内容。GNU 可能需要对代码库进行粗略的删除，在鉴于 Heartbleed 发生的事情）您可以使用它来完成您的项目，并且对于您不希望在除 Linux 或 GNU 工具链明显正常工作的地方以外的任何地方工作的小型项目，它可能会很好地工作。它“与 Linux 完美集成”的说法相当是粗体的说法，而且非常不正确。它与 GNU 工具套件很好地集成在一起，并解决了 IT 与它的目标有关的问题。

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

SCons 更像是 Make/GMake/etc 的替代品。看起来很不错，所有的东西都考虑了但是......

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

此线程中为 CMake 提供的示例有点虚假。

不过……

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

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

您是否需要处理很多损坏的工具链来生成有效的工作二进制文件？如果是，您可能需要考虑 Autotools，并意识到我上面提到的缺点。 CMake 可以处理很多这样的问题，但它比 Autotools 更不用担心。 SCons 可以扩展来担心它，但这不是一个开箱即用的答案。
您是否需要担心 Windows 目标？如果是这样，Autotools 应该完全退出运行。如果是这样，SCons 可能/可能不是一个好的选择。如果是这样，CMake 是一个不错的选择。
您是否需要担心交叉编译（通用应用程序/库、Google Protobufs、Apache Thrift 等）。应该关心这个.. .)？如果是这样，Autotools 可能可以为您工作，只要您不需要担心 Windows，但您将花费大量时间来维护您的配置系统事情在你身上改变。 SCons 目前几乎是不行的，除非你使用 Scratchbox2——它确实没有处理交叉编译，你需要使用这种可扩展性并以与您将使用 Automake。如果是这样，您可能需要考虑 CMake，因为它支持交叉编译，无需担心从沙箱中泄漏，并且可以使用/不使用 Scratchbox2 之类的东西，并且很好地集成了 使用 OpenEmbedded 之类的东西。

有很多很多项目放弃 qmake、Autotools 等并转向 CMake 的原因。到目前为止，我完全可以期望基于 CMake 的项目要么进入交叉编译情况，要么进入 VisualStudio 设置，或者只需要少量清理，因为该项目不考虑仅 Windows 或仅 OSX 部分到代码库。我真的不能指望在基于 SCons 的项目中会出现这种情况——而且我完全预计 1/3 或更多 Autotools 项目会出现 SOMETHING 错误，从而无法正确构建除了主机构建一个或 Scratchbox2 一个之外的任何上下文。

【讨论】：

提到 Heartbleed 的部分削弱了这种沮丧的咆哮。问题在于 OpenSSL 没有使用配置器类型包来检测损坏的 malloc，而是重新实现系统库并击败了生成库的平台开发人员，这些库可以更快地检测到缺陷。移植程序的一个原因是它们变得更高质量，因为它们更少依赖于您甚至没有意识到自己正在做出的那些小假设
问题是它根本不会减损它。使用 Autotools，您会担心补偿类似的事情——这些重新实现是这种想法的扩展。把它带到一个新的水平。你应该从那个背景来看……在这一点上它根本不会减损它。你没有在你的推理中指出根本原因——只是发生了什么。我正在摸索将它与 Shellshock 和其他一些类似的东西一起带来的确切想法。如果它坏了，你应该修复它。如果你不能 - 你应该问为什么要继续这样做。
我不怀疑 autotools 和 scons 很糟糕，但是这个答案在指出 CMake 的缺点方面做得很差（我首选的构建系统，只是因为构建系统的状态非常非常糟糕)。基本上，CMake 是一种不一致的分形，它内置了对个别边缘情况的支持，而不是一些处理大多数事情的核心抽象。这绝对是编程的胶带和钢丝绳。我确定我做错了什么，但它不支持 VisualStudio，除非你发现每个 CMakeLists.txt 有一个 VS 项目可以接受（我不是 VS 用户，但我的 Winfriends 告诉我这很糟糕）。
Unlike other hated programming tools，没有足够的材料来制作一本名为“CMake，好的部分”（可能是小册子或博客文章）的书，而且它更像是糟糕设计的分形比PHP.
@JAB VS 用户告诉我这不是惯用的。事实上，CMake 已被替换为我们项目的构建系统，因为没有人知道如何生成所说的“惯用的”VS Project 文件。

【解决方案2】：

必须在使用这些工具的人之间做出重要区分。 Cmake是用户在构建软件时必须使用的工具。 autotools 用于生成分发 tarball，可用于仅使用任何 SuS 兼容系统上可用的标准工具来构建软件。换句话说，如果您从使用 autotools 构建的 tarball 安装软件，您没有使用 autotools。另一方面，如果您正在安装使用 Cmake 的软件，那么您正在使用 Cmake，并且必须安装它才能构建软件。

绝大多数用户不需要在他们的盒子上安装自动工具。从历史上看，由于许多开发人员分发格式错误的 tarball，迫使用户运行 autoconf 以重新生成配置脚本，造成了很多混乱，这是一个打包错误。大多数主要的 Linux 发行版安装了多个版本的自动工具，而默认情况下它们不应该安装任何一个，这导致了更多的混乱。开发人员试图使用版本控制系统（例如 cvs、git、svn）来分发他们的软件而不是构建 tarball 会导致更多的混乱。

【讨论】：

是的，尽管您听起来好像使用 VCS 分发软件很糟糕。如果 checkout 或 clone 的内容与 tarball 的内容相同，为什么要推荐 tarball？
@Toor 我不明白你的问题。我从事的所有项目都会生成一个与 VCS 结帐不同的 tarball。保持两者不同有助于实现可靠的分发。
很多项目确实要求人们使用 VCS 来获取最新版本，但这仅适用于开发人员。不幸的是，许多用户无法理解发行版 tarball 和 VCS 之间的区别。尝试从 VCS 构建会带来更多的依赖关系。用户可能需要asciidoc 或help2man 或doxygen，或者更重要的是，需要正确的自动工具组合。这对汽车工具来说是一个巨大的营销问题。用户错误地认为他们需要安装 autoconf，因为他们不了解 tarball 和 VCS 之间的区别。
为什么一个项目不能为常见平台（例如）Win、Linux 和 MacOSX 分发 Cmake 的输出、项目文件和 Makefile？这似乎与使用 lex/yacc 工具的情况相同，您包含生成的 C 代码，因此它可以在没有工具的平台上构建
虽然我认为这个讨论中提到的观点是正确的，但我确实认为这个讨论没有抓住重点。用户需要安装一大堆其他东西，他是否需要安装 cmake 应该不是一个大问题。我会更担心构建软件所需的库、编译器工具链和其他工具。

【解决方案3】：

这与 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 宏，它大致扩展为（管理员可以设置它）系统电源。人们通过他们的环境将 -jNCPUS 之类的东西放在这里。由于 scons 不起作用，因此使用 scons 的软件包可能只能在发行版中进行序列化。

【讨论】：

+1，如果这是真的，世界将会变得更美好。可悲的是，./configure CFLAGS=-O0 经常失败，因为包覆盖了 makefile 中的 CFLAGS 并要求用户运行./configure --enable-debug。（例如tmux）。
它并不比 Autotools 更令人困惑，正如 William 正确指出的那样，它会因 makefile 中不正确的 CFLAGS = "" 框架而彻底崩溃。很简单，这是另一个“旧锯”项目。并且 CMake 示例是伪造的......再次......如果你没有指定 RELEASE 或 DEBUG，你可以做第一个。失败。

【解决方案4】：

了解 Autotools 的重要一点是，它们不是一个通用的构建系统——它们实现了 GNU 编码标准，仅此而已。如果你想制作一个遵循所有 GNU 标准的包，那么 Autotools 是完成这项工作的绝佳工具。如果你不这样做，那么你应该使用 Scons 或 CMake。（例如，请参阅this question。）这种常见的误解是对 Autotools 的大部分挫败感的来源。

【讨论】：

GNU 标准可以在 Automake 中使用 AUTOMAKE_OPTIONS = -foreign 在您的 Makefile.am 中禁用。（或者你的autogen.sh中的-foreign。我想几乎每个人都使用这个。）
是的，但这仅控制 Automake 是否强制执行表面的 GNU 规则，例如是否需要 README 文件。它不会改变使用 installcheck 和 distclean 等规则构建 GNU 风格 tarball 的基本前提。如果您尝试在仍然使用 Autotools 的同时改变这种行为，那么您只是在浪费时间。
它们（理论上）允许以完全相同的方式构建和安装所有软件包。
理论上，它们允许您比使用其他工具更恰当地处理 BROKEN 编译器和操作系统，并应用其中突出显示的@ptomato 等表面规则。如果您在现代操作系统上使用现代（例如 GCC 或 clang...例如）工具，而没有真正愚蠢的东西，例如 Linux 或当前的 *BSD，您不会需要那里的“规则”。实际上，他们为您做了很多很多工作，并且无能为力，老实说，对于交叉编译。如今，近一半的应用用于嵌入式 Linux 和 *BSD。你为什么要去做那些对你没有帮助的事情？
不知道你为什么不赞成这个答案，因为你似乎在评论中承认了它......？

【解决方案5】：

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

autotools 生成单个文件配置脚本，并且生成它的所有文件都随发行版一起提供。在 grep/sed/awk/vi 的帮助下很容易理解和修复。将此与 Cmake 相比，在 /usr/share/cmak*/Modules 中可以找到大量文件，除非用户具有管理员权限，否则无法修复这些文件。

因此，如果某些东西不能正常工作，通常可以通过使用标准 Unix 工具（grep/sed/awk/vi 等）以大锤的方式轻松“修复”，而无需了解构建系统。

您是否曾经翻遍您的 cmake 构建目录以找出问题所在？与可以从上到下读取的简单 shellscript 相比，按照生成的 Cmake 文件找出发生了什么是相当困难的。此外，使用 CMake，调整 FindFoo.cmake 文件不仅需要了解 CMake 语言，还可能需要超级用户权限。

【讨论】：

与 CMake 相比，我不认为 Autotools 的问题“容易解决”...
因为 autotools 是一个复杂的系统（就像 CMake 一样）。如果您认为 Autotools “很容易修复”（可能有理由这样认为），恕我直言，最好在答案中解释哪种方式更容易解决问题。
autotools 生成单个文件配置脚本，并且生成它的所有文件都随发行版一起提供。在 grep/sed/awk/vi 的帮助下很容易理解和修复。将此与在 /usr/share/cmak*/Modules 中找到大量文件的 Cmake 进行比较，除非他具有管理员访问权限，否则用户无法修复这些文件。你有没有翻过你的 cmake 构建目录来找出问题所在？相对于可以从上到下读取的简单shellscript，通过生成的Cmake文件来了解发生了什么是相当困难的
是的，这是有道理的，谢谢。我冒昧地将其添加到您的答案中。随意恢复:-)。
您始终可以使用自己的本地版本的 cmake；没有理由使用在系统级别安装的内容。对于任何做跨平台工作的人来说，这是完全正常的；这当然是我大部分时间使用 cmake 的方式。