Git havuzlarını ortak yuvalanmış alt modüllerle düzenleme

Git alt modüllerinin büyük bir hayranıyım . Sürümüyle birlikte bir bağımlılığı izleyebilmeyi severim, böylece projenizin önceki bir sürümüne geri dönebilir ve bağımlılığın ilgili sürümünü güvenli ve temiz bir şekilde oluşturabilirsiniz. Dahası, kütüphanelerimizin tarihi, onlara bağlı olan uygulamalardan (ve açık kaynaklı olmayacak) farklı olduğundan, açık kaynak projeleri olarak yayınlanması daha kolaydır.

İşyerinde çoklu projeler için iş akışı kuruyorum ve bu yaklaşımı tek bir monolitik projeye değil, biraz aşırıya çekersek bunun nasıl olacağını merak ediyordum. Çabucak fark ettim ki, gerçekten de alt modülleri kullanmanın olası bir solucan kutusu var .

: Uygulamaların bir çift farz studiove playerve bağımlı kütüphaneleri core, graphve networkaşağıdaki gibi bağımlılıklar vardır:

• core bağımsız
• graphbağlıdır core(alt modül de ./libs/core)
• networkbağlıdır core(alt modül de ./libs/core)
• studiobağlıdır graphve network(en alt modüllere ./libs/graphve ./libs/network)
• playerbağlıdır graphve network(en alt modüllere ./libs/graphve ./libs/network)

CMake'i kullandığımızı ve bu projelerin her birinin birim testleri ve tüm çalışmaları olduğunu varsayalım . Her proje (dahil studiove dahil player) kod ölçümleri, birim testleri vb. İşlemleri yapmak için bağımsız olarak derlenebilmelidir.

Mesele şu ki, özyinelemeli git submodule fetch, sonra aşağıdaki dizin yapısını elde edersiniz:

studio/
studio/libs/                    (sub-module depth: 1)
studio/libs/graph/
studio/libs/graph/libs/         (sub-module depth: 2)
studio/libs/graph/libs/core/
studio/libs/network/
studio/libs/network/libs/       (sub-module depth: 2)
studio/libs/network/libs/core/

Projede coreiki kez klonlandığına dikkat edin studio. Bu boşa harcanan disk alanı dışında, bir derleme sistemi sorunum var çünkü coreiki kez yapıyorum ve potansiyel olarak iki farklı sürümü alıyorum core.

Soru

Alt modülleri nasıl düzenlerim ki ortak iç içe alt modüllerin birden fazla kopyasını almadan sürüm bağımlılığı ve bağımsız yapı elde edeyim?

Olası çözüm

Kütüphane bağımlılığı bir öneriden kaynaklanıyorsa (yani, "X sürümüyle çalıştığı biliniyor" veya "yalnızca X sürümü resmi olarak desteklenir") ve olası bağımlı uygulamalar veya kütüphaneler, istedikleri sürümle oluşturulmasından sorumludur, o zaman Aşağıdaki senaryoyu hayal edebiliyorum:

• Derleme sistemini nerelere bulacağınızı graphve networknerede bulacağınızı söyleyin core(örneğin, bir derleyici yoluyla yol dahil). "Bağımsız" ve "bağımlılık" olmak üzere "bağımsız" ve "bağımlılık" olmak üzere iki yapı hedefi tanımlayın; burada "bağımsız", "bağımlılık" ı temel alır ve yerel corealt modüle işaret etmek için içerme yolunu ekler .
• Ekstra bir bağımlılık tanıtın: studioaçık core. Ardından, studioderler core, içerme yolunu corealt modülün kendi kopyasına ayarlar , sonra derler graphve network"bağımlılık" modunda ayarlar.

Ortaya çıkan klasör yapısı gibi görünüyor:

studio/
studio/libs/                    (sub-module depth: 1)
studio/libs/core/
studio/libs/graph/
studio/libs/graph/libs/         (empty folder, sub-modules not fetched)
studio/libs/network/
studio/libs/network/libs/       (empty folder, sub-modules not fetched)

Bununla birlikte, bu, bir miktar inşa sistemi sihri gerektirir (bunun CMake ile yapılabileceğinden oldukça eminim) ve sürüm güncellemelerinin bir kısmı el ile çalışmayı graphgerektirir (güncelleme ayrıca tüm projelerin güncellenmesini coreve networkuyumlu bir sürümünü edinmek için gerekli olabilir core) .

Bunun hakkında bir düşüncen var mı?

Bu partiye çok geç kaldım, ancak sorunuzun hala tam bir cevabı yok gibi görünüyor ve bu google’dan oldukça etkileyici.

C ++ / CMake / Git / Submodules ile aynı sorunu yaşıyorum ve MATLAB derlenmediğinden ekstra gariplik kazanan MATLAB / Git / Submodules ile benzer bir problemim var. Ben rastladım bu video bir "çözüm" önermeyi görünüyor, geçenlerde. Çözümü sevmiyorum, çünkü bu aslında alt modülleri çöpe atmak anlamına geliyor, ancak sorunu ortadan kaldırıyor. Aynen @ errordeveloper'ın önerdiği gibi. Her projenin alt modülü yok. Bir proje inşa etmek, onu inşa etmek için bir süper proje oluşturun ve onu bağımlılıklarına kardeş olarak ekleyin.

Yani geliştirme projeniz graphşöyle görünebilir:

buildgraph/graph
buildgraph/core

ve sonra stüdyo projeniz şöyle olabilir:

buildstudio/studio
buildstudio/graph
buildstudio/network
buildstudio/core

Süper projeler sadece bir ana CMakeLists.txtve bir sürü alt modül. Ancak hiçbir projenin kendi alt modülü yok.

Bu yaklaşıma gördüğüm tek maliyet, gerçek projelerinizi oluşturmaya adanmış önemsiz "süper projelerin" çoğalmasıdır. Ve birisi projelerinizden birini ele geçirirse, süper projeyi de bulmadan, bağımlılıklarının ne olduğunu söylemenin kolay bir yolu yoktur. Bu, örneğin Github'a gerçekten çirkin oturmasını sağlayabilir.

İkinizin de entegre zaman varsayalım graphve networkiçine submodules studio, her zaman aynı sürümü olması gerekir coretarihinin belirli bir zamanda studio. Alt studio/libs/coremodülü içine batırırdım studio/libs/{graph,network}/libs.

Güncelleme:

Belirttiğiniz bağımlılıklarla birden fazla depo oluşturdum:

./core      <--- (v2)
./graph
./graph/libs
./graph/libs/core  <--- (v2)
./graph/.gitmodules
./network
./network/libs
./network/libs/core  <--- (v1)
./network/.gitmodules
./studio
./studio/libs
./studio/libs/graph
./studio/libs/graph/libs
./studio/libs/graph/libs/core <--- (v1)
./studio/libs/graph/.gitmodules
./studio/libs/network
./studio/libs/network/libs
./studio/libs/network/libs/core  <--- (v1)
./studio/libs/network/.gitmodules
./studio/studio
./studio/.gitmodules

v1ve v2iki farklı versiyonu core. graphsürüm 2'yi kullanırken, networkbazı çalışmalara ihtiyaç duyar ve sürüm 1'de takılı kalır . Çalışma yerinde bir programa sahip olmak için her iki noktanın studioyerel gömülü sürümlerinde . Şimdi, inşa perspektifinden ayrı olarak, her şey alt modüller ile iyi çalışıyor.corev1

Şimdi şu dizini kaldırabilirim:

./studio/libs/network/libs/core

Ve onu sembolik bir bağlantıyla değiştirin:

./studio/libs/network/libs/core@ -> ../../graph/libs/core/

Yerel olarak bu değişikliği yapıyorum ve coreiçeride iki ayrı versiyona sahip olma yeteneğimi yitiriyorum studio, ancak sadece bir corekere yapıyorum . Yükseltmeye hazır v2olduğumda şunları yapabilirim:

 git submodule update # (--rebase ?)

... stüdyo / libs / ağ içinde.

Sadece bir alt modül derinliğine sahip olacak ve tüm modülleri README ve derleme komut dosyalarından başka hiçbir şey tutamayacak bir havuza sahip olacak şekilde düzleştirirdim. Bağımlılıklarını birbirine bağlayan paketlerin her biri için ayrı bir derleme betiği olacaktır. Aksi takdirde, bir paket için ayrı bir depoya sahip olabilirsiniz.

Ben alt modüller kullanmam.

Svn-dışsallardaki gibi eskisi gibi cazip. Ancak, bağladığınız tüm projelerin bir yılda hala aynı yerde olduğundan emin olabilir misiniz? Peki ya beşte?

Bu nedenle, sadece gerekli tüm bağımlılıkları projeme kopyalıyorum. Bu, depom geçerli olduğu sürece, kesin durumu kontrol edebilirim.

Temel olarak, aşağıdaki gibi bir klasör yapısına sahibim:

myproject/... [sources etc]
ext/ [third-party dependencies]


e.g. ext/boost, ext/cppunit

Bu, disk alanı açısından pek hoş olmamakla birlikte, depo çok daha yüksek olduğu sürece kaydedilen her durumu kontrol edebileceğime garanti ediyorum.

Ek olarak, burada açıklanan alt modüller ile ilgili bir sürü problem vardır.

Burada da aynı sorunla karşı karşıyayız. Çözümlerden biri bazı repo olması olabilir libsyapacağını core, network, graphAltmodüllerin ve bağımlılıklarını bulmak için kütüphanelerini her söylerdim sadece CMakeLists olarak. Artık her uygulama libsalt modül olarak sahip olacak ve sadece gerekli kütüphaneleri kullanacaktı.

Her bir lib'in test edilmesi 2 şekilde yapılabilir:

• Core_testing, graph_testing, network_testing 'i ayrı uygulamalar olarak yapın
• Test sunucularını test sunucularına dağıtın ve cmake kullanarak test yaparken bunları bulun