Gestione di una libreria di terze parti che viene utilizzata da più librerie indipendenti

Question

Gestione di una libreria di terze parti che viene utilizzata da più librerie indipendenti

#1 da (1 voti)

1

Sto lavorando alla configurazione dell'ambiente di compilazione per un progetto C ++ che utilizza più librerie. Queste librerie sono indipendenti l'una dall'altra, ma dipendono tutte dalla stessa libreria di terze parti (GTest) per i test. Sto avendo qualche problema nel determinare dove dovrei mettere questa libreria di terze parti, quindi avrò la massima flessibilità e modularità nel mio progetto.

La struttura generale del progetto è la seguente:

       +---------------+
       | Main Project  |
       +-+-----+-----+-+
         |     |     |
    +----+     |     +----+
    |          |          |
+---v---+  +---v---+  +---v---+
| lib1  |  | lib2  |  | lib3  |
+---+---+  +---+---+  +---+---+
    |          |          |
    +----+     |     +----+
         |     |     |
       +-v-----v-----v-+
       |     GTest     |
       +---------------+

Per come la vedo io ho 3 opzioni:

Costruisci e installa GTest da qualche parte sul mio sistema e fai in modo che tutte e 3 le librerie si colleghino alla stessa libreria GTest.

Il vantaggio di questo è che ho solo una copia di GTest, e le librerie non hanno bisogno di sapere nulla l'una sull'altra o sul progetto principale.
Lo svantaggio è che non esiste un posto standard dove metterlo e chiunque altro voglia utilizzare una di queste librerie dovrà sapere come installare GTest da sé e dove è necessario installarlo.

Aggiungi GTest come dipendenza dal progetto Main (magari in una cartella "3rdparty") e collega tutte le librerie alla copia del progetto principale di GTest

Il vantaggio di questo è che ho solo una copia di GTest e non è installata in qualche posizione arbitraria
Lo svantaggio ora è che tutte le librerie devono sapere del progetto principale e non potrebbero essere utilizzate senza il presente progetto principale. (e preferirei che fossero completamente indipendenti e utilizzabili da soli)

Aggiungi GTest come dipendenza su ogni singola libreria (ogni libreria avrà una cartella "3rdparty" che contiene GTest)

Il vantaggio di questo è che ogni libreria è indipendente dalle altre e tutte contengono la loro dipendenza GTest in modo che gli utenti della libreria non abbiano bisogno di sapere come installarlo da soli.
Lo svantaggio è che ora avrei 3 copie separate di GTest, una per ogni libreria. Ciò aggiunge anche una certa complessità complessiva.

Quale di questi approcci è il più preferibile, se esiste? Ci sono altri approcci migliori che non ho ancora considerato?

c++ architecture cmake project-structure dependency-management

posta tjwrona1992 11.11.2018 - 21:03

fonte

1 risposta

Leggi altre domande sui tag c++ architecture cmake project-structure dependency-management

come simulare i consumatori sequenziali in Kafka Separazione tra richieste di siti Web regolari e richieste API

score 1 · Answer 1

Build and install GTest somewhere on my system and have all 3 libraries link to the same GTest library.

Vengo dalla scuola di pensiero che dice qualsiasi dipendenza dal codice, è anche il mio codice. Pertanto, trattalo esattamente come tutti gli altri codici che stai scrivendo sul progetto e trasferiscilo nello stesso repository sorgente.

Ciò consente di generare ripetibili poiché l'unica informazione richiesta per ricostruire qualsiasi versione del progetto è già nella base del codice. Effettuerei anche le dipendenze di check-in create dagli altri repository. Essere in grado di ricostruire completamente un binario identico aiuta molto nell'analisi del rollback e dei difetti.

Aiuta anche a evitare problemi di ambiente di costruzione in cui diverse versioni globali si comportano in modo leggermente diverso.

Aumenta tuttavia la dimensione complessiva dei repository di origine, poiché ogni repository deve effettuare il check-in di tutte le dipendenze, ma lo spazio su disco è molto economico.

Add GTest as a dependency on the Main project (maybe in an "3rdparty" folder) and link all of the libraries to the main project copy of GTest

Non farlo se quelle librerie si trovano in repository separati . Questo rende un aggancio complicato, dato che A è necessario per costruire B, che è necessario per costruire A. Questo è pensiero circolare ei draghi mangiano i polli e le loro uova indipendentemente dall'ordine in cui arrivano.

Se queste librerie sono sottomoduli del progetto principale, questo funziona ed è una buona soluzione. Aiuta a mantenere la coerenza e fornisce un singolo punto di aggiornamento. L'unico punto critico è che tutte le librerie secondarie e gli strumenti nel repository devono essere aggiornati insieme. Questo potrebbe essere ottimo (tutto utilizza l'ultima versione), ma potrebbe anche essere un punto critico (non è possibile aggiornarlo perché la libreria C è troppo difficile da aggiornare).

Add GTest as a dependency on each individual library (each library would have a "3rdparty" folder that contains GTest)

Questa è sempre l'opzione più flessibile, ogni modulo / sottoprogetto / strumento nel repository può essere aggiornato indipendentemente. Ma questo può portare anche all'inferno della dipendenza. Soprattutto se la dipendenza è in qualche modo pubblicata nell'API dei moduli.

In questo caso, la libreria di test non verrà pubblicata tramite l'API, quindi non importa se ciascuna libreria utilizza una versione diversa. Tuttavia, dal punto di vista del reporting del test, il formato del report fa parte dell'API. Se cambia tra le versioni, potrebbe essere necessario aggiornarle tutte in una volta, o altrimenti devono gestire due diversi formati di report di errore nel processo di compilazione.

La mia preferenza sarebbe gestirla tramite una cartella di terze parti (opzione 2). Quando un progetto arriva al punto in cui un modulo ha bisogno di una versione separata di una dipendenza condivisa (opzione 3), il suo tempo per spostarsi nel proprio repository / processo di creazione / etc ...

A questo punto tratta quel modulo come se fosse completamente indipendente. Ha le sue dipendenze / build / test / documentazione / ecc. Il progetto principale build / test / etc può solo richiamare gli script build / test (come fa un build server) e si aspetta che il deliverable nella directory della libreria di "terze parti".

Ci sarà un po 'di tempo di transizione per ottenere tutto questo, ma quando si introducono le dipendenze locali - fare sempre tutto o niente. Mescolare i due sistemi (anche durante la transizione) porta a confusione su quale dipendenza è per cosa, dove si trova e gli impatti di un cambiamento.