我做过很多项目，也做过很多不同的构建系统和 CI 工具。最近，我接触到了偶尔具有挑战性的任务，即为合理大小的 C++ 应用程序添加基于自动工具的环境。虽然我喜欢最终用户的易用性，但我不太喜欢处理 m4 和开发人员方面的所有 auto* 工具。

我在业余时间从事一个相当大的副项目，并决定使用 CMake 进行试驾。由于我才刚刚开始，我显然计划通过文档、FAQ、wiki 等进行挖掘，并边做边学。顺便说一句，我会为“Mastering CMake”一书付钱，但我在亚马逊上找到的评论足以让我决定它可能不值得花钱。话虽如此，在任何新事物中，经常会有新手经常会遇到的“陷阱”，而老职业玩家早就学会了避免这些“陷阱”。我想知道这些是基于人们使用 CMake 的经验，我希望通过在这里提问来减少我的学习痛苦。

我应该指出，我计划主要在 Linux 和其他 UN*X 变体上构建。 Windows 并不是我 POV 真正关心的问题。这是一个大型服务器端应用程序，具有用于运算符(operator)的 Web 和 CLI 接口(interface)、用于自动化/与 OSS 工具集成的北向 REST 接口(interface)以及用于 CPE 的 SOAP 南向接口(interface)。我将需要大量第三方库和应用程序才能让这一切正常工作，除非我想在接下来的 10 年内手动构建这一切。 :)

最佳答案

首先，我认为 CMake 是一个出色的构建工具。在我看来，它是迄今为止对多平台构建的最佳支持，并且具有查找 3rd-party 库的强大机制。与 CPack 结合使用，它甚至为打包和安装提供了合理的选择。一些提示和可能的问题:

1. 始终以源代码外构建为目标:一个显而易见的问题:一个专为源代码构建而设计的项目很难在源代码外构建它。所以，如果你能从一开始就设计它，那么就瞄准外源构建。

2. 语法:语法可能很奇怪，有很多奇怪的怪癖，尽管自 2.6 和 2.8 版本以来这种情况变得更好。

3. 缓存变量。 CMake 会跟踪变量和设置的缓存，有时在重建某些内容时可能会出现问题。尝试删除 CMakeCache.txt(或清理您的源外构建目录)并重建。 DarenW也提到了这个。

4. 查找和配置第 3 方库:如果您有一个依赖于多个库(您自己或第 3 方)的大型项目，这可能是最麻烦的。

   • 我强烈建议深入研究 find_package 命令。它非常强大，但完全取决于 FindXXX.cmake 文件的质量。尤其是在多个平台(主要是 Windows 和 Mac)上构建时，这些文件可能需要一些调整，或者您可能需要自己编写。

   • 链接库的问题，如调试“ undefined reference ”或 debug|release 或 static|shared 之间的不匹配可能很难调试。特别是对于 3rd-party 库，这些问题可能是由不正确的 3rd-party FindXXX.cmake 文件引起的......

https://stackoverflow.com/questions/4506193/