Пункт 1 - Нужно ли создавать отдельный файл CMakeLists.txt для каждой папки (да, для простоты будем называть это папкой)?
Вам следует создать отдельную папку для каждойбиблиотека или исполняемый файл.(Хотя также возможно создание нескольких проектов для исполняемых файлов из одной папки. Я иногда использую эту опцию для папок с несколькими небольшими тестовыми приложениями.)
Для папок с подпапками вам может понадобиться CMakeLists.txtкоторый содержит только add_subdirectory() команд.(См. Пример ниже.)
Можно даже создать CMakeLists.txt, который рассматривает источники из нескольких подпапок.Я однажды написал ответ по этому поводу.( ТАК: достаточно одного CMakeLists.txt для моего проекта? ) Хотя, посмотрите на голоса - не так много людей, которые считают это хорошей идеей.; -)
Пункт 2 - Очевидно, ответом на пункт 1 является НЕТ.Я нашел эти команды для автоматизации поиска * .cpp файлов
Мы широко используем его, но есть и рекомендации не делать этого.
Недостатком является то, что ваша цепочка сборкине распознает автоматически при добавлении новых источников.Если вы явно дадите имена всем источникам в CMakeLists.txt, это может быть предоставлено.
С CMake doc. :
Примечание : Мы не рекомендуем использовать GLOB для сбора списка исходных файлов из дерева исходных текстов.Если файл CMakeLists.txt не изменяется при добавлении или удалении источника, сгенерированная система сборки не может знать, когда попросить CMake сгенерировать заново.Флаг CONFIGURE_DEPENDS может работать не надежно на всех генераторах, или если в будущем будет добавлен новый генератор, который не сможет его поддерживать, проекты, использующие его, будут заблокированы.Даже если CONFIGURE_DEPENDS работает надежно, проверка каждой перестройки все еще требует затрат.
Поэтому, используя file(GLOB, вы никогда не должны забывать перезапускать CMake явно один раз.файлы были добавлены, перемещены или удалены.
Пункт 3 - Кажется, нет необходимости упоминать файл * .hpp.(Это смутное замечание)
Да, это не обязательно, поскольку включаемые файлы упоминаются в файлах cpp.С другой стороны, мы используем CMake с VS2013.Хорошо, если вы найдете все заголовки в соотв.Папка проекта VS.Итак, я бы рекомендовал упомянуть и о включении.(Похоже, что CMake достаточно умен, чтобы отделить их от источников. Поэтому он не будет создавать команды сборки для заголовочных файлов.)
Пункт 4 - Теперь у меня есть сравнительно большой проект (разработанный в Eclipse).для любой причины).Но мне нужно создать для него файл cmake и, следовательно, не использовать eclipse для сборки.
CMake - сборщик скриптов сборки.Мы используем его для создания решений и проектов VS.Я уверен, что он также может создавать Makefiles для Linux.К сожалению, у меня нет практического опыта по этому поводу.(На самом деле, именно по этой причине мы перешли на CMake - чтобы можно было переносить сборку нашего портативного письменного исходного кода.
Кстати. Есть введение в cmake.org:
CMake Tutorial
Пример:
Представьте себе следующее дерево каталогов для приложения myApp:
└─ MyApp/
├─ main/
│ ├─ CMakeLists.txt
│ └─ myApp.cc
├─ gui/
│ ├─ CMakeLists.txt
│ ├─ guiMainWindow.cc
│ └─ guiMainWindow.h
├─ model/
│ ├─ CMakeLists.txt
│ ├─ model.cc
│ └─ model.h
└─ CMakeLists.txt
* * MyApp/CMakeLists.txt не отвечает за исходный код, но собирает сценарии сборки подпапок. Это может выглядеть так:
# MyApp/CMakeLists.txt
# make a project
project(MyApp)
# This will generate a MyApp solution for VisualStudio
# containing all involved projects.
# add sub-folders which have to be considered
add_subdirectory(main)
add_subdirectory(gui)
add_subdirectory(model)
* MyApp/model может содержать библиотекудля базовой модели данных MyApp без дополнительных зависимостей. Таким образом, MyApp/model/CMakeLists.txt может выглядеть следующим образом:
# MyApp/model/CMakeLists.txt
# build rule for library libmodel
add_libary(model
model.cc model.h)
MyApp/gui может предоставить другую библиотеку для графического интерфейса MyApp с зависимостями дляlibmodel. MyApp/gui/CMakeLists.txt может выглядеть так:
# MyApp/gui/CMakeLists.txt
# build rule for library libgui
add_libary(gui
guiMainWindow.cc guiMainWindow.h)
# dependencies
target_link_libraries(gui
model)
Наконец, MyApp/main предоставляет исходный код для функции main() MyApp и создает исполняемый файл. MyApp/main/CMakeLists.txt может выглядетькак это:
# MyApp/main/CMakeLists.txt
# build rule for executable myApp
add_executable(myApp
myApp.cc)
# dependencies
target_link_libraries(myApp
gui model)