Quando si scrive un progetto open source e si utilizza Google Code o GitHub e si desidera utilizzare una libreria come Lua, come si dovrebbe fare?
Dato che la libreria non necessita di installazione prima della compilazione.
Risposte:
Consiglio vivamente di leggere la documentazione di Git sui sottomoduli ; risolve proprio questo problema, supponendo che tutte le tue fonti utilizzino Git. In caso contrario, è sempre possibile impostare un repository git ai fini dell'integrazione. Lo sforzo è banale e il payoff è significativo.
La dipendenza dovrebbe essere inclusa nel repository?
Penso che le dipendenze debbano sempre essere incluse nel repository purché includerle non violi i termini di utilizzo. Poche cose sono più fastidiose di dover trovare manualmente le versioni giuste delle dipendenze giuste prima di poter creare una build. Certo, questo è facile quando hai strumenti automatici per farlo, che possono trovare e scaricare la dipendenza giusta, ma cosa succede se non sei connesso al web al momento o il server è inattivo o il progetto della dipendenza è stato completamente sospeso e portato offline? Includere sempre le dipendenze, se possibile.
La dipendenza dovrebbe essere costruita all'interno dello stesso script di compilazione del resto del progetto o da uno script di compilazione separato?
A meno che non ci sia una buona ragione per compilare dal sorgente, utilizzare versioni precompilate.
E perché non fornire opzioni nello script di build? Un semplice interruttore per scegliere se compilare o meno anche le dipendenze. Se l'utente sceglie di compilare anche le dipendenze, invoca semplicemente i propri script di build dallo script di build del tuo prodotto. Quindi l'utente può invocare manualmente gli script di compilazione delle dipendenze o scegliere di creare una build completa di tutto. Ma fornirei le dipendenze come file binari se non ci fosse una buona ragione per compilarle dai sorgenti. Penso che nel mondo Open Source, alcune licenze richiedano la distribuzione delle fonti insieme al prodotto, ma ciò non significa che non sia possibile precompilarle.
In breve: fornire un intero pacchetto autonomo, se possibile. Ciò fornirà la massima praticità ai tuoi utenti.
Ciò può essere o meno applicabile al tuo caso d'uso, ma ciò che facciamo al lavoro è includere una cartella "Riferimenti" in ogni ramo. Inseriamo DLL di terze parti qui. Ciò provoca molta duplicazione di binari relativamente invariati nel controllo del codice sorgente, ma lo spazio di archiviazione è economico e in ogni momento ogni ramo e tag ha esattamente le dipendenze (e la versione!) Che si aspetta.
Pre-compiliamo noi stessi le dipendenze e spostiamo i binari compilati in quella cartella. Anche la nostra libreria condivisa interna viene trattata in questo modo. In questo modo la stessa tecnica funziona per librerie proprietarie precompilate, librerie open source e librerie interne.
Per quanto riguarda effettivamente rispondere alla tua domanda ora che l'ho riletta, fai la stessa cosa e menziona solo che il tuo progetto utilizza una versione 1.3.5 precompilata di Lua.
La dipendenza dovrebbe essere inclusa nel repository?
Può essere referenziato nel repository (con qualsiasi utilizzabile per il metodo SCM), se questa dipendenza è parte integrante del prodotto (dipendenza dalla fonte), non dipendenza binaria, che può essere risolta separatamente
La dipendenza dovrebbe essere costruita all'interno dello stesso script di compilazione del resto del progetto o da uno script di compilazione separato?
Non importa affatto. Puoi preferire qualsiasi metodo, in base alle tue esigenze (velocità / trasparenza / gestibilità / ecc.)
Essendo un negozio Eclipse, abbiamo appena iniziato a utilizzare Buckminster per gestire il nostro processo di costruzione / assemblaggio / distribuzione.
Il nostro primo passo è stato quello di estrarre tutte le nostre librerie dipendenti esistenti e lasciare che Buckminster si occupasse di materializzare quelle corrette. Ciò consente una distribuzione molto più rapida e ridotta.
Il prossimo passo sarà spostare il nostro svnrepository monolitico in una serie di gitrepository modulari .
Non so quanto Buckminster si integrerebbe bene con i gitsottomoduli (o con i sottosposi mercuriali), ma è bello che Buckminster sia agnostico riguardo al VCS usato per un dato componente.