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

$ 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来构建它。
我应该选择哪个选项？
1.每个子文件夹中的CMakeLists.txt文件+顶层CmakeLists.txt中的add_subdirectory();
1.每个子文件夹中的some-random-name.cmake+顶层CmakeLists.txt中的include();
1.忽略我的想法，每个子文件夹是独立的，并把所有相关的构建信息放在顶层CMakeLists.txt，额外的cmake文件只作为助手（宏，函数，...）;
第一个选项是最方便的，但它建议每个子文件夹实际上都是一个独立的项目，可以单独编译。
第二个选项似乎清楚地表明这里只有一个cmake项目。但是在子文件夹中的每个some-random-name.cmake中，我必须使用源文件的完整路径，这与我希望每个源文件都是独立的愿望相违背。如果只有一层嵌套（就像前两个示例子文件夹）这是可以的，但对于some/deeply/nested/path/SomeFeature-unit-test这就不那么好了。我还必须为输出文件的名称加前缀。
第三个选项似乎是快速创建一个长度为意大利面条的CMakeLists.txt文件的简单方法，所以我可能更喜欢其他的东西。
我想知道在一个“现代”的cmake项目中，哪种方法是“首选”的。我能找到的所有多目录项目的教程都涉及到这样的情况：一个文件夹中有一个独立的库，另一个文件夹中有一个使用该库的独立应用程序，而另一个目录中有使用同一库的独立测试。查看使用cmake的项目，我发现没有一致性，所以这没有多大帮助。
（我是一个cmake新手，正在尝试将一个相对较大的项目转换为使用cmake）