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

Autotools、Cmake 和 Scons 有什么区别?

【问题讨论】:

标签: 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 构建会带来更多的依赖关系。用户可能需要asciidochelp2mandoxygen,或者更重要的是,需要正确的自动工具组合。这对汽车工具来说是一个巨大的营销问题。用户错误地认为他们需要安装 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 文件。它不会改变使用 installcheckdistclean 等规则构建 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 的方式。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-05-08
  • 2018-12-23
  • 2010-11-07
  • 2014-07-20
相关资源
最近更新 更多