实际上，Autotools唯一真正的“省钱”之处就是这是所有GNU项目都在大量使用的东西。
自动工具的问题：
- 真正结合了ARCANE m4宏语法和详细的扭曲外壳脚本，以进行“兼容性”测试等。
- 如果您不注意，则会搞乱交叉编译功能（应该清楚地注意到，诺基亚提出了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的典型用户是开发人员在做事情，因此如果存在损坏，他们将大为震惊。
它可以工作...大多数时候...关于Autotools的全部内容。它是一个系统，可以解决几个真正与GNU项目有关的问题……就其基础，核心工具链代码而言。（编辑（2014年5月24日）：应该指出的是，这种关注是一种潜在BAD是担心关于我们-心脏出血漏洞的事情，从这个思路，并与正确的，先进的系统，你朵朵部分真没有任何业务可以处理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 ++编译器。
实际上，您的目标应该决定您在这里选择什么。
- 你需要处理一个LOT破碎工具链产生一个有效的工作二进制？如果是，请注意上面提到的缺点，然后考虑使用Autotools。CMake可以解决很多这样的问题，但是它比Autotools所担心的要少。可以扩展SCons来担心它，但这并不是开箱即用的答案。
- 您是否需要担心Windows目标？如果是这样的话，Autotools应该完全不可用。如果是这样，SCons可能/可能不是一个不错的选择。如果是这样，CMake是一个不错的选择。
- 您是否需要担心交叉编译（通用应用程序/库，诸如Google Protobufs，Apache Thrift等之类的东西。应该对此进行关注...）？如果是这样，Autotools 可能只要您不必担心Windows，它就会为您工作，但是随着情况的变化，您将花费大量时间来维护配置系统。除非您使用的是Scratchbox2-，否则SCons目前几乎是不行的，除非它确实无法处理交叉编译，并且您将需要使用该可扩展性并以与您将使用Automake。如果是这样，您可能要考虑CMake，因为它支持交叉编译，而无需担心从沙箱中泄漏出来，并且可以使用/不使用Scratchbox2之类的东西，并且可以与OpenEmbedded之类的东西很好地集成在一起。
原因是很多项目放弃了qmake，Autotools等，而转移到CMake。到目前为止，我可以明确地期望基于CMake的项目陷入交叉编译的情况或进入VisualStudio安装程序，或者只需要少量清理，因为该项目没有考虑仅Windows或仅OSX的部分到代码库。我真的不能指望出SCons的基于项目和我完全相信1/3以上Autotools的项目已经得到SOMETHING错认为是正确的基础上，除了主机建立一个或Scratchbox2一个任何上下文排除了。