Definizione di un ambiente di runtime

Question

Devo definire un ambiente di runtime per il mio sviluppo. La prima idea è ovviamente di non reinventare la ruota. Ho scaricato macports, usato easy_install, provato fink. Ho sempre avuto problemi. In questo momento, ad esempio, non sono in grado di compilare scipy perché il programma di installazione di MacPorts vuole scaricare e installare gcc43, ma questo non si compila su Snow Leopard. È stato aperto un bug per questo problema, ma sono sostanzialmente legato a loro perché il mio runtime sia utilizzabile.

Una tecnica che ho imparato qualche tempo fa, era quella di scrivere un makefile per scaricare e compilare il runtime / lib con versioni chiaramente specificate di librerie e utility. Questo precede l'approccio MacPorts / fink / apt, ma hai molto più controllo su di esso, anche se devi fare tutto a mano. Naturalmente, questo può diventare un incubo da solo se il runtime aumenta, ma se trovi un problema, puoi usare patch e risolvere il problema sul pacchetto scaricato, quindi crearlo.

Ho più domande:

• Qual è la tua tecnica per preparare una raccolta runtime / libreria ben definita per il tuo sviluppo?
• MacPorts / fink / qualunque cosa mi consente la stessa flessibilità di rehacking se qualcosa va storto?
• Considerando la mia soluzione makefile, quando il mio software è finalmente disponibile per il download, quali sono i tuoi suggerimenti per risolvere i potenziali problemi tra il mio ambiente di sviluppo e la piattaforma reale sui computer dei miei utenti?

Modifica : ciò che non capisco in particolare è che altri progetti non mi danno suggerimenti. Ad esempio, ho appena scaricato scipy, una libreria complessa con molte dipendenze. Gli sviluppatori devono avere tutte le impostazioni di deps prima di lavorare su di esso. Nonostante ciò, non c'è nulla nello svn che crea questo ambiente.

Modifica : aggiunta una generosità alla domanda. Penso che questo sia un problema importante e che meriti di ottenere più risposte. Prenderò in considerazione al meglio quelle risposte con esempi del mondo reale con particolare attenzione alle problematiche emerse e alla loro soluzione.

Altre domande da ispirare per la taglia:

• Esegui test sul tuo ambiente (per verificare la corretta installazione, ad es. su una macchina di integrazione)?
• Come includi il tuo ambiente al momento della spedizione? Se è C, lo colleghi staticamente o spedisci la libreria dinamica, armeggiando LD_LIBRARY_PATH prima di eseguire l'eseguibile? Che dire dello stesso problema per python, perl e altri?
• Ti attieni al runtime o lo aggiorni col passare del tempo? Scarichi " trunk " pacchetti delle librerie delle dipendenze o una versione fissa?
• Come gestisci situazioni come: la libreria foo ha bisogno di Python 2.5, ma devi svilupparla in Python 2.4 perché la barra della libreria non funziona con Python 2.5?

Answer 1

Utilizziamo uno script CMake che genera Makefile che scaricano (principalmente tramite SVN) / configurano / costruiscono tutte le nostre dipendenze. Perché CMake Multi piattaforma. Funziona abbastanza bene e supportiamo l'invocazione di scons / autopain / cmake. Poiché ci basiamo su diverse piattaforme (Windows, MacOSX, un mucchio di varianti di Linux) supportiamo anche diversi flag di compilazione ecc. Basati sul sistema operativo. In genere una libreria ha una configurazione predefinita e se incontriamo un sistema che richiede una configurazione speciale, la configurazione viene sostituita con una configurazione specializzata. Funziona abbastanza bene. Non abbiamo davvero trovato una soluzione pronta che si adattasse al nostro scopo.

Detto questo, è un PITA che lo mette in funzione - ci sono molte manopole da girare quando è necessario supportare diversi sistemi operativi. Non penso che diventerà un incubo di mantenimento poiché le dipendenze sono abbastanza fisse (le biblioteche vengono aggiornate regolarmente, ma raramente ne introduciamo una nuova).

Answer 2

virtualenv è buono, ma non può fare magia - per esempio se vuoi usare una libreria che DEVE solo avere Python 2.4 e un'altra che invece BISOGNA assolutamente 2.5, sei sfortunato. Né virtualenv (o qualsiasi altro strumento) può essere d'aiuto quando c'è una nuovissima versione di un sistema operativo e metà degli strumenti e degli strumenti non lo supporta ancora, come hai già detto per Snow Leopard: alcuni problemi sono semplicemente impossibili da risolvere (due librerie con esigenze assolutamente contrastanti all'interno della stessa build), altre richiedono solo pazienza (fino a quando tutti gli strumenti necessari non vengono portati alla nuova versione del sistema operativo, è sufficiente attenersi alla versione precedente del sistema operativo).