Chciałbym uzyskać porady dotyczące organizacji zestawu powiązanych, ale niezależnych projektów C ++ przechowywanych w jednym repozytorium (git). Projekty wykorzystują CMake.
Dla uproszczonego przykładu wyobrażamy sobie 2 projekty A i B, A w zależności od B. Większość osób rozwijających A otrzyma B poprzez system pakowania. W ten sposób skompilują tylko A. Jednak powinniśmy pozwolić programistom na kompilację zarówno A, jak i B (i zainstalowanie go), osobno lub razem.
Oto propozycja:
└── 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) Zdefiniuj wspólne zmienne cmake dla wszystkich projektów (jeśli istnieją) i obejmuje podkatalogi. (2) Definiuje sam projekt i wymagane w projekcie zmienne cmake. (3) Definiuje nagłówki do zainstalowania i wymagane do kompilacji. (4) Konfiguruje bibliotekę i pliki binarne. (5) Konfiguruje pliki wykonywalne i przypadki testowe.
Jak rozumiem, każdy projekt powinien wygenerować plik XXXConfig.cmake i zainstalować go w / usr / local / share / cmake. Pisanie tych plików wydaje się dość skomplikowane podczas czytania dokumentacji CMake.
Co myślisz ? Czy struktura ma sens?
Czy zdarza ci się mieć działający przykład takiego zestawu projektów?
CMakeLists.txt
pliku na projekt:A/CMakeLists.txt
(aplikacjaB/CMakeLists.txt
) używa (biblioteki)add_subdirectory(...)
.