Я хотел бы получить несколько советов по организации набора связанных, но независимых проектов C ++, хранящихся в одном репозитории (git). В проектах используется CMake.
Для упрощенного примера мы представляем 2 проекта A и B, A в зависимости от B. Большинство людей, разрабатывающих A, получат B через систему упаковки. Таким образом, они будут компилировать только A. Однако мы должны позволить разработчикам самим компилировать A и B (и устанавливать их), по отдельности или вместе.
Вот предложение:
└── Repo1
├── CMakeLists.txt (1)
├── A
│ ├── CMakeLists.txt (2)
│ ├── include
│ │ ├── aaa.h
│ │ ├── aaaa.h
│ │ └── CMakeLists.txt (3)
│ └── src
│ ├── aaa.cpp
│ ├── aaaa.cpp
│ └── CMakeLists.txt (4)
├── B
│ ├── CMakeLists.txt (2)
│ ├── include
│ │ ├── bbb.h
│ │ ├── bbbb.h
│ │ └── CMakeLists.txt (3)
│ └── src
│ ├── bbb.cpp
│ ├── bbbb.cpp
│ └── CMakeLists.txt (4)
└── test
├── CMakeLists.txt (5)
└── testaaaa.cpp
(1) Определить общие переменные cmake для всех проектов (если таковые имеются) и включает в себя подкаталоги. (2) Определяет сам проект и необходимые переменные cmake проекта. (3) Определяет заголовки для установки и те, которые требуются для компиляции. (4) Конфигурирует библиотеку и двоичные файлы. (5) Конфигурирует исполняемые файлы теста и контрольные примеры.
Насколько я понимаю, каждый проект должен создать файл XXXConfig.cmake и установить его в / usr / local / share / cmake. Написание этих файлов кажется довольно сложным при чтении документации CMake.
Как вы думаете ? Имеет ли структура смысл?
У вас есть рабочий пример такого набора проектов?
CMakeLists.txt
файлом на проект:A/CMakeLists.txt
(приложение) включаетB/CMakeLists.txt
(библиотеку) с помощьюadd_subdirectory(...)
.