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

Question

我正在尝试将我的旧 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 的一个很好的理由，那就是模块化。

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

Answer 1

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

在我的一个项目（图书馆）中，我有很多资源，因此我开始将其中一些移动到子目录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 和utilSources 以及必须提供源代码的位置：

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

就是这样。

---

Fred 在他的评论中提醒，我不应该忘记提到file(GLOB 有一定的弱点（尽管我发现它在我们的日常工作中非常有价值）。 CMake doc.中甚至提到了这一点：

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

因此，使用file(GLOB，您永远不要忘记在添加、移动或删除文件后重新运行 CMake。另一种选择是直接在生成的内置脚本（例如 VS 项目文件）中添加、移动、删除文件，并依赖于 CMake 的下一次重新运行将覆盖这些文件的事实。最后但同样重要的是，git pull 是值得考虑重新运行 CMake 的其他内容。

Answer 2

我总是推荐每个目录一个 CMakeList.txt 文件。我的理由：

• locality：将所有内容保存在同一个文件夹中。这包括构建系统的相关部分。我讨厌它导航到根文件夹以查看如何调用库或目标。
• 构建工件和相关构建代码的分离：测试属于test，库属于lib，二进制文件属于bin，文档属于doc，实用程序属于utils。这可能因项目而异。当我必须对文档进行更改时，我为什么要翻阅几十个不相关的 CMake 代码？只需查看正确的 CMakeLists.txt。
• 避免处理路径：在大多数情况下，可以避免包括${CMAKE_CURRENT_SOURCE_DIR} 之类的相对或绝对路径。这会导致可维护的构建代码并减少错误路径造成的错误。尤其是外源构建，无论如何都应该使用它。
• 错误的本地化：如果发生 CMake 错误，则更容易定位问题。通常可以排除子目录作为第一个解决方法。