私はperlでいくつかのアクションを実行するエージェントの作成に取り組んでいます。.pm形式のいくつかのモジュールといくつかのライブラリを使用します。次に、それを1つの実行可能ファイルとして変換して、その1つのファイルをコピーしてn個のサーバーにインストールできるようにします。それは私がperlで達成できるものですか?私はperlの初心者です。おそらく私の質問はばかげているように聞こえるかもしれませんが、それは私に何かを教えてくれます。
3 に答える
一部のモジュールはPerlに含まれているため、別々のモジュールであっても、それらのモジュールをインストールしなくても、他のPerlインストールで機能します。これらには、、、が含まFile::Copy
れFile::Find
ますTime::Piece
。
すべての標準モジュールのリストは、Perldocホームページで確認できます。ドロップダウンバージョンフィールド(左側にあります)を、使用しているバージョンに設定してください。Solaris上にあるPerl5.8.8にまでさかのぼります。
必要なモジュールがすでに標準のPerlディストリビューションに含まれている可能性は十分にあるので、心配する必要はありません。場合によっては、使用されている非標準モジュールを、ほとんど書き換えのない標準モジュールに置き換えることができます。
一部のモジュールにはコンパイル済みのCコードが含まれており、再配布できません。それらは、実行してインストールされているマシンでコンパイルする必要があります。ただし、ほとんどのモジュールは純粋なPerlモジュールであり、プログラムで再配布できます。
モジュールが標準モジュールではなく、純粋なPerlモジュールである場合、再配布する方法は2つあります。
- Perlには、
@INC
モジュールを検索するときに検索するディレクトリを示すリストがあります。ディレクトリを追加できるPerluselibプラグマがあります。プログラムのサブディレクトリとしてモジュールを含めてから、構造全体を圧縮することができます。ユーザーは、プログラムと必要なモジュールを含むディレクトリツリー全体を解凍します。ちなみに、デフォルト@INC
には通常、現在のディレクトリが含まれています。 - もう1つの方法は、モジュールをプログラムに追加してから、
use
そのモジュールのステートメントを削除することです(これはファイルの一部であるため)。これは少し注意が必要ですが、単一のプログラムファイルを意味します。
モジュールには別のモジュールが必要な場合があることを覚えておいてください。十分に確認してください。
もう1つできることは、モジュールをチェックすることです。モジュールがない場合は、CPANからダウンロードします。テストは簡単です:
BEGIN {
eval {
require My::Module; Module->import( LIST );
};
if ($@) {
die qq(Module doesn't exist);
}
}
もちろん、それを行うのdie
は一種のばかげたuse
ことです。ただし、 CPANモジュールプログラマーのインターフェイスを介してモジュールをロードする代わりに、可能である可能性があります。私はそれをしたことがありません、そして私は持っている人を知りません。しかし、それは可能です。
したがって、最善の策は、プログラムが標準のPerlモジュールを使用しているかどうかを確認し、使用していない場合は、それらを使用するようにプログラムを変更できるかどうかを確認することです。たとえば、プログラムでを使用している場合は、代わりArchive::Zip
にを使用するようにプログラムを変更できる可能性があります。IO::Uncompress::Unzip
IO::Compress::Zip
それ以外の場合は、インストール用にこれらのモジュールを含めるか(再帰性と非純粋なPerlモジュールを監視する)、モジュールがインストールされていないことを検出してプログラムでインストールするかを選択します。
pp
で提供されるスクリプトは、PAR::Packer
単一ファイルの実行可能ファイルを作成できます。そのページからの例:
pp -o foo foo.pl bar.pl # Pack 'foo.pl' and 'bar.pl' into 'foo'
答えは少し複雑です。
Perlの性質上、ほとんどのユースケースでperlスクリプトをコンパイルすることは事実上不可能であるため、単一の実行可能ファイルを(Windowsの意味での実行可能ファイルとともに)配布できます。同様のことをする方法はいくつかありますが、残念ながら私はそれらを知りません。
ただし、実際には、Perlソース(スクリプト+モジュール)を含む任意のCアプリケーション内にPerlインタープリターを埋め込むことができます。すべてのCライブラリを静的にリンクする場合、これも機能するはずです。その後、PerlAPIを使用してスクリプトを呼び出すことができます。
ターゲットとするすべてのサーバーが、まったく同じライブラリを使用してまったく同じOSを実行することが保証されており、できればある種の* nixである場合、必要なすべてのファイルをアーカイブにパックして、インストールスクリプトを作成できます。解凍しようとしているアーカイブを含む自己解凍型シェルスクリプトを作成することができます。同じことがperlにも当てはまり、特別な__DATA__
コマンドとDATA
ファイルハンドルを使用します。
#!/usr/bin/perl
print for <DATA>;
__DATA__
1
2
3
プリント
1
2
3
データをにパイプするのにtar
も最適です。
すべての依存モジュールとすべてのコンパイル済みライブラリをファイルに含め、すべてのファイルを正しい場所にインストールするためのメタデータシステムを理解する必要があります。
原則として、ソフトウェアは、バイナリファイルをコピーするだけでなく、ターゲットシステム自体でコンパイルする必要があります。アーキテクチャの違い、構成ファイル、またはビューから隠された特別な登録エントリを見落とすのは簡単です。
cpan
異なるシステムをターゲットにする必要がある場合は、インストールの大部分を任意のperlパッケージマネージャーに委任するスクリプトを作成する方がよい場合があります。これは、ファイルパスをハードコーディングするよりも柔軟性があります。
#!/bin/bash
cpan install Foo::Bar
cpan install Acme
cpan install ...
# etc.
私はそれに固執します。
最も洗練された解決策は、CPANからダウンロードしたもののような独自のパッケージまたはディストリビューションを作成することです。すべての依存関係を参照するメタデータファイルを含めると、cpanはそれ自体ですべてを把握し、場合によっては必要なコンパイルを実行します。これは必ずしも初心者向けのトピックではないと思いますが、最大限の柔軟性と保守性が得られます(アップグレードが簡単です!)。これにより、いくつかのインストールテストを含めるのがかなり簡単になります。
これは初心者向けです。インターネットやもっと知識のある人が詳しく説明してくれると思います。