15.8 项目转换为CMake的常见问题

我们总结一下,在这一章中所所学到的知识。

代码修改总结

在本章中,讨论了如何将项目移植到CMake进行构建。我们以Vim项目为例,添加了以下文件:

.
├── CMakeLists.txt
└── src
    ├── autogenerate.cmake
    ├── CMakeLists.txt
    ├── config.h.cmake.in
    ├── libvterm
    │    └── CMakeLists.txt
    ├── pathdef.c.in
    └── testdir
        ├── CMakeLists.txt
        └── test.cmake

可以在线查看修改: https://github.com/dev-cafe/vim/compare/b476cb7...cmake-support

为了简单起见,我们省略了许多选项和调整,并将重点放在最重要的步骤上。

常见问题

在结束讨论之前,我们想指出一些迁移到CMake时常见的问题。

  • 全局变量代码异味:这点适用于任何编程语言,CMake也不例外。跨CMake文件的变量,特别是从子到父CMakeLists.txt文件的“向上”传递的变量,这是明显的“异味代码”。通常,会有一种更好的方法来传输依赖关系。理想情况下,依赖项应该通过目标导入。与其将库列表组装成一个变量并在文件之间携带该变量,不如逐个链接到定义库的地方。不是将源文件组装成变量,而是使用target_sources添加源文件。当链接到库时,在可用时使用导入的目标,而不是变量。

  • 最小化顺序的影响:CMake不是一种声明性语言,但是也不应该使用命令式范式进行处理。执行严格命令的代码往往是脆弱的,这也与变量有关(见上一段)。一些语句和模块的顺序是必要的,但是为了实现健壮的CMake框架,我们应该避免不必要的顺序强制。应该多使用target_sourcestarget_compile_definitiontarget_include_directorytarget_link_libraries。避免使用全局范围语句,如add_definitioninclude_directorylink_libraries,从而避免定义全局编译标志。如果可能,为每个目标定义编译标志。

  • 不在build目录之外生成文件:强烈建议不要将生成的文件放在构建目录之外。原因是生成的文件通常依赖于所选择的选项、编译器或构建类型。如果写入原目录树,我们就放弃了用同一套源码维护多个构建的可能性,并且会使构建步骤的重现复杂化。

  • 尽可能使用函数,而不是宏:它们的作用范围不同,功能范围也有限定。所有变量修改都需要显式标记,这也向读者展示了重新定义的变量。如果可以最好使用函数,必要时再使用宏。

  • 避免shell命令:Shell可能不能移植到其他平台(如Windows)。可以使用CMake中的命令或函数。如果没有可用的CMake等效函数,请考虑调用Python脚本。

  • Fortran中,注意后缀:需要预处理的Fortran源文件是大写的.F90后缀。无预处理的源文件应该以.f90为后缀。

  • 避免显式路径:这条建议在定义目标和引用文件时都适用。当引用当前路径时,可使用CMAKE_CURRENT_LIST_DIR。这样做的好处是,当移动或重命名一个目录时,构建不会出问题。

  • 不应该在函数调用中进行模块包含:将CMake代码模块化是一个很好的策略,但是包含模块不应该执行CMake代码。相反,将CMake代码封装到函数和宏中,并在包含模块之后显式地调用这些函数和宏。当意外地多次包含模块时,这条建议可以防止意外的副作用,并使执行CMake代码模块的操作更易读。

Last updated