5

私はPerlプログラミングにとても慣れていません。ラマの本を読み終えたところです。これまでBashでスクリプトを作成してきましたが、Perlを試してみたいと思っています。これは、Bashスクリプトよりも優れています。

いくつかの標準モジュール（例：Getopt）といくつかのあまり標準的でないモジュール（例：PerlMagick）を使用するスクリプトを作成しています

ある時点で、Perlコードを配布したいと思っており、Perlやプログラミングについてあまり知らない人でも使用できるようにしたいと思っています。明らかに、標準モジュールは常に存在する必要があります（これをある程度保証するために、「5.010を使用」を使用しています）が、非標準モジュールはどうでしょうか。

2つの可能性があると思います：1）不足しているモジュールをインストールするようにエンドユーザーに指示する必要がありますか？2）モジュールをテストするインストールスクリプトを作成する必要がありますか？モジュールがない場合は、インストールしますか？選択肢2を選択した場合、モジュールをダウンロードしてインストールする必要がありますか？または、メインコードと一緒に配布しますか？そんなことでエチケットがどうなっているのかよくわかりません...

アドバイスありがとうございます、ベン

4

3 に答える 3

5

アプリをPerlディストリビューション（CPANで使用される）として設計すると、Perlツールチェーンの力を利用してこの種のことを処理できます。依存しているモジュールがに正しくリストされていることを確認するだけで、アプリケーションとそれに必要なすべてのものを取得するためにMakefile.PL誰かが書くだけで済みます。cpan YourApp::Nameまたは、CPAN以外の場所からアプリをダウンロードし、手動でビルドしている場合、makeプロセスはそれらの依存関係を見つけることができます（これが、Module::AutoInstall完全に死んでいるわけではなく、IMOに値しない理由です）。

Windowsユーザーの場合、cpan YourApp::Name手順の前に追加する必要があるのは「StrawberryPerlのインストール」だけです。

バンドルするオプションもあります（PARが含まれるか、アプリと必要なすべてのモジュールの両方を含むインストーラーまたはアーカイブ、そしておそらくperlそれ自体が含まれるかどうか）が、この手法には1つの大きな欠点があります。つまり、どちらもできないということです。 XSコードを使用するか、アプリでサポートするプラットフォームごとに個別のパッケージを提供する必要があります。CPANルートはその問題に遭遇しません。

于 2010-07-13T00:28:11.137 に答える
3

それらを実行可能ファイルに変換できます。perlcc、perl2exe、PAR、Perl開発キットなどを試すことができます。

于 2010-07-13T00:04:57.510 に答える
1

そして、それらをprelccまたはperlappでコンパイルしたくない場合は、任意の可能性が機能します。

  • Perlコードが「@INCでData/UUID.pmが見つかりません（@INCに含まれるもの：...）」のようなエラーメッセージを要求しないように、存在する正しいバージョンのモジュールを確認する必要があります。例えば：

    eval { use Data::UUID; };
if( $@ ) { 
        print "Data::UUID not found\n"; 
}

    また

    eval { use Text::ParseWords 3.23; }; 
if( $@ ) { 
        print "Text::ParseWords 3.23 not found\n"; 
}

  • CPANモジュール（またはUNIXのcpanプログラム）を使用してみることができます。同様に、シェルコマンドを試すことができます：

    cpan Data::UUID

    またはperl-scriptから：

    #!/usr/bin/perl
use CPAN;
CPAN::install("Data::UUID");
于 2010-07-13T00:17:06.013 に答える