Dotaz: Správa C++ projektů (odkazy ve správě verzí?)

[microcz]

Dobrý den,

předem se omlouvám za případnou stupiditu dotazu, ale potřeboval bych od Vás poradit....

Pracujeme ve firmě na několika rozsáhlejších projektech v C++. Jednotlivé projekty mají mezi sebou závislosti, například projekty B a C používají různé podmnožiny z množiny tříd projektu A, který byl vytvořen dříve. Zároveň pro projekt A beží podpora a je potřeba uvedené třídy měnit (vylepšovat, opravovat)

Řešením by mohlo být rozdrobit projekty do mnoha malých knihoven a v každém projektu si pak stahovat ze správy verzí aktuální verze potřebných knihoven. V jave by tohle byla paráda, ale problémem je C++ ... psát CMake pro každou knihovnu, uvažovat fakt že každá knihovna může být závislá na jiných knihovnách, být schopen zkompilovat každou knihovnu pro všechny požadované architektury, operační systémy a začlenit ji do projektů, nutnost stromovitě překompilovávat závislosti, to vše činí z tohohle způsobu řešení peklo.

Proto bych se chtěl zeptat zda nějaký existující verzovací systém neobsahuje něco jako tvorbu odkazů...

PŘEDSTAVA:

1. Existovali by oddělené složky pro projekty A,B,C...atd
2. Každý projekt by měl svou adresářovou strukturu, ale z růzých míst v B a C by mohli být odkazovány třídy nebo celé adresáře projektu A.
3. Pokud by někdo stáhl z repozitáře pouze projekt B nebo C, stáhli by se mu místo linků reálné soubory a adresáře, aniž by vědět o přítomnosti linků na projekt A, při commitu změn v těchto souborech by se ale updatovaly i soubory v A.

Zdá se Vám to jako hloupost? Jak byste podobný problém řešili vy?

Odpovědi

[vbar]

Subversion podporuje symlinky, ale bohužel nikoli pod Windows... Osobně jsem tenhle problém řešil na svém posledním projektu hrubou silou, tj. sdílené soubory se udržovaly zvlášť a každý projekt který je potřeboval si je v rámci buildu zkopíroval. Je pravda že to ten build komplikuje, a dělat změny na originálu mimo projekt je nepohodlné, ale pro podporu bouřlivě se vyvíjejících závislostí a obskurních platforem to má své výhody. Stabilnější části jsem ale stejně tlačil do sdílené knihovny - kolik jich na konkrétním projektu má být a jak velké je podle mně hlavně otázka osobních preferencí architekta...

[Sten]

Subversion hlavně podporuje svn:externals a není problém sdílený kód umístit do jedné složky, kterou takhle „nalinkujete“. S tímto přístupem mám na Windows dobré zkušenosti. Nicméně už nějakou dobu používám git, který externals umí také.

[pht]

Dejte si to vše do jednoho repa, nebo vyjměte z A jednu knihovnu na kterou budou odkazovat A B C.

aniž by vědět o přítomnosti linků na projekt A, při commitu změn v těchto souborech by se ale updatovaly i soubory v A

To je dost nebezpečné řešení.

[l4m4]

Nebezpečného na tom není nic.

Akorát normálnější je sdílená knihovna (blouznění tazatele o samostatných makefiles nechápu, to snad už takhle je, nebo má rozbitý build system).

[Josef Kufner]

V Gitu bych to řešil pomocí submodulů.

Ten makefile napíšeš jen jednou a pak ho budeš jen kopírovat a kopírovat pro každou knihovnu.

Závislosti můžeš vyřešit celkem jednoduše malým scriptem. V kořeni každého submodulu bys mohl mít soubor, kde na samostatných řádcích budou uvedeny závislosti dané knihovny. Pak jen uděláš cat lib/*/závislosti | uniq a odečteš seznam souborů (| while read d ; do [ -d "$d" ] || echo "Missing $d" ; done).

Build takového projektu bude jen o tom, že v tom adresáři lib/ budeš mít makefile, který rekurzivně zavolá makefily všech knihoven. Pokud je pořadí kompilace důležité (nemělo by být, hlavičkové soubory by měly stačit), tak ty soubory se závislostmi jednoduchým scriptem poskládáš do makefilu (každý soubor spojit v jeden řádek uvozený jeho jménem a dvojtečkou, tedy ještě to asi bude chtít převést názvy na jména archivů knihoven). Jo a ten makefile v lib zavoláš na začátku kompilace tvého projektu.