Perl 5.18 時代における Core module についての捉え方について - tokuhirom's blog
Perl 5.20 で、CPANPLUS とその依存モジュールたちが core distribution から分離されます。 また、5.22 では CGI.pm と Module::Build が分離されそうです。 ここにいたり、Perl 5 の core distribution にはいっている、ということの意味が徐々にかわってきつつあります。 では、現在の状況はなぜおきているのかを考えてみましょう。 configure_requires の普及Perl 5.8.5 あたりの時代では、Module::Build などは core distribution にはいっていないと、つらかったわけですが、configure_requires が普及したことにより、インストーラを CPAN shell で自動的にインストールすることができるようになりました。 これにより Module::Build
Perl のモジュールローダー選定委員会 - tokuhirom's blog
UNIVERSAL::require$module->require() or die $@ ってかけるのが cool という話ではあるのだが、UNIVERSAL をつかうのに抵抗があるかもしれない。 そして、Module::Load にたいする優位性はとくにないので、最近はあまりつかってない。 Class::Load上記2つにくらべると、機能がおおい。これは Moose から派生したパッケージで、Moose の is_class_loaded 相当の機能もそなえている。 Moose 由来ということで、%INC の中にはいっていなくても、package がすでにつかわれていれば、ファイルをよみにいかないという点がすぐれている。具体的には package Foo; sub bar { } package main; use Class::Load qw/load_class/; load_c
Module::Build と EU::MM と M::I と dzil にかんする雑感(miscellaneous thoughts) - tokuhirom's blog
Module::Build の目標は make の排除だとおもうのだが、現実的には、EU::MM に依存している場合には make が必要だし、ある人のモジュールだけが make なしではいるようになってもとくにうれしくはない。 つまり、移行するメリットが薄い。よって、流行らなかったのだとおもう。 おぼえることがふえるのやだし。 EU::MM はもはや積極的に開発はされないようだが、普通に使う分にはもんだいないし、メンテナンスはされてる。 単純な pure perl のモジュールなら、これをそのままつかっても問題はない。 ただし、ちょっとこった実行時の処理などをやろうとすると、よみづらい Makefile.PL ができあがる傾向があるようにおもう。 クールなインターフェースを提供してくれる。プラガブルで拡張可能だ。 日本では、Plagger で M::I が採用されたことを契機に、一気にひ
第25回 Module::Starter：モジュールを書くためのテンプレート | gihyo.jp
モジュールを再利用可能にするためのツールたち Perl 4の時代まではいざ知らず、いまどきPerlのモジュールやアプリケーションを再配布しようと思ったら、CPANモジュールと同じ形式にしておくのがベタープラクティスです。たとえ一般には公開しない社外秘のモジュールであっても、Makefile.PLやBuild.PLを用意して、テストも書いて、できればREADMEやChangesなどの更新履歴もつけておけば、別のプロジェクトを立ち上げたときにコピー＆ペーストする必要もなくなりますし、業務の引き継ぎなども簡単になります。 とはいえ、モジュールを書くたびにMakefile.PLなどを一から書きおこすのは面倒な話。メタ情報の部分はモジュールごとに異なるとはいえ、それ以外の部分は（特にひな形の時点では）大差ないのがふつうですから、できれば省力化したいところです。 今回はそんなときに使われるひな形作成ツ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
最近は local::lib を直接つかわないでもいきていけるという話 - tokuhirom's blog
