2012-12-03 10 views
7

Supponiamo di lavorare su qualche progetto che supporta diverse configurazioni (build di linux e windows, collegamenti condivisi/statici, con alcune funzionalità o senza, ecc.). Per costruire tutte queste configurazioni sono necessarie versioni diverse di componenti di terze parti (creati con gcc o msvc, condivisi/statici, con alcune definizioni di preprocessore specificate, ecc.). Quindi alla fine si finisce con il problema di gestire tutte queste configurazioni non solo per il progetto, ma per tutte le librerie utilizzate dal progetto.Come gestire le librerie di terze parti in un progetto di multi-configurazione

Esiste una soluzione/approccio/software generale per facilitare la gestione di diverse configurazioni di un singolo progetto?

Criteri:

  • Facilità di configurazione, vale a dire quanto tempo uno avrebbe bisogno di spendere per costruire il vostro progetto da zero?
  • Facilità di gestione, ovvero è difficile aggiungere una nuova dipendenza o rimuoverne una esistente?
  • Prova di errore, cioè con quale frequenza gli sviluppatori interromperanno la build cambiando le dipendenze?

Finora ho provato diversi approcci.

  1. pacchetti precompilati Conservare per ogni configurazione sotto VCS.

    Pro: facilità di impostazione mentre il progetto è di piccole dimensioni (aggiornamento della copia di lavoro e sei a posto). Facilità di gestione (creare una libreria una volta per ogni configurazione richiesta). Prova di errore (il client VCS ti avvisa delle modifiche alla tua copia di lavoro).

    Contro: non funziona bene per i VCS distribuiti (GIT, Mercurial, etc.). Il deposito cresce rapidamente e alla fine una semplice operazione di "clonazione" sarà intollerabile. Si finisce anche per scaricare un sacco di cose che non sono realmente necessarie (ad esempio, le librerie di Windows se si sta lavorando su Linux). E se stai implementando la libreria, gli utenti della tua libreria erediteranno tutti questi problemi integrandoli nel loro progetto.

  2. Memorizza le origini della libreria anziché i pacchetti predefiniti.

    Pro: facilità di installazione.

    Contro: È estremamente doloroso aggiungere una nuova libreria. È necessario fornire script di compilazione e patch di origine per ogni configurazione. Ma questa è solo la punta dell'iceberg. Le tue dipendenze hanno le loro dipendenze, che hanno le loro, così via e così via ... Hai una buona possibilità di finire con qualcosa come una distribuzione Gentoo :)

  3. Archiviare un archivio o solo una cartella con prebuilt pacchetti da qualche parte sul server esterno.

    Pro: Risolve il problema ... tipo di.

    Contro: Non è così facile da installare (è necessario copiare l'archivio manualmente). Non è così facile da gestire (devi aggiungere ogni libreria ad un server a mano). Nessuna cronologia dei cambiamenti.Non a prova di errore, perché è facile dimenticare di mettere qualcosa sul server o rimuovere qualcosa di utile.

    Approccio leggermente migliorato: è possibile utilizzare un VCS centralizzato (ad esempio, SVN) per archiviare tutte le librerie di terze parti, sarà più facile lavorare con. Tuttavia non hai ancora una cronologia centralizzata delle modifiche se la utilizzi come semplice archivio di file o se ottieni un enorme repository con molte librerie inutili se lo utilizzi come un sub-repository.

+1

La maggior parte delle librerie di terze parti che uso provengono da tutte le loro dipendenze quando si scarica la fonte, quindi si limitano a creare. Ma come hai detto, questo li rende molto più grandi di quanto probabilmente abbiano bisogno di essere. Scrivo personalmente uno script per clonare/checkout/scaricare tali librerie in una cartella vicina, e poi li costruisco come parte del processo di compilazione della mia stessa fonte. Il più fastidioso è quando queste librerie sono dotate di un sistema di compilazione che ti obbliga a iniziare un IDE e premere un pulsante. – enobayram

+0

@enobayram Che tipo di sistema di compilazione ti costringe a "avviare un IDE e premere un pulsante"? Come gestisci questi? Voglio dire, premi manualmente il pulsante o usi qualche soluzione automatica? – kol

+0

@kol alcune librerie distribuiscono un "file di progetto" per un particolare IDE, come il codelite, invece di un vero sistema di compilazione multipiattaforma come cmake. Per quanto ne so (perché ho cercato e non ho trovato nulla), non c'è modo di dire codelite dalla riga di comando per costruire un progetto, quindi è necessario avviarlo e premere "build". – enobayram

risposta

2

Quando di fronte a questo tipo di problemi, è necessario imparare e iniziare a utilizzare Configuration Management strumenti (oltre a tecniche usuali della vostra SCM di scelta). CM è il processo e l'utilizzo di alcuni strumenti di gestione della configurazione fa parte di questo processo.

Attualmente disponiamo di un'ampia scelta di diversi strumenti CM, in cui è possibile selezionare il metodo più adatto o solo quello preferito. Dal mio punto di vista, Chef è "Scelta migliore per tutti", il chilometraggio può variare

+0

Sembra promettente, grazie. – DikobrAz

Problemi correlati