单个 CMakeLists.txt 足以满足我的项目需求吗？

我正在尝试将旧的 CMake 移植到现代 CMake（CMake 3.0.2 或更高版本）。在旧的设计中，我有多个 CMakelists.txt，每个目录都包含一个 CMakeLists.txt 文件。

我当前项目的目录结构如下所示：

.
├── VizSim.cpp
├── algo
├── contacts
│   ├── BoundingVolumeHierarchies
│   │   └── AABBTree.h
│   └── SpatialPartitoning
├── geom
│   └── Geometry.h
├── math
│   ├── Tolerance.h
│   ├── Vector3.cpp
│   └── Vector3.h
├── mesh
│   ├── Edge.h
│   ├── Face.h
│   ├── Mesh.cpp
│   ├── Mesh.h
│   └── Node.h
├── util
|   |__ Defines.h
|   |__ Math.h
|
└── viz
    └── Renderer.h

我打算做的只是使用一个 CMakelists.txt 并将所有 cpp 文件放在 SOURCE 中，将所有标头放在 HEADER 中，然后使用 add_executable。

set (SOURCE
    ${SOURCE}
    ${CMAKE_CURRENT_SOURCE_DIR}/src/mesh/Mesh.cpp
    ${CMAKE_CURRENT_SOURCE_DIR}/src/math/Vector3.cpp
    ${CMAKE_CURRENT_SOURCE_DIR}/src/VizSim.cpp
    ....
)

set (HEADER
    ${HEADER}
    ${CMAKE_CURRENT_SOURCE_DIR}/src/mesh/Mesh.h
    ${CMAKE_CURRENT_SOURCE_DIR}/src/math/Vector3.h
    .... 
)

add_library(${PROJECT_NAME} SHARED ${SOURCE})

这样做我担心使用单个 CMakeLists.txt 是否是一个好的做法。那么单个 CMakeLists.txt 就足够了，还是每个文件夹都需要一个 CMakeLists.txt ？

我只能想到一个在我的项目中拥有多个 CMakeLists.txt 的充分理由，那就是模块化。

考虑到我的项目最终会成长。

对于评论来说有点长——所以我把它作为一个答案：

在我的一个项目（一个库）中，我有很多源，我开始将其中一些源移动到子目录中util.

为此，我创建了单独的变量：

file(GLOB headers *.h)
file(GLOB sources *.cc)
file(GLOB utilHeaders
  RELATIVE ${CMAKE_CURRENT_SOURCE_DIR}
  ${CMAKE_CURRENT_SOURCE_DIR}/util/*.h)
file(GLOB utilSources
  RELATIVE ${CMAKE_CURRENT_SOURCE_DIR}
  ${CMAKE_CURRENT_SOURCE_DIR}/util/*.cc)

为了使其在 VisualStudio 中美观/更方便，我插入了source_groups 在 VS 项目中生成适当的子文件夹。我相信它们被称为“过滤器”。

source_group("Header Files\\Utilities" FILES ${utilHeaders})
source_group("Source Files\\Utilities" FILES ${utilSources})

当然，我必须考虑变量utilHeaders and utilSources以及必须提供来源的地方：

add_library(libName
  ${sources} ${headers}
  ${utilSources} ${utilHeaders})

就是这样。

Fred https://stackoverflow.com/users/1028434/fred在他的评论中提醒我不应该忘记提及这一点file(GLOB有一定的弱点（尽管我发现它在我们的日常工作中非常有价值）。这甚至在CMake 文档。 https://cmake.org/cmake/help/latest/command/file.html#filesystem:

Note：我们不建议使用 GLOB 从源树中收集源文件列表。如果添加或删除源时 CMakeLists.txt 文件没有更改，则生成的构建系统无法知道何时要求 CMake 重新生成。这CONFIGURE_DEPENDSflag 可能无法在所有生成器上可靠地工作，或者如果将来添加无法支持它的新生成器，则使用它的项目将被卡住。即使CONFIGURE_DEPENDS工作可靠，但每次重建时执行检查仍然有成本。

所以，使用file(GLOB，一旦添加、移动或删除文件，您不应该忘记重新运行 CMake。另一种选择是直接在生成的内置脚本（例如 VS 项目文件）中添加、移动、删除文件，并依赖于下一次重新运行 CMake 也将覆盖这些文件。最后但并非最不重要的一点是，git pull还有其他值得考虑重新运行 CMake 的事情。