适用于 Windows 和 Linux 编译的 Autotools 与 CMake

Question

我一直在寻找专业人士和专业人士。 Autotools 和 CMake 的缺点。但我想了解在项目中使用过其中一种（或两种）工具的人们的意见。

一年前我基本上使用了 Autotools，我知道它的一个优点是它依赖于 shell 脚本，因此不需要安装即可运行并使用可移植的 shell 脚本。但看起来它太面向unix了，在Windows上运行配置文件是不可能的。

我现在必须为开源项目选择一个构建系统工具，该工具必须是至少为 Linux 和 Linux 编译视窗。它是用 C++ 编写的，并使用 Qt GUI 前端，其余部分是“通用的”。

谢谢你的帮助。

Answer 1

2019 年 1 月 16 日更新：随着工具的发展完善建议。

我之前已经使用过自动工具相当长一段时间了。

目前，我仅在需要时才大量使用 meson 和 cmake。

一些个人建议：

1. 对于大型团队，如果您想使用 XCode 的生成器，请坚持使用 CMake。如果你不需要它，我会直接使用Meson。 Meson，从版本 0.49 开始，还支持查找 CMake 配置文件（尽管我还没有测试它的效果如何）。另外，Visual Studio 目前似乎得到了足够好的支持，尽管我自己没有尝试过。 CMake 的优势在于它与 Visual Studio 集成。

2. 删除自动工具。介子已经很好地涵盖了一切。他们的交叉编译模型非常容易理解。在 CMake 中，我上次检查时，一切都变得更加困难。

我还尝试过 scons， waf 和 tup。

功能最齐全的跨平台系统是CMake，但是 meson 的 DSL 对于习惯 python 和其他语言的人来说会更容易使用。 Meson 也开始支持 VS（VS2015 生成器），并且一些项目已经对其提供了实验性支持，例如 gstreamer。 Gstreamer 在 Windows 中也可以使用 meson 编译。现在有 VS2015 生成器和 VS2017，但我最近没有尝试自己使用生成器。截至介子 0.37.1 需要一些工作，但他们正在改进它们，当前版本已经是 0.40。

介子

优点：

• DSL 根本不会妨碍。事实上，它非常好用且熟悉，基于 python。
• 深思熟虑的交叉编译支持。
• 这些对象都是强类型的：您不能轻易犯字符串替换错误，因为对象是诸如“依赖关系”、“包含目录”等实体。
• 如何为您的工具之一添加模块是非常明显的。
• 交叉编译似乎更容易使用。
• 确实是想得很周到。 Meson 的设计者和主要作者知道什么
  他在设计构建系统时谈得很好。
• 非常非常快，尤其是在增量构建中。
• 该文档比 cmake 中的文档好 10 倍。访问 http://mesonbuild.com，您会找到教程、操作方法和很好的参考。它并不完美，但确实是可以发现的。

缺点：

• 虽然不如 CMake 成熟，但我认为它已经完全可用于 C++。
• 不过可用的模块并不多，gnome、qt 和常见的模块已经有了。
• 项目生成器：似乎 VS 生成器目前工作得不太好。 CMake 项目生成器要成熟得多。
• 具有 python3 + ninja 依赖项。

Cmake

优点：

• 为许多不同的 IDE 生成项目。对于团队来说，这是一个非常的好功能。
• 与自动工具不同，可以很好地与 Windows 工具配合使用。
• 成熟，几乎是事实上的标准。
• Microsoft 正在致力于 Visual Studio 的 CMake 集成。

缺点：

• 它不遵循任何众所周知的标准或指南。
• 没有卸载目标。
• DSL 很奇怪，当你开始进行比较等，以及字符串与列表或转义字符时，你会犯很多错误，我很确定。
• 交叉编译很糟糕。

Autotools

优点：

• 最强大的交叉编译系统，恕我直言。
• 生成的脚本除了 make、shell 和编译器（如果需要它来构建）之外不需要任何其他东西。
• 命令行非常好并且一致。
• Unix 世界的标准，有很多文档。
• 真正强大的命令行：更改安装目录，卸载，
  重命名二进制文件...
• 如果您的目标是unix，使用此工具打包源代码确实很方便。

缺点：

• 它不能很好地与微软工具配合使用。真正的精彩表演。
• 学习曲线是......嗯......但实际上我可以说 CMake 也不是那么容易。
• 递归 make 的使用在遗留项目中很普遍。 Automake 支持非递归构建，但它不是一种使用非常广泛的方法。

关于学习曲线，有两个非常好的来源可以学习：

• 网站此处
• 本书此处

第一个来源将使您更快地启动和运行。本书对此进行了更深入的讨论。

从 Scons、waf 和 tup 来看，Scons 和 tup 更像 make。 Waf 更像是 CMake 和自动工具。我一开始尝试了waf而不是cmake。我认为它是过度设计的，因为它具有完整的 OOP API。这些脚本看起来一点也不短，而且工作目录的内容和相关的内容确实让我感到困惑。最后，我发现autotools和CMake是更好的选择。这 3 个构建系统中我最喜欢的是 tup。

Tup

优点

• 确实正确。
• 快得离谱。你应该尝试一下才能相信。
• 该脚本语言依赖于一个非常简单的想法，可以在 10 分钟内理解。

缺点

• 它没有功能齐全的配置框架。
• 我找不到制作诸如 doc 之类的目标的方法，因为
  它们生成我不知道的文件，并且它们必须在生成之前列在输出中，或者至少，这是我现在的结论。如果是的话，这真是一个令人烦恼的限制，因为我不确定。

总而言之，我现在对于新项目唯一考虑的是 Cmake 和 Meson。当我有机会时，我也会尝试 tup，但它缺少配置框架，这意味着当您需要所有这些东西时，它会让事情变得更加复杂。另一方面，它的速度确实很快。

Answer 2

我不推荐 Windows 下的自动工具。使用 CMake。

为什么？ Windows 没有原生的 sh.exe，并且模拟速度很慢。配置也很容易出错。我并不是说这在 CMake 中是不可能的，但 CMake 肯定会抽象出更多内容，因此您担心的事情会更少。 CMake 文档可能有点难以阅读，但一旦设置完毕，您应该可以轻松使用 CMake 支持的所有工具链。 CMake 还集成了测试、打包等...

Autotools 在 Windows 上速度很慢，不能轻松地与 MSVC 一起工作，并且与 Windows（和其他操作系统）有奇怪的怪癖，难以调试和修复。 libtool 在 Windows 上也很糟糕，即使你认为它应该并且可以，它也经常拒绝构建共享库。工具链重定位问题在 libtool 中也很普遍，它可能会查看用户工具链中的错误文件。 CMake 在这方面要容易得多。它假设目标平台的正常情况并创建通用且良好的构建指令。

此外，CMake 还具有彩色输出:) 和不错的进度百分比。

PS：作为用户，我只是对 Windows 上的 CMake 和 autotools 有一些经验。 CMake 往往会工作，自动工具往往会在你不看的时候咬掉你的耳朵，当它由于一些奇怪的错误而失败时会对你微笑......