Tek bir (git) deposunda depolanan bir dizi ilişkili ama bağımsız C ++ projesinin organizasyonu hakkında bazı tavsiyelerde bulunmak istiyorum. Projeler CMake kullanıyor.
Basitleştirilmiş bir örnek için, B'ye bağlı olarak 2 proje A ve B, A düşünüyoruz. A geliştiren çoğu insan B sistemi üzerinden B alacak. Böylece sadece A derleyeceklerdir. Bununla birlikte, geliştiricilerin hem A hem de B'nin kendilerini ayrı ayrı veya birlikte derlemelerine (ve kurmasına) izin vermeliyiz.
İşte bir teklif:
└── 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) Tüm projeler (varsa) için ortak cmake değişkenlerini tanımlayın ve alt dizinleri içerir. (2) Projenin kendisini ve projenin gerekli olan cmake değişkenlerini tanımlar. (3) Kurulacak başlıkları ve derleme için gerekli olan başlıkları tanımlar. (4) Kütüphaneyi ve ikili dosyaları yapılandırır. (5) Test çalıştırılabilirlerini ve test senaryolarını yapılandırır.
Anladığım kadarıyla, her proje bir XXXConfig.cmake dosyası üretmeli ve / usr / local / share / cmake dosyasına kurmalıdır. CMake belgelerini okurken bu dosyaları yazmak oldukça karmaşık görünmektedir.
Ne düşünüyorsun ? Yapı mantıklı mı?
Böyle bir dizi projenin çalışan bir örneğine sahip misiniz?
CMakeLists.txt
proje başına bir dosya ile mutlu :A/CMakeLists.txt
(uygulama) içerirB/CMakeLists.txt
(kütüphane) kullanarakadd_subdirectory(...)
.