Достаточно одного 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

Я бы всегда рекомендовал файл CMakeList.txt для каждого каталога.Мои причины:

• местность: держите все в одной папке, которая принадлежит друг другу.Это включает в себя соответствующие части системы сборки.Мне бы не хотелось переходить в корневую папку, чтобы увидеть, как была вызвана библиотека или цель.
• разделение артефактов сборки и связанного кода сборки: тесты принадлежат ниже test, библиотеки ниже lib, двоичные файлы нижеbin, документация ниже doc и утилиты ниже utils.Это может варьироваться от проекта к проекту.Когда мне нужно внести изменения в документацию, зачем мне пробираться через десятки несвязанного кода CMake?Просто взгляните на правильный файл CMakeLists.txt.
• избегайте обработки путей: в большинстве случаев можно избежать относительных или абсолютных путей, включая такие, как ${CMAKE_CURRENT_SOURCE_DIR}.Это приводит к поддерживаемому коду сборки и уменьшает количество ошибок по неправильным путям.Особенно при сборке вне источника, которая должна использоваться в любом случае.
• локализация ошибок: если возникает ошибка CMake, проще найти проблему.Часто подкаталог может быть исключен в качестве первого обходного пути.

Answer 2

Это немного длинно для комментария - поэтому я делаю его ответом:

В одном из моих проектов (библиотека), у меня есть столько источников, что я начал перемещать некоторые из них вподкаталог 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_group s, который генерирует соответствующиеподпапки в проекте VS.Я считаю, что они называются «Фильтры».

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

Конечно, я должен учитывать также переменные utilHeaders и utilSources, где должны быть указаны источники:

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

Вот и все.

---

Фред напомнил в своем комментарии, что я не должен забывать упомянуть, что у file(GLOB есть определенная слабость (хотя я нахожу это очень ценным внаша ежедневная работа).Это даже упоминается в CMake doc. :

Примечание : мы не рекомендуем использовать GLOB для сбора списка исходных файлов из вашего исходного дерева,Если файл CMakeLists.txt не изменяется при добавлении или удалении источника, сгенерированная система сборки не может знать, когда попросить CMake сгенерировать заново.Флаг CONFIGURE_DEPENDS может работать не надежно на всех генераторах, или если в будущем будет добавлен новый генератор, который не сможет его поддерживать, проекты, использующие его, будут заблокированы.Даже если CONFIGURE_DEPENDS работает надежно, проверка каждой перестройки все еще требует затрат.

Поэтому, используя file(GLOB, вы никогда не должны забывать повторно запускать CMake один раз для файловбыли добавлены, перемещены или удалены.Альтернативой также может быть добавление, перемещение, удаление файлов непосредственно в сгенерированных встроенных скриптах (например, файлах проекта VS) и полагаться на тот факт, что при следующем повторном запуске CMake эти файлы также будут покрыты.И последнее, но не менее важное: git pull - это еще кое-что, что стоит рассмотреть повторный запуск CMake.