Autotools，Cmake和Scons之间有什么区别？
实际上，Autotools唯一真正的“省钱”之处就是这是所有GNU项目都在广泛使用的东西。
自动工具的问题:
Truly ARCANE m4宏语法与详细信息，扭曲的shell脚本结合使用，以测试“兼容性”等。如果您不注意，则将弄乱交叉编译功能(它
应该明确指出的是，诺基亚想出了Scratchbox/Scratchbox2来回避高度破坏了Maemo/Meego的Autotools构 build 置。)如果由于某种原因在测试中有固定的静态路径，您将中断交叉编译支持，因为它不符合您的sysroot规范，并且会将东西从您的主机系统中取出。如果您放弃了交叉编译支持，它将使您的代码无法用于诸如
OpenEmbedded，使其对尝试在交叉编译器而非目标版本上构建发行版的发行版“很有趣”。 对 NOBODY 当前在当今这个时代生产的几乎所有产品中使用的古老的，损坏的编译器进行大量测试。除非您在Solaris，AIX或其他类似软件的真正古代版本上构建glibc，libstdc++或GCC之类的东西，否则这些测试是浪费时间，并且会导致许多类似上述提到的潜在破坏以上。 获取Autotools设置来为Windows系统构建可用代码几乎是一个痛苦的经历。 (尽管我很少使用Windows，但如果要开发据说跨平台的代码，则是一个严重的问题。)当它崩溃时，您将花费 HOURS 追尾，以理清谁编写脚本的错误来理清您的构建(事实上，这就是我要做的(或，而不是完全淘汰Autotools-我怀疑本月剩余时间是否有足够的时间整理困惑...)，因为我正在键入此代码，所以现在可以工作了。Apache Thrift具有其中一种 BROKEN 构建系统不会交叉编译。)实际上，“普通”用户是而不是只会做“./configure; make”-在很多情况下，他们将要从某人提供的软件包中取出PPA或他们的发行商。在许多情况下，“普通”用户不是开发人员，也不是抓包。每个人都认为这是事实，这对所有人都很不利。 tarball的典型用户是开发人员在做事情，因此如果存在损坏，他们将大为震惊。
它可以工作...大多数时候...关于Autotools的全部内容。它是一个系统，可以解决几个真正与GNU项目有关的问题……就其基础，核心工具链代码而言。 (Edit(05/24/2014):应该注意的是，这种担忧是潜在的 BAD 值得担心的事情。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++编译器。
实际上，您的目标应该决定您在这里选择什么。
是否需要处理 splinter 的工具链的很多才能产生有效的工作二进制文件？如果是，请注意上面提到的缺点，然后考虑考虑使用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/3rd或更多的Autotools项目出现 SOMETHING 错误，这使得它无法在任何上下文上正确构建，除非宿主在构建一个或一个Scratchbox2。