cmake：add_subdirectory()vs include()

cmake: add_subdirectory() vs include()

假设我有一个使用cmake的C ++单元测试项目，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

$ tree
.
├── C-API-ConditionVariable-unit-test
│ ├── C-API-ConditionVariable-compile-link-test.c
│ ├── C-API-ConditionVariable-unit-test-0.cpp
│ └── C-API-ConditionVariable-unit-test-1.cpp
├── C-API-Mutex-unit-test
│ ├── C-API-Mutex-compile-link-test.c
│ ├── C-API-Mutex-unit-test-0.cpp
│ └── C-API-Mutex-unit-test-1.cpp
├── some
│ └── deeply
│ └── nested
│ └── path
│ └── SomeFeature-unit-test
│ ├── SomeFeature-compile-link-test.c
│ ├── SomeFeature-unit-test-0.cpp
│ └── SomeFeature-unit-test-1.cpp
└── CMakeLists.txt

子文件夹中的每个源文件都会创建一个单独的可执行文件。我希望项目中的每个子文件夹都是一个非独立的模块-也就是说，每个子文件夹都是(或多或少)独立的，但不是一个可以单独编译的独立的cmake项目。我希望只能构建所有内容或一无所获。例如，我不想给人一种印象，即您只能从some/deeply/nested/path/SomeFeature-unit-test运行cmake来构建它。

我应该选择哪个选项？

每个子文件夹中的CMakeLists.txt文件+顶级CMakeLists.txt中的add_subdirectory()

每个子文件夹中的some-random-name.cmake +顶级CMakeLists.txt中的include();

忽略我关于每个子文件夹都是独立的想法，并将所有相关的构建信息放置在顶级CMakeLists.txt中，其他cmake文件仅用作帮助程序(宏，函数等)；

第一个选项最方便，但是它建议每个子文件夹实际上是一个独立的项目，可以单独编译。

第二种选择似乎清楚地表明这里只有一个cmake项目。但是，然后在子文件夹的每个some-random-name.cmake中，我必须使用完整路径来获取文件，这与我希望每个文件都独立的想法背道而驰。如果只有一个嵌套级别(例如前两个示例子文件夹)，就可以了，但是对于some/deeply/nested/path/SomeFeature-unit-test来说就不太好了。我还必须在输出文件的名称前加上前缀。

第三种选择似乎是一种快速创建长度为意大利面条的CMakeLists.txt文件的简便方法，因此我可能希望使用其他方法。

我想知道在"现代" cmake项目中哪种是"首选"方式。在一个目录中有一个独立的库，在另一个文件夹中有一个使用该库的独立应用程序，而在另一个目录中有一个同一个库的独立测试，我可以找到的多目录项目的所有教程都涉及这种情况。使用cmake查看项目时，我看不到一致性，所以这没有太大帮助。

(我是一个cmake菜鸟，试图将一个相对较大的项目转换为使用cmake)