6

これは、 Perl アプリケーションの開発に関する以前の質問へのフォローアップです。を使用して CPAN モジュールとしてアプリケーションを開発するとしますModule::Install。ここで、たとえば を使用してコードを本番サーバーにアップロードし、 にgit pushリストされているアプリケーションの依存関係をインストールしたいと考えていますMakefile.PL。単純に を実行するcpan .と、通常の Perl モジュールのようにアプリケーションをインストールしようとします。モジュールとドキュメントをシステム全体の標準 Perl ディレクトリにコピーし始めます。

これが本来あるべき姿ですか？アプリケーションを標準の Perl ディレクトリにインストールしますか? Perl アプリケーションを 1 つのディレクトリに、別のlib. そうしないと、パスのどこかにリソースをインストールするなど、他の多くのことを管理する必要があるようです。宣言された deps をインストールしMakefile.PL、アプリケーション テストを実行してすべてが機能することを確認したい場合は、どうすればよいですか?

(これはどこかに文書化されていますか? つまり、自明ではない Perl アプリケーションをデプロイおよび更新するためのベスト プラクティスのようなものはありますか? それとも、誰もが独自の方法でこれを行っているのでしょうか?)

4

3 に答える 3

9

誤解されているかもしれませんが、あなたが探しているのは

perl Makefile.PL
make installdeps
于 2009-11-10T16:49:17.430 に答える
9

Module::Installを使用している場合、実際には裏でExtUtils::MakeMakerを使用しています。MakeMaker のすべての機能とそれが提供するターゲットを使用できます。ドキュメントはすべての機能を示しているわけではありませんが、生成されたMakefile.

しかし、MakeMakerこれは古いニュースであり、ほとんどの人がサンタクロースに消えてほしいと頼んでいます。独自のターゲットとプロセスの作成など、より適切な制御が必要な場合は、Module::Buildを使用すると、クロスプラットフォームと同様に操作が桁違いに簡単になります (同じ OS で別makeの 、 、またはその他のものを使用しないことを意味する場合でも)。gmake別のボックスで)。通常のコンシューマ グレードのインストール プロセスから逸脱すると、MakeMaker.

ビルド ファイルの簡潔さを高く評価する人もいますが、Module::Installビルド ファイルを一度構築すると、ビルド ファイルをいじるのに多くの時間を費やさないため、実際のメリットはあまりありません。あなたが得たわずかな利益があなたをロックするときMakeMaker、それはまったく勝利ではありません.

2014 年の更新: Module::Buildは人気がなくなり、メンテナーが必要になりました。人々がそれを使用して XS モジュールを構築および配布できるようになるまでには、まったく到達しませんでした。Perl v5.19 で非推奨になりましたが、CPAN から入手することはできます。

于 2009-11-10T19:50:52.307 に答える
4

Module::ScanDepsを調べて、インストールする依存モジュールのリストを生成できます。または、すべてを「アプリ」としてパッケージ化するためのPar::Packer 。

于 2009-11-10T15:09:36.603 に答える