Come trattare le librerie interne

Question

Come trattare le librerie interne

#1 da (4 voti)
#2 da (3 voti)

7

Sto affrontando problemi nella strutturazione di progetti e librerie.

Nella società per cui lavoro spesso vedo che le cose sarebbero più manutenibili e meno soggette a errori, se potessimo estrarre codice comune e creare librerie con quel codice.

Un semplice esempio potrebbe essere l'uso di una libreria di registrazione personalizzata invece di copiare codice da altri progetti o, peggio ancora, scrivere di nuovo tutto da capo.

Quindi, volendo esporre le cose nelle biblioteche, sorge la domanda su come farlo? La mia idea è di mettere ogni lib (o relativo set di librerie) nel proprio repository. Ma questo significherebbe che per costruire il progetto, è necessario verificare almeno due repository. Poiché ho lavorato a lungo su un progetto con dipendenze a un lotto di altri repository, sono diventato abbastanza attento a creare dipendenze da altri progetti.

Quindi la mia domanda è: c'è un'altra bella soluzione per questo? Cosa fate ragazzi?

Ci sono più di 150 repository, che non sono tutti correlati, ovviamente. La maggior parte dei progetti ha il proprio repository. Per fornire uno scenario, ipotizziamo quanto segue:

Applicazione A
L'applicazione B (fa già riferimento a 30 altri repository interni)
LibXYZ

Entrambe le applicazioni devono utilizzare LibXYZ.

Versioning:

Il controllo delle versioni dipende dal progetto. I vecchi progetti hanno appena preso il numero di revisione da SVN. Ora stiamo passando al versioning con numeri di fix come 1.2 o 1.2.5, quindi assumiamo questo come approccio di versioning. Ogni versione è contrassegnata in SVN.

Plattform:

Utilizziamo Qt come target principalmente di Windows. Ma apprezzo molto un approccio cross-plattform.

Cosa mi impedisce di creare un repository per codice comune?

Il problema che vedo è che aggiunge molta complessità a un progetto. Per essere in grado di compilare ed eseguire un'applicazione ho bisogno di:

controlla più repository
compila tutte le dipendenze
copia tutte le DLL compilate nella directory di compilazione dell'applicazione

Tutto questo di nuovo deve essere documentato e forse anche da includere negli script di compilazione. Inoltre questo costringe gli altri membri del team ad avere esattamente la stessa configurazione di me.

Non sto dicendo che questo è impossibile, sto solo cercando un approccio migliore.

version-control svn c++ qt

posta exilit 09.01.2017 - 14:39

fonte

2 risposte

Leggi altre domande sui tag version-control svn c++ qt

Come posso contare la frequenza delle stringhe? Dovrebbe essere definito ogni metodo in una classe in un'interfaccia implementata?

score 4 · Answer 1

Per risolvere questi problemi uno per uno:

check out multiple repositories

Usando SVN, puoi utilizzare la funzione "esternal" per questo. Ciò ti consentirà di definire le dipendenze tra diversi repository in modo tale da indicare "l'app A dipende da lib B taggato con la versione X" o "l'app A dipende da lib B, sempre la versione più recente". Per altri sistemi di controllo del codice sorgente senza una funzionalità come "esterni" (o se "esterni" non fornisce la soluzione che stai cercando), è possibile implementare un comportamento simile scrivendo alcuni script di checkout.

compile all dependencies

Il tuo sistema di build dovrebbe gestirlo per te, una volta definite le dipendenze in modo corretto. Non c'è differenza nella situazione in cui si usano le librerie di terze parti. Puoi ridurre i tempi di compilazione fornendo binari precompilati di ogni versione di libreria e inserisci i file binari compilati anche nel repository.

copy all compiled DLL's into the application's build directory

Sì, questo dovrebbe accadere automaticamente con il passo precedente.

In generale, la chiave di questo è l'automazione. Ogni volta che trovi un'attività manuale ricorrente, che potrebbe diventare soggetta a errori (ad esempio il check-out dai repository "corretti", copiare il file X nella cartella Y, impostare un tag con numero di versione aumentato qui e così via),

scrivi i passaggi manuali in qualcosa di simile a un file "readme"
scopri come automatizzare questi passaggi attraverso lo scripting
assicurati che gli script eseguano correttamente la registrazione e la gestione degli errori! Anche il controllo delle precondizioni e qualche tolleranza agli errori è utile per la mia esperienza.

Quando si ha a che fare con più applicazioni, repository e librerie, potrebbe essere anche una buona idea configurare un server di build che controlli tutto di notte e faccia una compilazione completa di tutto.

Moreover this forces the other team members to have the exact same setup as I do.

In una certa misura, sì, ma questa non è necessariamente una brutta cosa. Per ogni strumento di sviluppo, consiglio di aggiungere un file Leggimi che descriva i requisiti specifici di installazione nel proprio ambiente interno. Gli script di build dovrebbero fare affidamento sui percorsi relativi possibili, non utilizzare alcun percorso assoluto quando non è necessario. Se necessario, disporre di uno script di inizializzazione centralizzato che mostri cose come i percorsi di installazione per gli strumenti richiesti nel computer corrente e impostare di conseguenza alcune variabili di ambiente.

score 3 · Answer 2

Non fare riferimento ad altri repository. Non hai bisogno di costruire le dipendenze ogni volta che crei l'applicazione principale.

Costruisci ciascun repository di librerie in una dll separatamente e la versione che dll

aggiungi la DLL binaria compilata a un repository di pacchetti (nuget npm)

aggiungi un riferimento al pacchetto sul repository del pacchetto al progetto principale

quando costruisci il progetto principale, il primo passo è scaricare le DLL versione

(se non hai un gestore di pacchetti, aggiungi la DLL al controllo del codice sorgente nel tuo repository principale)