Как получить решение VS со всеми проектами и решениями для отдельных проектов с CMake

Question

TL; DR Я в основном хочу модульное решение этот вопрос . Не только одно решение со всем в нем, но и решение для каждого исполняемого файла отдельно.

---

В моем вопросе здесь Я хотел знать, как мне разбить мой CMakeLists.txt по разным папкам. Некоторые папки содержат код, который будет являться статической библиотекой, а часть кода будет исполняемым файлом или динамической библиотекой, основанной на этих статических библиотеках.

Структура папок выглядит следующим образом:

/path/to/base/
  CMakeLists.txt
  app1/
    <src files for app1>
    CMakeLists.txt
  app2/
    <src files for app2>
    CMakeLists.txt
  lib/
    <src files for lib>
    CMakeLists.txt

Если я использую CMakeLists.txt в родительской папке для всех моих библиотек и исполняемых файлов и включаю все каталоги, у меня возникает проблема, заключающаяся в том, что при создании проектов / решений VS, которые содержатся в моих проектах для каждой цели все проекты - не только те, которые необходимы для моей намеченной цели.

Содержимое CMakeLists.txt в базовой папке:

cmake_minimum_required(VERSION 3.1)

add_subdirectory(lib)
add_subdirectory(app1)
add_subdirectory(app2)

и CMakeLists.txt в папке app1 (app2 эквивалентно)

cmake_minimum_required(VERSION 3.1)

project(app1)

add_executable(app1 <src of app1>)

target_link_libraries(app1 lib)

и CMakeLists.txt из lib:

add_library(lib <src of lib>)

Если я запускаю cmake на CMakeLists.txt из базы, решение содержит все проекты. И даже если я открою только один из проектов; это также содержит все. VS проект app1 также строит app2 - чего я не хочу.

Если я запускаю cmake только на CMakeLists.txt в app1, я получаю решение, которое не содержит app2, но и не содержит lib, потому что это упоминается только для ссылок внутри файла cmake, а не как цель ( это в базовом файле)

Answer 1

CMake создаст решение для каждого вызова project, который будет включать все цели текущего каталога и его подкаталогов (независимо от того, были ли они определены до или после фактического вызова project).

Вот что должен делать хорошо ведущий себя сценарий CMake: каждый список CMake, который вы хотите использовать в качестве корня своего собственного поддерева в рамках более крупного проекта, должен начинаться с вызова cmake_minimum_required, за которым следует project звонок. Запись project в CMakeLists в основном означает: Это полностью автономный компонент, который может быть собран независимо, даже если вы удалите все файлы из его родительских каталогов. Таким образом, имеет смысл иметь отдельное решение для каждого такого project.

Имея это в виду, мы можем понять, почему это не работает в вашем случае: ваши приложения не являются полностью автономными, они зависят от lib . Решением этой проблемы является написание сценариев сборки для приложений, как если бы lib был предоставлен в качестве стороннего компонента с вызовами find_package и всем остальным. В составной сборке у вас уже есть цель для lib , поэтому сценарий, вызванный вызовом find_package, должен быть выполнен для короткого замыкания с использованием этой цели и фактически очищать систему, только если она не может найти существующую цель.

Также читайте о том, как работает система упаковки CMake , которая обеспечивает некоторую автоматизацию для элегантного управления такими случаями.