7.7 add_subdirectory的限定范围
NOTE:此示例代码可以在 https://github.com/dev-cafe/cmake-cookbook/tree/v1.0/chapter-7/recipe-07 中找到,其中有一个C++示例。该示例在CMake 3.5版(或更高版本)中是有效的,并且已经在GNU/Linux、macOS和Windows上进行过测试。
本章剩下的示例中,我们将讨论构建项目的策略,并限制变量的范围和副作用,目的是降低代码的复杂性和简化项目的维护。这个示例中,我们将把一个项目分割成几个范围有限的CMakeLists.txt文件,这些文件将使用add_subdirectory命令进行处理。
准备工作
由于我们希望展示和讨论如何构造一个复杂的项目,所以需要一个比“hello world”项目更复杂的例子:
我们的代码将能够计算任何256个基本细胞自动机,例如:规则90 (Wolfram代码):

我们示例代码项目的结构如下:
我们将代码分成许多库来模拟真实的大中型项目,可以将源代码组织到库中,然后将库链接到可执行文件中。
主要功能在src/main.cpp中:
external/conversion.cpp文件包含要从十进制转换为二进制的代码。
我们在这里模拟这段代码是由src外部的“外部”库提供的:
src/evolution/evolution.cpp文件为一个时限传播系统:
src/initial/initial.cpp文件,对出进行初始化:
src/io/io.cpp文件包含一个函数输出打印行:
src/parser/parser.cpp文件解析命令行输入:
最后,tests/test.cpp包含两个使用Catch2库的单元测试:
相应的头文件包含函数声明。有人可能会说,对于这个小代码示例,项目包含了太多子目录。请注意,这只是一个项目的简化示例,通常包含每个库的许多源文件,理想情况下,这些文件被放在到单独的目录中。
具体实施
让我们来详细解释一下CMake所需的功能:
CMakeLists.txt顶部非常类似于第1节,代码重用与函数和宏:目标和源在
src/CMakeLists.txt中定义(转换目标除外):转换库在
external/CMakeLists.txt中定义:src/CMakeLists.txt文件添加了更多的子目录,这些子目录又包含CMakeLists.txt文件。src/evolution/CMakeLists.txt包含以下内容:单元测试在
tests/CMakeLists.txt中注册:配置和构建项目产生以下输出:
最后,运行单元测试:
工作原理
我们可以将所有代码放到一个源文件中。不过,每次编辑都需要重新编译。将源文件分割成更小、更易于管理的单元是有意义的。可以将所有源代码都编译成一个库或可执行文件。实际上,项目更喜欢将源代码编译分成更小的、定义良好的库。这样做既是为了本地化和简化依赖项,也是为了简化代码维护。这意味着如在这里所做的那样,由许多库构建一个项目是一种常见的情况。
为了讨论CMake结构,我们可以从定义每个库的单个CMakeLists.txt文件开始,自底向上进行,例如src/evolution/CMakeLists.txt:
这些单独的CMakeLists.txt文件定义了库。本例中,我们首先使用add_library定义库名,然后定义它的源和包含目录,以及它们的目标可见性:实现文件(evolution.cpp:PRIVATE),而接口头文件evolution.hpp定义为PUBLIC,因为我们将在main.cpp和test.cpp中访问它。定义尽可能接近代码目标的好处是,对于该库的修改,只需要变更该目录中的文件即可;换句话说,也就是库依赖项被封装。
向上移动一层,库在src/CMakeLists.txt中封装:
文件在主CMakeLists.txt中被引用。这意味着使用CMakeLists.txt文件,构建我们的项目。这种方法对于许多项目来说是可用的,并且它可以扩展到更大型的项目,而不需要在目录间的全局变量中包含源文件列表。add_subdirectory方法的另一个好处是它隔离了作用范围,因为子目录中定义的变量在父范围中不能访问。
更多信息
使用add_subdirectory调用树构建项目的一个限制是,CMake不允许将target_link_libraries与定义在当前目录范围之外的目标一起使用。对于本示例来说,这不是问题。在下一个示例中,我们将演示另一种方法,我们不使用add_subdirectory,而是使用module include来组装不同的CMakeLists.txt文件,它允许我们链接到当前目录之外定义的目标。
CMake可以使用Graphviz图形可视化软件(http://www.graphviz.org )生成项目的依赖关系图:
生成的图表将显示不同目录下的目标之间的依赖关系:

本书中,我们一直在构建源代码之外的代码,以保持源代码树和构建树是分开的。这是推荐的方式,允许我们使用相同的源代码配置不同的构建(顺序的或并行的,Debug或Release),而不需要复制源代码,也不需要在源代码树中生成目标文件。使用以下代码片段,可以保护您的项目免受内部构建的影响:
认识到构建结构与源结构类似很有用。示例中,将message打印输出插入到src/CMakeLists.txt中:
在build下构建项目时,我们将看到build/src的打印输出。
在CMake的3.12版本中,OBJECT库是组织大型项目的另一种可行方法。对我们的示例的惟一修改是在库的CMakeLists.txt中。源文件将被编译成目标文件:既不存档到静态库中,也不链接到动态库中。例如:
主CMakeLists.txt保持不变:automata可执行目标将这些目标文件链接到最终的可执行文件。使用也有要求需求,例如:在对象库上设置的目录、编译标志和链接库,将被正确地继承。有关CMake 3.12中引入的对象库新特性的更多细节,请参考官方文档: https://cmake.org/cmake/help/v3.12/manual/cmake-buildsystem.7.html#object-libraries
Last updated
Was this helpful?