仕事では、Windows で Perl 5.8.0 を使用しています。
最初に Perl をインストールしたとき、CPAN に移動し、すべてのソースをダウンロードし、(スレッドをサポートするために .MAK ファイル(?) などで) いくつかの変更を行い、 // を実行しましnmakeた。次に、少しずつ、CPAN から個々のモジュールをダウンロードし、nmake ダンスを実行しました。nmake testnmake install
したがって、より新しいバージョンにアップグレードしたいのですが、新しいバージョンは既存のスクリプトを壊してはなりません。特に、私がインストールした一連の「使用」モジュールは、新しいバージョンにインストールする必要があります。
現在のバージョンを更新するための最も信頼できる (そして最も簡単な) 方法は何ですか?
他の人が指摘したように、新しい perl を別の場所にインストールすることから始めます。いくつかの perl がインストールされており、それぞれが他のすべての perl とは完全に分離されています。
そのためには、ソースを自分で構成してコンパイルする必要があります。を実行configureすると、インストーラーを指定する機会が得られます。これについては、The Perl Review の 2008 年春号の「Compiling My Own Perl」で詳細な手順を説明しました。それを行う方法を示す効果的な Perl プログラミングの項目もあります。
次に、元のディストリビューションに戻り、実行cpan -aして autobundle ファイルを作成します。これは、インストールしたすべての余分なものをリストする Pod ドキュメントであり、CPAN.pm はそれを使用してすべてを再インストールする方法を理解しています。
新しい perl にインストールするには、その perl のパスを使用して CPAN.pm を起動し、作成した autobundle ファイルをインストールします。CPAN.pm は、その perl の構成から正しいインストール パスを取得します。
出力を見て、うまくいくことを確認します。このプロセスでは、同じバージョンのモジュールはインストールされませんが、最新バージョンがインストールされます。
Strawberry Perlに関しては、デフォルトの場所以外の場所にインストールできる「ポータブル」バージョンがあります。そうすれば、新しい perl をリムーバブル メディアに入れることができます。ローカル インストールを妨げることなく、好きな場所でテストできます。ただし、一般的な使用の準備が整っているとは思いません。Berrybrewツールは、それを管理するのに役立つかもしれません。
幸運を、 ：）
Strawberry Perlの使用を真剣に検討します。
Perl の 2 番目のバージョンを別の場所にインストールできます。非コア モジュールを新しいバージョンに再インストールする必要があります。一般に、異なるバージョンの Perl はバイナリ互換性がありません。これは、XS コンポーネントを使用するプログラム固有のライブラリがある場合に問題になる可能性があります。Pure Perl モジュールは影響を受けません。
5.8 トラック内にとどまる場合、同じ 5.8 シリーズ内でバイナリ互換性が保証されているため、XS (バイナリ) 拡張機能を含むすべてのインストール済みモジュールは引き続き機能します。5.10 に移行した場合、XS コンポーネントを含むすべてのモジュールを再コンパイルする必要があります。
必要なことは、新しいビルドが @INC 配列 (モジュールの検索に使用される) に以前のインクルード ディレクトリをリストしていることを確認することだけです。
その音から、あなたは Windows を使用していると思います。その場合、現在の @INC パスは次のコマンドで表示できます。
perl -le "print for @INC"
別のディレクトリで新しい Perl バージョンをターゲットにしていることを確認してください。以前のバージョンと問題なく共存できます。これにより、どの Perl インストールを使用するかを選択できます。PATH の順序を整理するだけの問題です。Perl インタープリターは、起動するとすぐに、残りのモジュールを探す場所を認識します。
Strawberry Perl は、おそらく最近の Windows で独自のロールを作成するのに最適なディストリビューションです。
私がそれをしたとき、私は新しいものを別のディレクトリにインストールしました。2 つのバージョンを実行すると少し混乱が生じますが、最初にすべてが機能していることを確認するのに役立ち、ピンチで古いバージョンにすばやく切り替える方法が提供されます。また、2 つの別個のサービスを実行するように Apache をセットアップしたので、古い Perl の運用サービスに触れることなく、1 つのサービスで新しい Perl をいじることができました。
後から考えると、別のコンピューターにインストールして、そこでテストを行う方がおそらくはるかに賢明です。必要なすべての構成変更を記録します。
自分でビルドするかどうかはわかりません。私は常に、Windows 用のパッケージ化されたバイナリを使用していました。
あなたが求めていることを正確に理解しているかどうかはわかりません。5.8 メイクファイルに加えた変更のリストはありますか? それとも、そのようなリストを取得する方法の問題ですか? また、CPAN から取得した基本インストールの上にあるパッケージを見つける方法も尋ねていますか? また、CPAN から再度パッケージを取得した場合に、カスタムの変更によってそれらのパッケージが壊れないことをテストする方法も尋ねていますか?
これに対する答えには、ある種の仮想化が含まれると思います。
この背後にある考え方は、おそらく、あなたが考えもしなかったあらゆる種類の微妙な依存関係と仮定があるということです。可能性は低いですが、特定のモジュールの最新バージョン (コア モジュールである可能性もありますが、それはさらにありそうもないことです) は、使用していたものと比べて微妙な違いがある場合があります。コードベース全体を徹底的に調べていない限り、特定の状況でのみ必要な特定のモジュールが存在する可能性が非常に高くなります。
すべてのスクリプトのリストを作成することで、これを見つけることができます-バージョン管理下にあるすべてのコードのくぼみによって、とにかく持つべきリストです（バージョン管理、たとえばSubversionを使用していますか？）-そして繰り返し各スクリプトで実行されます。たとえば、このスクリプト。この種の自動化されたテストは非常に価値があります。実行するように設定し、コーヒーなどを飲みに行って、戻ってきてすべてが機能しているかどうかを確認できます。最初の数回は、おそらく忘れていたあいまいなモジュールを見つけるでしょう。これは問題ありません。これを自動化することの全体的なポイントは、すべてのスクリプトをチェックするという面倒な作業を行う必要がないようにすることです。perl -c
ActivePerl とその "ppm" ツールを使用してモジュールを (再) インストールしてみませんか?
