Vorrei alcuni consigli sull'organizzazione di una serie di progetti C ++ correlati ma indipendenti memorizzati in un unico repository (git). I progetti utilizzano CMake.
Per un esempio semplificato, immaginiamo 2 progetti A e B, A a seconda di B. La maggior parte delle persone che sviluppano A otterranno B tramite il sistema di confezionamento. Quindi compileranno solo A. Tuttavia, dovremmo consentire agli sviluppatori di compilare sia A che B stessi (e installarlo), separatamente o insieme.
Ecco una proposta:
└── 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) Definisce le variabili cmake comuni per tutti i progetti (se presenti) e include le sottodirectory. (2) Definisce il progetto stesso e le variabili cmake richieste dal progetto. (3) Definisce le intestazioni da installare e quelle necessarie per la compilazione. (4) Configura la libreria e i binari. (5) Configura gli eseguibili e i casi di test.
A quanto ho capito, ogni progetto dovrebbe produrre un file XXXConfig.cmake e installarlo in / usr / local / share / cmake. Scrivere questi file sembra piuttosto complicato quando si legge la documentazione di CMake.
Cosa pensi ? La struttura ha senso?
Ti capita di avere un esempio funzionante di una tale serie di progetti?
CMakeLists.txt
file per progetto:A/CMakeLists.txt
(l'app) includeB/CMakeLists.txt
(la libreria) usandoadd_subdirectory(...)
.