build - Autotools、Cmake 和 Scons 之间有什么区别？

Question

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

Answer 1

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

自动工具的问题：

• 真正的 ARCANE m4 宏语法与冗长、扭曲的 shell 脚本相结合，用于测试“兼容性”等。
• 如果你不注意，你会搞砸交叉编译能力（应该清楚地指出，诺基亚提出了 Scratchbox/Scratchbox2 来回避高度损坏的 Autotools 为 Maemo/Meego 构建设置。）如果你，对于任何原因，在您的测试中有固定的静态路径，您将破坏交叉编译支持，因为它不会遵守您的 sysroot 规范，并且会从您的主机系统中提取内容。如果你破坏了交叉编译支持，它会使你的代码无法用于 OpenEmbedded 之类的东西，并使试图在交叉编译器而不是目标上构建其版本的发行版变得“有趣”。
• 对NOBODY目前在当今几乎所有产品中使用的古老、损坏的编译器的问题进行了大量测试。除非您在真正古老的 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 纠正的大部分内容。鉴于 Heartbleed 发生的情况，GNU 可能需要对代码库进行粗略的删除）您可以使用它来完成您的项目，并且它可能适用于您不希望在除 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 项目会出现一些错误，这使得它无法在任何上下文中正确构建，除了宿主构建一个或 Scratchbox2 一个。

Answer 2

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

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

Answer 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 的软件包可能只能在发行版中进行序列化。

Answer 4

关于 Autotools 的重要了解是它们不是一个通用的构建系统——它们实现了 GNU 编码标准，仅此而已。如果你想制作一个遵循所有 GNU 标准的包，那么 Autotools 是完成这项工作的绝佳工具。如果你不这样做，那么你应该使用 Scons 或 CMake。（例如，请参阅这个问题。）这种常见的误解是 Autotools 最令人沮丧的原因。

Answer 5

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

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

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

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