Autotools、Cmake 和 Scons 之间有什么区别? [英] What are the differences between Autotools, Cmake and Scons?

查看:67
本文介绍了Autotools、Cmake 和 Scons 之间有什么区别?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

What are the differences between Autotools, Cmake and Scons?

推荐答案

事实上,Autotools 唯一真正的可取之处"是所有 GNU 项目都在大量使用它.

In truth, Autotools' only real 'saving grace' is that it is what all the GNU projects are largely using.

Autotools 的问题:

Issues with Autotools:

  • 真正的 ARCANE m4 宏语法与冗长、扭曲的 shell 脚本相结合,用于测试兼容性"等
  • 如果你不注意,你搞乱交叉编译能力(它应该清楚地注意到,诺基亚提出了 Scratchbox/Scratchbox2,以高度 回避了 Maemo/Meego 损坏的 Autotools 构建设置.)如果您出于任何原因修复了, 测试中的静态路径,您将破坏交叉编译支持,因为它不会遵守您的 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 纠正的大部分内容.GNU 可能需要对代码库进行粗略的删除,在鉴于 Heartbleed 发生的事情)您可以使用它来完成您的项目,它可能适用于一个小型项目,除了 Linux 或 GNU 工具链显然可以正常工作之外,您不希望在任何地方工作.它与 Linux 很好地集成"的声明是相当大胆的声明,并且很不正确.它可以很好地与 GNU 工具套件集成,并解决 IT 部门在实现其目标时遇到的问题.

It works...most of the time...is all you can say about Autotools. It's a system that solves several problems that only really concerns the GNU project...for their base, core toolchain code. (Edit (05/24/2014): It should be noted that this type of concern is a potentially BAD thing to be worrying about- Heartbleed partially stemmed from this thinking and with correct, modern systems, you really don't have any business dealing with much of what Autotools corrects for. GNU probably needs to do a cruft removal of the codebase, in light of what happened with Heartbleed) You can use it to do your project and it might work nicely for a smallish project that you don't expect to work anywhere except Linux or where the GNU toolchain is clearly working correctly on. The statement that it "integrates nicely with Linux" is quite the bold statement and quite incorrect. It integrates with the GNU toolsuite reasonably well and solves problems that IT has with it's goals.

这并不是说此处讨论的其他选项没有问题.

This is not to say that there's no problems with the other options discussed in the thread here.

SCons 更像是 Make/GMake/etc 的替代品.看起来很不错,考虑到所有因素 但是...

SCons is more of a replacement for Make/GMake/etc. and looks pretty nice, all things considered However...

  • 它仍然更像是一个仅限 POSIX 的工具.与使用 Autotools 相比,您可能更容易让 MinGW 使用它来构建 Windows 的东西,但它仍然更适合做 POSIX 的东西,并且您需要安装 Python 使用它.
  • 除非您使用的是像 Scratchbox2 这样的东西,否则交叉编译会出现问题.
  • 从他们自己的比较来看,诚然比 CMake 慢且不稳定.与 SCons 相比,他们对 CMake 提出了三心二意(POSIX 方面需要 make/gmake 来构建...)的负面影响.(顺便说一句,如果您需要比其他解决方案更多的可扩展性,您应该问问自己您的项目是否太复杂了...)

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

The examples given for CMake in this thread are a bit bogus.

不过……

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

事实上,您的目标应该决定您在此处选择什么.

In truth, your goals should dictate what you choose here.

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

许多项目放弃 qmake、Autotools 等,转而使用 CMake,这是有原因的.到目前为止,我可以明确地期望基于 CMake 的项目要么陷入交叉编译状态,要么进入 VisualStudio 设置,或者只需要少量清理,因为该项目没有考虑仅 Windows 或 OSX 的部分到代码库.我真的不能指望在基于 SCons 的项目中会出现这种情况 - 我完全希望有 1/3 或更多的 Autotools 项目出现某些错误,从而阻止它正确构建除了主机构建或 Scratchbox2 之外的任何上下文.

There is a reason many, many projects are ditching qmake, Autotools, etc. and moving over to CMake. So far, I can cleanly expect a CMake based project to either drop into a cross-compile situation or onto a VisualStudio setup or only need a small amount of clean up because the project didn't account for Windows-only or OSX-only parts to the codebase. I can't really expect that out of an SCons based project- and I fully expect 1/3rd or more Autotools projects to have gotten SOMETHING wrong that precludes it building right on any context except the host building one or a Scratchbox2 one.

这篇关于Autotools、Cmake 和 Scons 之间有什么区别?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆