Я хотів би отримати кілька порад щодо організації набору пов'язаних, але незалежних проектів 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(...)
.