Saya ingin beberapa saran pada organisasi satu set proyek C ++ terkait tetapi independen yang disimpan dalam repositori (git) tunggal. Proyek menggunakan CMake.
Sebagai contoh sederhana, kita bayangkan 2 proyek A dan B, A tergantung pada B. Kebanyakan orang yang mengembangkan A akan mendapatkan B melalui sistem pengemasan. Dengan demikian mereka hanya akan mengkompilasi A. Namun, kami harus mengizinkan pengembang untuk mengkompilasi A dan B sendiri (dan menginstalnya), secara terpisah atau bersama-sama.
Berikut ini sebuah proposal:
└── 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) Tentukan variabel cmake umum untuk semua proyek (jika ada) dan sertakan subdirektori. (2) Menentukan proyek itu sendiri dan variabel cmake yang diperlukan proyek. (3) Menentukan header untuk diinstal dan yang diperlukan untuk kompilasi. (4) Mengkonfigurasi perpustakaan dan binari. (5) Mengkonfigurasi executable uji dan kasus uji.
Seperti yang saya pahami, setiap proyek harus menghasilkan file XXXConfig.cmake dan menginstalnya di / usr / local / share / cmake. Menulis file-file ini sepertinya cukup rumit ketika membaca dokumentasi CMake.
Bagaimana menurut anda ? Apakah strukturnya masuk akal?
Apakah Anda memiliki contoh kerja dari serangkaian proyek seperti itu?
CMakeLists.txt
file per proyek:A/CMakeLists.txt
(aplikasi) termasukB/CMakeLists.txt
(perpustakaan) yang menggunakanadd_subdirectory(...)
.