Frage

Bei der Arbeit verwende ich Perl 5.8.0 unter Windows.

Als ich Perl zum ersten Mal installierte, ging ich zu CPAN, lud alle Quellen herunter und nahm ein paar Änderungen vor (in der .MAK-Datei?um Threads oder ähnliches zu unterstützen) und habe nmake / nmake test / nmake installiert.Dann habe ich nach und nach einzelne Module von CPAN heruntergeladen und den Nmake-Tanz gemacht.

Ich würde also gerne auf eine neuere Version upgraden, aber die neue darf keine vorhandenen Skripte beschädigen.Insbesondere müssen eine Reihe von „Use“-Modulen, die ich installiert habe, in der neuen Version installiert werden.

Was ist der zuverlässigste (und einfachste) Weg, meine aktuelle Version zu aktualisieren und sicherzustellen, dass alles, was ich mit nmake dance gemacht habe, auch nach dem Update noch vorhanden ist?

War es hilfreich?

Lösung

Wie andere bereits erwähnt, zunächst die neue Perl in einem separaten Ort zu installieren. Ich habe mehrere perls installiert, die jeweils völlig unabhängig von allen anderen.

Um das zu tun, werden Sie müssen die Quellen selbst konfigurieren und kompilieren. Wenn Sie configure ausführen, werden Sie die Chance bekommen, um das Installationsprogramm zu spezifizieren. Ich gab detaillierte Anweisungen für diese in einem in die Frühjahr 2008 Ausgabe von The Perl Review "My Own Perl Kompilieren" . Es gibt auch einen Artikel in Effective Perl-Programmierung , die Sie zeigt, wie es geht.

Nun, gehen Sie zurück zu Ihrem ursprünglichen Verteilung und führen cpan -a eine autobundle Datei zu erstellen. Dies ist ein Pod-Dokument, das alle zusätzlichen Sachen aufgeführt, die Sie installiert haben, und CPAN.pm versteht, wie das verwenden, um alles neu zu installieren.

Um die Dinge in der neuen Perl zu installieren, verwenden, dass Perl Pfad CPAN.pm zu starten und installieren Sie die Datei, die Sie erstellt autobundle. CPAN.pm die richtigen Installationspfade aus, dass Perl die Konfiguration erhalten.

Sehen Sie den Ausgang sicher die Dinge gut zu machen. Dieser Prozess wird die gleichen Versionen der Module nicht installieren, aber die neuesten Versionen.

Wie für Strawberry Perl , gibt es eine "portable" Version, die Sie irgendwo neben dem Standardverzeichnis installiert werden kann. Auf diese Weise könnte man die neue Perl auf Wechselmedien haben. Sie können testen, es überall Sie mögen, ohne die lokale Installation zu stören. Ich glaube nicht, dass, obwohl für den allgemeinen Gebrauch ziemlich bereit ist. Die Berrybrew Werkzeug könnte Ihnen helfen, dass zu verwalten.

Viel Glück:)

Andere Tipps

Ich würde ernsthaft auf der Suche bei Verwendung von Strawberry Perl .

Sie können eine zweite Version von Perl in einem anderen Ort installieren. Sie werden alle Nicht-Core-Module in die neue Version neu installieren müssen. In der Regel verschiedene Versionen von Perl sind nicht binär-kompatibel, was ein Problem sein könnte, wenn Sie programmspezifische Bibliotheken, die XS-Komponenten nutzen. Reine Perl-Module sollten nicht betroffen sein.

Wenn Sie im 5.8-Track bleiben, funktionieren alle installierten Module, die XS-Erweiterungen (binär) enthalten, weiterhin, da die Binärkompatibilität innerhalb derselben 5.8-Serie gewährleistet ist.Wenn Sie auf 5.10 umsteigen würden, müssten Sie alle Module neu kompilieren, die XS-Komponenten enthalten.

Sie müssen lediglich sicherstellen, dass der neue Build die vorherigen Include-Verzeichnisse in seinem @INC-Array auflistet (das zur Suche nach Modulen verwendet wird).

So wie es sich anhört, denke ich, dass Sie unter Windows arbeiten. In diesem Fall können die aktuellen @INC-Pfade mit angezeigt werden

perl -le "print for @INC"

Stellen Sie sicher, dass Sie Ihre neue Perl-Version in einem anderen Verzeichnis ablegen.Es wird glücklich mit der vorherigen Version koexistieren, und Sie können aus dieser Perl -Installation auswählen.Es geht nur darum, Ihre PATH-Bestellung zu regeln.Sobald ein Perl-Interpreter gestartet ist, weiß er, wo er nach den restlichen Modulen suchen muss.

Strawberry Perl ist heutzutage wahrscheinlich die beste Windows-Distribution zum Erstellen eigener Distributionen.

Ich denke, die Antwort auf diese beinhaltet Virtualisierung irgendeine Art:

  1. Stellen Sie eine exakte Kopie Ihrer aktuellen Live-Maschine. Upgrade-Perl, mit den gleichen Verzeichnispositionen und -strukturen, wie Sie im Moment verwenden.
  2. Gehen Sie durch Ihre Skripte sie auf dem neuen Image zu testen.
  3. Wenn Sie glücklich sind, drehen Sie den Schalter.

Der Gedanke dahinter ist, dass es wahrscheinlich alle Arten von subtilen Abhängigkeiten und Annahmen, die Sie nicht gedacht haben. Während unwahrscheinlich, die neueste Version eines bestimmten Moduls (möglicherweise sogar ein Kernmodul, obwohl das noch unwahrscheinlicher) könnte einen subtilen Unterschied müssen die, die Sie verwendet haben. Sofern Sie nicht erschöpfend durch Ihre gesamte Code-Basis gegangen sind, gibt es möglicherweise ein bestimmtes Modul, das nur unter bestimmten Umständen erforderlich ist.

Sie können dies versuchen und vor Ort durch eine Liste aller Ihrer Skripte bauen - eine Liste, die Sie sowieso, vermöge den gesamten Code ist unter Versionskontrolle (Sie sind mit der Versionskontrolle haben sollte, zB Subversion , ja?) - und durch sie laufen, auf jedem Skript ausgeführt perl -c. z.B. dieses Skript . Diese Art von automatisierten Test ist von unschätzbarem Wert: Sie festlegen können, es läuft, gehen weg für einen Kaffee oder was auch immer, und kommen zurück, um zu überprüfen, ob alles funktioniert. Die ersten paar Male Sie werden wahrscheinlich ein obskures Modul finden, die Sie vergessen haben, was in Ordnung ist: der ganze Sinn der Automatisierung ist dies so, dass Sie müssen die drudge-Arbeit nicht tun jedes einzelnes Skript zu überprüfen.

Als ich es tat, brachte ich die neuere Version in ein separates Verzeichnis. Es gibt ein wenig mehr Verwirrung laufen zwei Versionen, aber es hilft auf jeden Fall sicher, dass alles zuerst machen die Arbeit und bietet einen schnellen Weg zu den alten Schalt zurück in eine Prise. Ich auch Apache hat zwei getrennte Dienste laufen, so dass ich konnte um Affen mit dem neueren Perl in einem Dienst, ohne dass die Produktion eines auf dem alten Perl zu berühren.

Es ist wahrscheinlich viel klüger, im Nachhinein auf einem separaten Computer zu installieren, und machen Sie Ihre Tests gibt. Nehmen Sie jede Konfigurationsänderung Sie vornehmen müssen.

Nicht sicher, dass es über den Bau selbst-ich immer nur verwendet vorverpackten Binärdateien für Windows.

Ich bin mir nicht sicher, ob ich verstehen, genau das, was Sie fragen. Haben Sie eine Liste der Änderungen haben Sie an die 5,8 Make-Datei gemacht? Oder die Frage, wie eine solche Liste zu erhalten? Sind Sie fragen auch, wie um herauszufinden, welche über dem Basis Pakete installieren Sie von CPAN erhalten haben? Sind Sie auch fragen, wie zu testen, ob Ihre benutzerdefinierten Änderungen nicht die Pakete brechen, wenn man sich aus dem CPAN wieder bekommen?

Warum Sie nicht verwenden ActivePerl und sein „ppm“ Werkzeug (wieder) installieren Module?

alt text

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top