Build CMake的新来者想知道哪些尘土飞扬的角落？

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

我在业余时间从事一个相当大的辅助项目，并决定带CMake进行试驾。因为我才刚刚开始，我显然计划在文档、常见问题解答、维基等方面进行挖掘，并在实践中学习。顺便说一句，我愿意花钱买《精通CMake》这本书，但我在亚马逊上看到的评论足以让我觉得这本书可能不值得。尽管如此，在任何新事物中，新来者往往会绊倒“陷阱”，而老职业选手早就学会了避免。我想知道这些都是基于人们对CMake的经验，我希望通过在这里提问来减轻我的学习痛苦

---

我应该指出，我计划主要在Linux和其他UN*X变体上构建。从我的观点来看，Windows并不是一个真正的问题。这是一个大型服务器端应用程序，具有用于操作员的Web和CLI界面、用于自动化/与OSS工具集成的北向REST界面，以及用于CPE的SOAP南向接口。我需要大量的第三方库和应用程序来实现这一切，除非我想在接下来的10年内手工构建这一切。：）

有一件事我花了一段时间才弄明白：如果由于我更改了编译器选项、添加/删除了.c文件、与支持库版本混淆等原因导致构建出现问题，那么最好删除构建树并从头开始运行CMake。否则，即使CMake和

使

似乎完成了它们的工作，结果是可执行文件崩溃

---

这可能是因为我们“做得不好”，但这正成为许多工具、语言、框架等的常见问题。不可能每个人都精通他们所依赖的所有软件，而且“做得不好”是很多事情的唯一方法，即使是在专业人士中也是如此。CMake在很多事情上都很聪明，但不是所有事情。Nuking the build tree仍然是我们项目中常用的技术。

首先，我认为CMake是一个优秀的构建工具。在我看来，它是迄今为止对多平台构建的最佳支持，并且具有查找第三方库的强大机制。结合CPack，它甚至为包装和安装提供了合理的选择。一些提示和可能的问题：

始终以源代码外构建为目标：一个显而易见的问题是：为源代码内构建设计的项目很难从源代码外构建。因此，如果您可以从一开始就设计它，那么就要以源代码外构建为目标

语法：语法可能很奇怪，有很多奇怪的怪癖，尽管从2.6和2.8版本开始，这已经变得更好了

缓存变量。CMake跟踪变量和设置的缓存，有时在重建某些内容时会出现问题。尝试删除cmakcache.txt（或清除源代码外生成目录）并重新生成。DarenW也提到了这一点

查找和配置第三方库：如果您有一个依赖于多个库（您自己的或第三方的）的大型项目，这可能是最麻烦的

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

• 链接库的问题，如调试“未定义的引用”或调试|发布或静态|共享之间的不匹配，可能很难调试。特别是对于第三方库，这些问题可能是由不正确的第三方FindXXX.cmake文件引起的

---

是的，我去过好几次，当你在墙上敲打你的头，找出你的自定义脚本中缺少的依赖项或其他奇怪的部分后，除了把它吹走并从头开始尝试之外，什么都不管用。糟糕透了，但事实往往是，在某个时刻，你需要割断并跑开，然后把这该死的东西建起来(