Domanda

Al lavoro sto usando Perl 5.8.0 su Windows.

Quando ho messo Perl per la prima volta, sono andato su CPAN, scaricato tutte le fonti, fatto alcune modifiche (nel file .MAK? per supportare thread o cose del genere), e ho fatto nmake / nmake test / nmake install . Poi, a poco a poco, ho scaricato i singoli moduli da CPAN e ho fatto la danza nmake.

Quindi, vorrei passare a una versione più recente, ma quella nuova non deve interrompere alcuno script esistente. In particolare, un gruppo di "usa" i moduli che ho installato devono essere installati nella nuova versione.

Qual è il modo più affidabile (e più semplice) per aggiornare la mia versione attuale, assicurandomi che tutto ciò che ho fatto con la danza di nmake sarà ancora lì dopo l'aggiornamento?

È stato utile?

Soluzione

Come altri hanno notato, iniziare installando il nuovo perl in un posto separato. Ho diversi perls installati, ognuno completamente separato da tutti gli altri.

Per fare ciò, dovrai configurare e compilare tu stesso i sorgenti. Quando esegui configura , avrai la possibilità di specificare il programma di installazione. Ho dato istruzioni dettagliate per questo in una "Compilazione del mio Perl". in il numero di primavera 2008 di The Perl Review . C'è anche un elemento in efficace programmazione Perl che ti mostra come farlo.

Ora, torna alla tua distribuzione originale ed esegui cpan -a per creare un file autobundle. Questo è un documento Pod che elenca tutte le cose extra che hai installato e CPAN.pm comprende come usarlo per reinstallare tutto.

Per installare le cose nel nuovo perl, usa il percorso di quel perl per avviare CPAN.pm e installare il file autobundle che hai creato. CPAN.pm otterrà i giusti percorsi di installazione dalla configurazione di quel perl.

Guarda l'output per assicurarti che le cose vadano bene. Questo processo non installa le stesse versioni dei moduli, ma le ultime versioni.

Per quanto riguarda Strawberry Perl , c'è un " portatile " versione che puoi installare da qualche parte oltre alla posizione predefinita. In questo modo potresti avere il nuovo perl su supporti rimovibili. Puoi testarlo ovunque tu voglia senza disturbare l'installazione locale. Non penso che sia abbastanza pronto per l'uso generale però. Il Berrybrew strumento potrebbe aiutarti a gestirlo.

Buona fortuna, :)

Altri suggerimenti

Prenderei seriamente in considerazione la possibilità di utilizzare Strawberry Perl .

Puoi installare una seconda versione di Perl in una posizione diversa. Dovrai reinstallare tutti i moduli non core nella nuova versione. In generale, diverse versioni di Perl non sono compatibili con i binari, il che potrebbe costituire un problema se si dispone di librerie specifiche del programma che utilizzano componenti XS. I moduli Pure Perl non dovrebbero essere interessati.

Se rimani all'interno della traccia 5.8, tutti i moduli installati che contengono estensioni XS (binarie) continueranno a funzionare, poiché la compatibilità binaria è garantita all'interno della stessa serie 5.8. Se sei passato a 5.10, dovrai ricompilare tutti i moduli che contengono componenti XS.

Tutto quello che devi fare è assicurarti che la nuova build elenchi le precedenti directory di inclusione nel suo array @INC (che è usato per cercare i moduli).

A quanto pare, penso che tu sia su Windows, nel qual caso i percorsi @INC attuali possono essere visualizzati con

perl -le "print for @INC"

Assicurati di scegliere come target la tua nuova versione di Perl in un'altra directory. Riuscirà felicemente a coesistere con la versione precedente, e questo ti permetterà di scegliere quale installazione Perl utilizzare; è solo una questione di ottenere il tuo ordine PATH risolto. Non appena viene avviato un interprete perl, sa dove cercare il resto dei suoi moduli.

Strawberry Perl è probabilmente la distribuzione migliore su Windows in questi giorni per il tuo lancio.

Penso che la risposta a ciò implichi virtualizzazione di qualche tipo:

  1. Imposta una copia esatta della tua attuale macchina live. Esegui l'upgrade di Perl, utilizzando le stesse posizioni e strutture di directory che stai utilizzando al momento.
  2. Scorri i tuoi script testandoli sulla nuova immagine.
  3. Quando sei felice, gira l'interruttore.

Il pensiero dietro questo è che probabilmente ci sono tutti i tipi di dipendenze e ipotesi sottili a cui non hai pensato. Sebbene improbabile, l'ultima versione di un particolare modulo (forse anche un modulo principale, anche se è ancora più improbabile) potrebbe avere una differenza sottile rispetto a quella che stavi usando. A meno che non abbiate esaurientemente esaminato l'intera base di codice, è molto probabile che un modulo particolare sia richiesto solo in determinate circostanze.

Puoi provare a individuarlo creando un elenco di tutti i tuoi script, un elenco che dovresti comunque avere, a forza di tutto il tuo codice sotto il controllo di versione (tu stai usando il controllo di versione, ad es. Subversion , sì?) - e iterando attraverso di esso, eseguendo perl -c su ogni sceneggiatura. per esempio. questo script . Questo tipo di test automatizzato ha un valore inestimabile: puoi metterlo in funzione, andare via per un caffè o altro e tornare a controllare se tutto ha funzionato. Le prime volte probabilmente troverai un modulo oscuro di cui ti saresti dimenticato, il che va bene: il punto centrale dell'automatizzazione è che tu non devi fare il lavoro del drudge di controllare ogni singolo script.

Quando l'ho fatto ho installato quello più recente in una directory separata. C'è un po 'di confusione in più in esecuzione su due versioni, ma sicuramente aiuta a assicurarsi che tutto funzioni prima e fornisce un modo rapido per tornare a quello vecchio in un pizzico. Ho anche impostato Apache per eseguire due servizi separati, in modo da poter cercare il nuovo Perl in un servizio senza toccare quello di produzione sul vecchio Perl.

Probabilmente è molto più saggio, con il senno di poi, installare su un computer separato e fare i test lì. Registra tutte le modifiche alla configurazione che devi apportare.

Non sono sicuro di crearlo tu stesso: ho sempre usato solo binari preconfezionati per Windows.

Non sono sicuro di aver capito esattamente cosa stai chiedendo. Hai un elenco di modifiche apportate al makefile 5.8? O la domanda è come ottenere un tale elenco? Stai anche chiedendo come scoprire quali pacchetti sopra l'installazione di base hai ottenuto da CPAN? Stai anche chiedendo come verificare che le tue modifiche personalizzate non rompano quei pacchetti se li ricevi di nuovo da CPAN?

Perché non usi ActivePerl e il suo " ppm " strumento per (reinstallare) i moduli?

alt text

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top