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

问题描述

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

解决方案

实际上，Autotools唯一真正的节省宽限期"是所有GNU项目都在使用它.

Autotools问题:

• 真正的ARCANE m4宏语法与冗长的，扭曲的外壳脚本结合在一起，用于兼容性"测试等.
• 如果您不注意，则会 会 搞乱交叉编译功能( 应该明确指出的是，诺基亚想出了Scratchbox/Scratchbox2来回避 高度 损坏的Maemo/Meego的Autotools构建设置.)如果您由于任何原因已修复， ，即测试中的静态路径，您将中断对交叉编译的支持，因为它不符合您的sysroot规范，并且会将东西从您的主机系统中取出.如果您放弃了交叉编译支持，它将使您的代码无法用于诸如 OpenEmbedded，使其对尝试在交叉编译器而不是在目标编译器上构建发行版的发行版很有趣".
• 对古老的，损坏的编译器进行了大量测试， NOBODY 目前在当今这个时代几乎不生产任何东西.除非您在真正的 古代 版本的Solaris，AIX或类似版本上构建glibc，libstdc ++或GCC之类的东西，否则这些测试是在浪费时间，并且上面提到的许多潜在潜在破坏的来源.
• 获得Autotools设置以为Windows系统构建可用代码几乎是一个痛苦的经历. (尽管我很少使用Windows，但如果要开发据说跨平台的代码，则是一个严重的问题.)
• 当它崩溃时，您将花费 HOURS 追逐自己的尾巴，以尝试弄清谁编写脚本的错误来整理您的构建(实际上，这就是我想要做的(或者更确切地说，是完全淘汰Autotools，我怀疑本月剩余时间中是否有足够的时间来清理混乱……)，因为我现在正在工作键入此代码.ApacheThrift具有不会交叉编译的 Broken 构建系统之一.)
• 正常"用户实际上是 不 ，只会做"./configure; make"-在很多情况下，他们将要打包由某人(例如PPA之外的人)或其分销商提供.在许多情况下，普通"用户不是开发人员，也不是抓包.每个人都认为这是事实，这对所有人都很不利. tarball的典型用户是开发人员在做事情，因此如果存在损坏，他们将大为震惊.

它奏效了...大多数时候...关于Autotools的全部内容.它是一个系统，可以解决几个真正与GNU项目有关的问题……就其基础，核心工具链代码而言. (编辑(05/24/2014):应该注意的是，这种担忧可能是潜在的 BAD 令人担忧的事情-Heartbleed部分源于这种想法，如果使用正确的现代系统，您 确实 就没有任何业务可以处理Autotools所纠正的大部分内容.GNU可能需要彻底删除代码库， (您可以使用Heartbleed发生的事情))，您可以使用它来执行您的项目，并且它可能适合小型项目，除了Linux或GNU工具链可以正常工作的地方之外，您都不希望在其他任何地方工作.它与Linux完美集成"的声明是 相当 粗体语句，并且 不正确 .它与GNU工具套件很好地集成在一起，并解决了IT目标方面的问题.

这并不是说这里的线程中讨论的其他选项没有问题.

SCons更是Make/GMake/etc的替代品.而且看起来还不错，所有的东西都考虑过了.

• 它实际上仍然只是POSIX专用工具.与Autotools相比，您可能更容易使MinGW以此来构建Windows东西，但实际上它仍然更适合做POSIX东西，您需要安装Python 和 要使用它.
• 除非您使用的是Scratchbox2之类的东西，否则它会进行交叉编译.
• 从他们自己的比较来看，它确实比CMake慢且不稳定.与SCons相比，它们为CMake带来了三心二意的问题(POSIX方面需要make/gmake来构建...). (顺便说一句，如果您需要 那个 于其他解决方案的可扩展性，您应该问自己项目是否太复杂了……)

在此线程中为CMake给出的示例有点虚假.

但是...

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

实际上，您的目标应该决定您在此处选择的内容.

• 您是否需要处理破碎的工具链中的 LOT 才能生成有效的工作二进制文件?如果是，请注意上面提到的缺点，然后考虑使用Autotools. CMake可以应付很多情况，但是它比Autotools所担心的要少.可以扩展SCons来担心它，但这并不是开箱即用的答案.
• 您是否需要担心Windows目标?如果是这样的话，Autotools应该完全不可用.如果是这样，SCons可能/可能不是一个不错的选择.如果是这样，CMake是一个不错的选择.
• 您是否需要担心交叉编译(通用应用程序/库，诸如Google Protobufs，Apache Thrift之类的东西. SHOULD 对此很在意. )?如果是这样，只要您不需要担心Windows，Autotools 可能 就可以为您工作，但是您将花费大量时间将配置系统维护为事情改变了你.除非您使用的是Scratchbox2-，否则SCons目前几乎是行不通的，除非它确实没有交叉编译的处理方法，否则您将需要使用该可扩展性并以与方法相同的方式对其进行维护.您将使用Automake.如果是这样，您可能要考虑CMake，因为它支持交叉编译，而无需担心从沙箱中泄漏出来，并且可以使用/不使用Scratchbox2之类的东西，并且可以很好地集成 ，例如OpenEmbedded.

很多项目都有理由放弃qmake，Autotools等，然后转移到CMake.到目前为止，我可以明确地期望基于CMake的项目陷入交叉编译的情况或进入VisualStudio安装程序，或者只需要进行少量清理，因为该项目并未考虑仅Windows或仅OSX的部分到代码库.我真的不能指望在基于SCons的项目中，并且我完全希望1/3或更多的Autotools项目出现 SOMETHING 错误，从而无法在其上正确构建除了宿主构建一个上下文或Scratchbox2上下文之外的任何上下文.

What are the differences between Autotools, Cmake and Scons?

解决方案

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

Issues with Autotools:

• Truly ARCANE m4 macro syntax combined with verbose, twisted shell scripting for tests for "compatibility", etc.
• If you're not paying attention, you will mess up cross-compilation ability (It should clearly be noted that Nokia came up with Scratchbox/Scratchbox2 to side-step highly broken Autotools build setups for Maemo/Meego.) If you, for any reason, have fixed, static paths in your tests, you're going to break cross-compile support because it won't honor your sysroot specification and it'll pull stuff from out of your host system. If you break cross-compile support, it renders your code unusable for things like OpenEmbedded and makes it "fun" for distributions trying to build their releases on a cross-compiler instead of on target.
• Does a HUGE amount of testing for problems with ancient, broken compilers that NOBODY currently uses with pretty much anything production in this day and age. Unless you're building something like glibc, libstdc++, or GCC on a truly ancient version of Solaris, AIX, or the like, the tests are a waste of time and are a source for many, many potential breakages of things like mentioned above.
• It is pretty much a painful experience to get an Autotools setup to build usable code for a Windows system. (While I've little use for Windows, it is a serious concern if you're developing purportedly cross-platform code.)
• When it breaks, you're going to spend HOURS chasing your tail trying to sort out the things that whomever wrote the scripting got wrong to sort out your build (In fact, this is what I'm trying to do (or, rather, rip out Autotools completely- I doubt there's enough time in the rest of this month to sort the mess out...) for work right now as I'm typing this. Apache Thrift has one of those BROKEN build systems that won't cross-compile.)
• The "normal" users are actually NOT going to just do "./configure; make"- for many things, they're going to be pulling a package provided by someone, like out of a PPA, or their distribution vendor. "Normal" users aren't devs and aren't grabbing tarballs in many cases. That's snobbery on everyone's part for presuming that is going to be the case there. The typical users for tarballs are devs doing things, so they're going to get slammed with the brokenness if it's there.

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 is more of a replacement for Make/GMake/etc. and looks pretty nice, all things considered However...

• It is still really more of a POSIX only tool. You could probably more easily get MinGW to build Windows stuff with this than with Autotools, but it's still really more geared to doing POSIX stuff and you'd need to install Python and SCons to use it.
• It has issues doing cross-compilation unless you're using something like Scratchbox2.
• Admittedly slower and less stable than CMake from their own comparison. They come up with half-hearted (the POSIX side needs make/gmake to build...) negatives for CMake compared to SCons. (As an aside, if you're needing THAT much extensibility over other solutions, you should be asking yourself whether your project's too complicated...)

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

However...

• You will need to learn a new language.
• There's counter-intuitive things if you're used to Make, SCons, or Autotools.
• You'll need to install CMake on the system you're building for.
• You'll need a solid C++ compiler if you don't have pre-built binaries for it.

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

• Do you need to deal with a LOT of broken toolchains to produce a valid working binary? If yes, you may want to consider Autotools, being aware of the drawbacks I mentioned above. CMake can cope with a lot of this, but it worries less with it than Autotools does. SCons can be extended to worry about it, but it's not an out-of-box answer there.
• Do you have a need to worry about Windows targets? If so, Autotools should be quite literally out of the running. If so, SCons may/may not be a good choice. If so, CMake's a solid choice.
• Do you have a need to worry about cross-compilation (Universal apps/libraries, things like Google Protobufs, Apache Thrift, etc. SHOULD care about this...)? If so, Autotools might work for you so long as you don't need to worry about Windows, but you're going to spend lots of time maintaining your configuration system as things change on you. SCons is almost a no-go right at the moment unless you're using Scratchbox2- it really doesn't have a handle on cross-compilation and you're going to need to use that extensibility and maintain it much in the same manner as you will with Automake. If so, you may want to consider CMake since it supports cross-compilation without as many of the worries about leaking out of the sandbox and will work with/without something like Scratchbox2 and integrates nicely with things like OpenEmbedded.

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屋！