CMake 新手想了解哪些尘土飞扬的角落？
我做过很多项目以及很多不同的构建系统和 CI 工具。最近，我遇到了偶尔具有挑战性的任务，即为合理大小的 C++ 应用程序添加基于自动工具的环境。虽然我喜欢最终用户的易用性，但我不太喜欢在开发人员方面处理 m4 和所有 auto* 工具。
我正在利用业余时间从事一个相当大的副项目，并决定尝试一下 CMake。因为我才刚刚开始，所以我显然打算深入研究文档、常见问题解答、维基百科等，并边做边学。顺便说一句，我愿意花钱买《掌握 CMake》一书，但我在亚马逊上找到的评论足以让我决定这可能不值得花钱。话虽这么说，在任何新事物中，经常会出现新人经常会遇到的“陷阱”，而老专家早已学会避免这些问题。我想知道这些是基于人们使用 CMake 的经验，我希望通过在这里询问来减轻我的学习痛苦。
我应该指出，我计划主要在 Linux 和其他 UN*X 变体上进行构建。从我的观点来看，Windows 并不是真正的问题。这是一个大型服务器端应用程序，具有供操作员使用的 Web 和 CLI 界面、用于自动化/与 OSS 工具集成的北向 REST 界面以及用于 CPE 的 SOAP 南向界面。我将需要大量第三方库和应用程序才能使这一切正常工作，除非我想在接下来的 10 年里手工构建这一切。 :)
I've done a lot of projects and a lot of different build systems and CI tools. Most recently, I've been exposed to the occasionally challenging task of adding to an autotools based environment for a reasonably sized C++ application. While I love the ease of use for the end user, I'm not so fond of dealing with m4 and all of the auto* tools from the developer side.
I'm working on a reasonably large side project in my spare time and have decided that I'd like to take CMake for a test drive. Since I'm just starting out, I'm obviously planning on digging through the documentation, FAQ, wikis, etc. and learning by doing. BTW, I'd fork over money for the "Mastering CMake" book, but the comments that I found on Amazon were enough to make me decide that it probably isn't worth the money. All that being said, in anything new there are often "gotchas" that a newcomer will often stumble over that the old pros have long since learned to avoid. I'm wondering what those are based on people's experience with CMake, and I'm hoping to cut my learning pains down a bit by asking here.
I should point out that I'm planning on building on Linux primarily, and other UN*X variants. Windows isn't really a concern from my POV. This is a large server-side application, with a Web and CLI interface for operators, a northbound REST interface for automation/integration with OSS tooling, and a SOAP southbound interface for CPEs. I'm going to need a lot of third-party libraries and applications to get this all to work unless I want to take the next 10 years to build this all by hand. :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先，我认为 CMake 是一个优秀的构建工具。在我看来，它具有迄今为止对多平台构建的最佳支持，并且具有用于查找第 3 方库的强大机制。与 CPack 相结合，它甚至可以提供合理的打包和安装选项。一些提示和可能的问题：
始终以源代码外构建为目标：一个明显的问题是：对于为源代码内构建而设计的项目来说，要使其在源代码外构建可能很困难。因此，如果您可以从一开始就设计它，那么就以源代码外构建为目标。
语法：语法可能很奇怪，有很多奇怪的怪癖，尽管自 2.6 和 2.8 版本以来这已经变得更好了。
变量的缓存。 CMake 会跟踪变量和设置的缓存，有时这在重建某些内容时可能会出现问题。尝试删除 CMakeCache.txt （或清理源外构建目录）并重建。 DarenW也提到了这一点。
查找和配置第 3 方库：如果您有一个大型项目依赖于多个库（您自己的库或第 3 方库），这可能是最麻烦的。
我强烈建议深入研究 find_package 命令。它非常强大，但完全取决于 FindXXX.cmake 文件的质量。特别是在多个平台（主要是 Windows 和 Mac）上构建时，这些文件可能需要一些调整，或者您可能需要编写自己的文件。
链接库的问题（例如调试“未定义的引用”或 debug|release 或 static|shared 之间的不匹配）可能很难调试。特别是对于第 3 方库，这些问题可能是由不正确的第 3 方 FindXXX.cmake 文件引起的...
First of all, I think CMake is an excellent build-tool. It has in my opinion by far the best support for multi-platform-builds and has a powerful mechanism for finding 3rd-party libraries. Combined with CPack it even provides reasonable options for packaging and installation. Some hints and possible problems:
Always aim for out-of-source builds: An obvious one: It can be difficult for a project designed for in-source builds to get it built out-of-source. So, if you can design it from the start, aim for out-of-source builds.
Syntax: The syntax can be bizarre with a lot of strange quirks, although this is getting better since the 2.6 and 2.8 versions.
Caching of variables. CMake keeps track of a cache of variables and settings and sometimes this can be a problem when rebuilding something. Try to remove the CMakeCache.txt (or clean your out-of-source build-directory) and rebuild. This one is also mentioned by DarenW.
Finding and configuring 3rd-party libraries: If you have a large project depending on several libraries (your own or 3rd-party), this will likely be the most troublesome.
I seriously recommend diving into the find_package command. It is very powerful, but fully depends on the quality of the FindXXX.cmake files. Especially when building on multiple platforms (mostly Windows and Mac), these files may require some tweaking or you may need to write your own.
Problems with linking libraries like debugging "undefined references" or mismatches between debug|release or static|shared can be difficult to debug. Especially with 3rd-party libraries these problems may be caused by incorrect 3rd-party FindXXX.cmake files...
我花了一段时间才弄清楚一件事：如果由于我更改了编译器选项、添加/删除了 .c 文件、与支持库版本混淆等而导致构建出现了混乱，那么最好删除从头开始构建树并运行 CMake。否则，即使 CMake 和 make 似乎完成了它们的工作，生成的可执行文件也会崩溃。
可能是我们“没有做对”，但这正在成为许多工具、语言、框架等的常见问题。不可能每个人都精通他们所依赖的所有软件，并且“没有做”即使对于专业人士来说，“正确”也是完成许多事情的唯一方法。 CMake 在很多事情上都非常聪明，但不是所有事情。破坏构建树仍然是我们项目中常用的技术。
One thing that took me a while to figure out: if anything goes haywire with a build because I've changed a compiler option, added/removed a .c file, had confusion with support library versions, etc. - it's best to delete the build tree and run CMake from scratch. Otherwise, even though CMake and
makeseem to do their job, the resulting executable crashes.It could be we're "not doing it right", but that's becoming a common problem with many tools, languages, frameworks, etc. It's not possible for everyone to be expert at all the software they depend on, and "not doing it right" is the only way a lot of things get done even among professionals. CMake is pretty smart about a lot of things, but not everything. Nuking the build tree remains a commonly used technique on our project.