nDiki : blib

[ Perl ] PDL::PP で C extension を書く

PDLを使ったPerl数値処理プログラムによりインタラクティブ性が求められるようになってきたので、一部をCで書いて高速化する事を検討。 問題は Linux でも Windows + ActivePerl でもすんなり動くかどうか。

.pd ファイルを書く

とりあず PDL::PP のサンプルから sumit 関数あたりを MathEx.pd に書いておく。

Makefile.PLを修正する

Foo::Bar パッケージの中の Foo::Bar::Math の一部を Foo::Bar::MathEx に移して、C extension 化したい。 ということで lib/Foo/Bar/MathEx.pd として、Makefile.PL の各種設定をしてみる。

がどうもうまくいかない。 PDL::PP の Makefile.PLサポートは、Makefile.PL と同じ位置に .pd がある事を想定しているようなので、いろいろと小細工をしなければならない。 一方 Perl の XS は Foo::Bar のベース名から Bar.so を作る前提になっているようで、これまたパッケージの中の一部のモジュールをどうもXS化しにくい。

子Makefile.PLを作る

Perl の ext/SDBM_File を真似て、子 Makefile.PL を使ってみることにした。

 Foo-Bar-x.xx
   |
   +- Makefile.PL
   |
   +- lib
   |    |
   |    +- Foo
   |         |
   |         +- Bar.pm
   |         |
   |         +- Bar
   |              |
   |              +- Math.pm
   |              |
   |              +- MathNoEx.pm
   |              |
   |              ...
   |
   |
   +- blib/...
   |
   +- MathEx
   |    |
   |    +- Makefile.PL
   |    |
   |    +- MathEx.pd
   ...

パッケージディレクトリの下に MathEx ディレクトリを作り、そこに Makefile.PL と MathEx.pd を置く。 Makefile.PL は MathEx.pd 専用になるので、PDL::PP の標準的なものでOKになる。

全体のパッケージング・PPM化・インストール等が面倒にならないかと心配したが、Foo-Bar パッケージ化で perl Makefile.PL、make xxx を実行すれば子Makefile.PLまできちんと面倒をみてくれる。 MathEx 以下でビルドしたものもパッケージの blib に一緒に入れてくれるし(=一緒にインストールできる・PPM化できる)。 逆に make dist の際には子Makefileの方は余計なとりまとめはしないで、親Makefileが一括して tar.gz に入れてくれる。 これはよい。 MathEx.pd もきちんと Foo/Bar/MathEx.so になった。

XSが使えない環境との両対応

XSが使えない環境のために、PerlとPPの両方で関数を書いておく。 XSが使えれば MathEx を、使えなければ MathNoEx.pm を使うように。 表向きのAPIは Foo::Bar::Math とし、ここで AUTOLOAD を使ってどちらか一方を呼び出すようにする。 間接呼び出しにして遅くなるのはいやなので、シンボルテーブルを直接設定する。

 use vars qw($IMPLEMENT_CLASS $AUTOLOAD);
 BEGIN {
   $IMPLEMENT_CLASS = 'Foo::Bar::MathEx';

   eval "use $IMPLEMENT_CLASS";
   if ($@) {
     warn "Can't load $IMPLEMENT_CLASS: $@";
     $IMPLEMENT_CLASS = 'Foo::Bar::MathNoEx';
     eval "use $IMPLEMENT_CLASS";
     die $@ if $@;
   }
 }

 sub AUTOLOAD {
   my $name = $AUTOLOAD;
   $name =~ s/.*://;
   my $implement = $IMPLEMENT_CLASS . '::' .$name;
   no strict "refs";
   *{$name} = \&{$implement}; # ここでシンボルテーブル設定
   return &{$implement}(@_);
 }

最初は、AUTOLOAD の最後の行で die したら、trap してエラーメッセージ中のパッケージ名(Foo::Bar::MathEx や Foo::Bar::MathNoEx)を呼び出された Foo::Bar::Math に置換して die し直すようにしようかと思ったが面倒なのでやめ。

ActivePerl 5.6 + Visual C++ 6

使っているWindows BOX には Visual C++ 6 が入っているので、XSも問題なくビルドでき PDL extension もうまく動いた。

 PPM化までここで済ませば、他のPCにも持っていけるはず。

さて

これでバシバシPPで書けるわけだが、PPがこれまた難解で最初は苦労しそう。

[ Perl ] blib モジュール

wxPerl のサンプルを見ていて blib モジュールなるものを知る。 5.004 から既にあったもので、にカレントディレクトリ下の blib (あるいはいくつか上の階層にある blib )を @INC に追加してくれるモジュール。

 PERL5LIB=blib/lib:blib/arch blib/script/myscript

とするかわりに

 perl -Mblib blib/script/myscript

のようにスクリプトを実行できるようになる。

PAR で重複アーカイブされる

pp でうまく依存モジュールがアーカイブされていないようなので、確認しようと exe 化されたファイルを unzip。 ではじめて、同じモジュールが重複されたアーカイブされている事に気がつく。 blib の下で、

 pp -o foo.exe -a lib -a arch -M ... -c script/foo

としていたのだが、どうやら -M や -c でリストアップされたモジュールと -a で指定したものが重複していてもそのまま両方アーカイブしてしまっているらしい。

lib 以下に

• eval で use するため依存関係では自動抽出されない
• 画像ファイルなどのリソースもある

ということで '-a' で指定していたのだが。

これらのモジュールは -M で、リソースは -a でそれぞれきちんと明示的に指定しないと駄目か。 blib の下のファイルをスキャンするスクリプトをつくるかな。

nmake で毎回 pl2bat されるのを何とかしたい

EXE_FILES でインストールするスクリプトを指定してある Makefile.PL を ActivePerl 上で実行して nmake をかける。 また nmake する。

するとソースを書き換えてないにもかかわらず、EXE_FILES指定ファイルの blib/script へのコピーと pl2bat の実行が行われる。 嫌な感じ。

追いかけてみると

• UNIX上の場合 FIXIN *1 が blib/script にコピーされたスクリプトを上書きするため更新時刻が変更され、次の make では最新と判断される。
• Windows上の場合 FIXIN *2 は blib/script にコピーされたスクリプトからバッチファイルを生成する。このためコピーされたファイルの更新時刻は、ソースと同じのまま。依存関係で指定されている Makefile の方が新しいので次の nmake でも同じ処理が繰り返される。

というわけ。コピーした後 touch するようにすればよい。

 perl -MExtUtils::Command -e touch %1
 pl2bat %1

という内容の touchpl2bat.bat を作って

 nmake FIXIN=touchpl2bat

とすればきちんと更新時刻が反映されビルドは1回だけになる。 毎回指定するのは面倒なので、MSWin32 なら自動的にそうするようにパッケージングしたいのだが nmake で他にうまく FIXIN を上書きする方法がみつからず (MY::postamble で書き出しても、WriteMakefile(macro => {FIXIN => 'touchpl2bat'}, ...) しても駄目)。

---

[ ExtUtils::MakeMaker ]

「依存関係検査のしにくいモジュール」に依存するスクリプトをPARで実行形式化する

PAR を使うとPerlスクリプトを単独の実行可能形式ファイルに変換することができる。 この際、自動的に依存するモジュールも探し出して追加してくれるのだが、eval の中で use するものや lib 以下に配置された通常のファイル等は自分で追加する必要がある (pp の -a, -A, -M オプション等で)。

開発しているモジュールに含まれるスクリプトをexe化するルールは、Makefile.PL でいろいろ処理をしてこれらを指定するようにしておけば比較的簡単にビルドできる。

しかしそれが今開発対象となっているモジュール/スクリプトではなく、その依存モジュールがそのようになっていると面倒くさい。 ということで依存モジュール側で必要なモジュール・ファイル一式を PAR ファイル化し、それを作業中のモジュール/スクリプトで取り込むようにしてみた。

PAR の pp コマンドは(1つのPAR ファイルから実行形式ファイルを作る時以外)直接 par ファイルを取り込む事ができないようなので、展開してあらためて追加する必要があるのでちょっと面倒。

依存モジュールをまとめた par を作る

例えばそのモジュールに myscript.pl が含まれており、これをexe化するにはいくつか手動で追加するファイルを指定する必要があるとする。

またそれらのファイルは、現在作ろうとしているスクリプトをexe化する際にも必要だとする。

 pp -p -o all.par \
    -I blib/lib -I blib/arch \
    -A ... \
    -M ... \
    blib/script/myscript.pl

myscript.pl に必要なモジュールを含んだ PAR ファイル all.par ができる。

ちなみに parl -p でもモジュールからPAR ファイル化でき blib 以下をごっそりアーカイブできるのだが、そのモジュールが依存しているモジュールを含ませることができないので、今回の用途には×。

PAR ファイルを展開する

all.par を展開する。 ここでは c:\tmp\all 以下に展開するものとする。

作成したいスクリプトのPAR ファイルをいったん作る

スクリプトのあるモジュールのディレクトリに移動し、make。 その後

 pp -p -o newscript.par \
    -I blib/lib -I blib/arch -I c:\tmp\all\lib \
    -a c:\tmp\all\lib;lib \
    blib/script/newscript.pl

newscript.par が出来上がる。この中には -a オプションの指定と、newscript.pl の依存関係検査による抽出で c:\tmp\all\lib 以下のファイルが2回含まれているものがある(大抵)。 無駄なので除去する。

(面倒ならば重複するファイルを含んだままではあるが、ここで -p オプションを指定しないで直接 exe を作る事も可能である)

除去するスクリプト(例)

 #!/usr/bin/perl -w
 use strict;
 use Archive::Zip qw(:ERROR_CODES);
 my $zip_name = shift || die 'must provide a zip name';
 my $zip = Archive::Zip->new;
 $zip->read($zip_name) == AZ_OK || die "Can't read $zip_name:\n";

 my %names;
 for my $member ($zip->members) {
   my $file_name = $member->fileName;
   if (exists $names{$file_name}) {
     print "Remove $file_name ...";
     if (defined $zip->removeMember($member)) {
       print "OK.\n";
     }
     else {
       print "NG.\n";
     }
   }
   $names{$file_name}++;
 }

 exit($zip->overwrite);

PAR ファイルを実行可能形式ファイルに変換する

 pp -o newscript.exe newscript.par

Module::Build でソースパッケージング

ExtUtils::MakeMaker

私が Perl が好きな理由の一つに、標準でExtUtils::MakeMakerという Makefile ジェネレータがついているところである。これを使って Makefile.PL を書くと

 perl Makefile.PL
 make manifest
 make
 make test
 make dist

で <pacakge>-<versionno>.tar.gz というソースパッケージを作ることができ、

 tar zxvf <pacakge>-<versionno>.tar.gz
 cd <pacakge>-<versionno>
 perl Makefile.PL
 make
 make test
 make install

という手順でインストールする事ができるようになる。 パッケージの作り方が確立されているので、容易に新しいパッケージを開発しはじめられる。

逆に Java でプログラムを書くのが億劫なのは、このあたりの準備が面倒だからである。 Ant を使っても結局ここら辺自分でやらなければならないし。

ちょっとしたアーカイブの作成

ちょっとしたパッケージを作りたいと思うことは良くある。 例えばいくつかのデータファイルと、READMEファイルなんかをひとまとめにしてアーカイブにするとか。

本当にちょっとしたであれば、手動でアーカイブすれば良いのだが、

• アーカイブしたいファイル群がバージョン管理下にあって、CVS ディレクトリや .svn ディレクトリがある (除外してアーカイブする必要がある)
• 同じディレクトリにある、作業用のファイルはアーカイブしたくない (除外してアーカイブする必要がある)
• アーカイブする前に、チェック用のリグレッションテスト一式を走らせたい (リグレッションテストをかけられるようにする)
• UNIX でも Windows でもアーカイブ化できるようにしたい。

あたりを考慮しなければならない時は面倒くさくなってくる。

自動化としては

• シェルスクリプト/バッチファイルを書く
• Makefile を書く
• GNU Autotools を使う

あたりがぱっと思い浮かぶ。 しかし、最初の2つは毎回同じようなものを書くのが面倒だし保守もしにくい。 GNU Autotools はちょっとごっつすぎだし、Windows での環境構築も面倒。

ExtUtils::MakeMaker の欠点

ということで最初は ExtUtils::MakeMaker を使うという線で考えてみた。 もともと Perl モジュール用で汎用用途にはちょっと邪魔な振舞いもあるが、使えないことはないと思う。 しかし make (GNU Make あるいは nmake など) に依存しているという欠点がある。

Module::Build で

ということで ExtUtils::MakeMaker の代替である Module::Build ベースで汎用用途に使えないか検討してみた。こちらは pure Perl で make を必要としない。

Module::Build も Perl モジュールビルドにあわせた振舞いがあるものの、ちょっとカスタマイズすれば使えそうだ。 で、いろいろいじった結果、次のような感じにすると使いやすそうだ。

 use Module::Build;
 my $class = Module::Build
   ->subclass(class => 'NonmoduleBuilder',
              code => q{
                        # Don't make blib
                        sub ACTION_code {};
                        # Don't make blib
                        sub ACTION_docs {};
                        # Don't make META.yml
                        sub ACTION_distmeta {
                          # no warning on ACTION_distdir
                          $_[0]->{metafile} = 'MANIFEST';
                        };
                        # Don't add MEATA.yml to MANIFEST
                        sub ACTION_manifest {
                          $_[0]->{metafile} = 'MANIFEST',
                          $_[0]->SUPER::ACTION_manifest(@_);
                        };
                       });

 # Set your archive name and version.
 $class->new(dist_name => 'mypackage',
             dist_version => '1.0.2',
             )->create_build_script;

カスタマイズした部分は以下(Module::Build 0.26 で動作確認)。

• Perl モジュールビルドに特有の blib ディレクトリを作らないようにする。
• META.yml を生成しないようにし、アーカイブに含まれないようにする。

上記のようなファイルを Build.PL という名前で作っておけば

 perl Build.PL
 ./Build manifest
 ./Build
 ./Build test
 ./Build dist

等として、アーカイブ作成が容易にできるようになる。

しばらくこの方法でいろいろ試してみることにしてみよう。

PAR::Repository でビルド済み Perl モジュールをネットワーク配信

実行可能ファイル作成としての PAR

PAR といえば Perl スクリプトを実行可能ファイル(Windows なら EXE 形式ファイル)に変換するモジュールとして有名である。

ちなみに実行可能ファイルを作成する部分はは PAR 0.97 より PAR-Packer パッケージに分けられ、PAR 自体はインストールしやすい pure Perl なパッケージになっている。

PAR モジュールアーカイブからのローダとしての PAR

PAR が提供するもう一つの(こちらが本来はメイン?)機能は、プログラムの実行時に必要な Perl モジュールを PAR ファイルと呼ばれる Perl モジュールアーカイブファイルからロードする機能である。 XS モジュールなどもコンパイルすることができるどこかの環境で1度ビルドして PAR ファイルにしておけば、同じアーキテクチャのホスト上でそのまま利用することができる。

PAR リポジトリ

ロードしたい PAR ファイルはファイルパスだけではなく URL でも指定することができ、必要な時にオンデマンドでフェッチさせることができる。 これを使えば Perl プログラムの集中管理可能だ。

PAR 0.951 からは PAR リポジトリというコンセプトが追加され、パッケージ毎に作った PAR ファイルをサーバ上(あるいはローカル)のリポジトリに蓄積してオンデマンドでロードできるようになった。

個別に PAR ファイルを指定する従来の方式に比べてかなり便利そうである。 ということで試用してみた。

まずは

• PAR
• PAR::Repository
• PAR::Repository::Client
• PAR::Repository::Query
• PAR::Dist
• PAR::Packer

あたりをインストールし準備 OK。

1. PAR リポジトリを作成する

最初に PAR-Repository に含まれている parrepo で。

 parrepo create -r /tmp/PAR

PAR リポジトリファイルの中にはデータベースファイルが作成されるが、これは DBM::Deep というアーキテクチャ非依存のものを使っているので、Linux でも Windows でもどちらからでもアクセス可能である (つまり Linux 上でリポジトリをメンテできるということだ)。

2. Perl パッケージを PAR ファイル化する

次に必要な PAR ファイルを作成する。 作成したいパッケージを展開してビルドし、blib ができている状態で PAR::Dist を使ってパッケージ化する。

 perl Makefile.PL
 make
 make test
 perl -MPAR::Dist -e blib_to_par

例えば ActivePerl*1 上で WWW-Mechanize-1.20 を PAR ファイル化すると

 WWW-Mechanize-1.20-MSWin32-x86-multi-thread-5.8.8.par

というファイルが作成される。

普段から ActivePerl で必要なライブラリは基本的に自前で PPM パッケージ化して、動作確認した上で PPM リポジトリに蓄積するようにしているので、合わせて次の手順でパッケージを作ることになる。

 perl Makefile.PL
 nmake
 nmake test
 perl -MPAR::Dist -e blib_to_par
 make_ppm

3. PAR リポジトリに PAR ファイルを登録する

PAR ファイルができたら parrepo でリポジトリに登録する。

 parrepo inject -r /tmp/PAR -f xxx.par

4. PAR リポジトリ上のライブラリを使用してみる

例えば先ほどの WWW::Mechanize がリポジトリに登録されている状態で

 #!/usr/bin/perl
 use PAR { repository => 'file:///tmp/PAR/' };
 use WWW::Mechanize;
 my $mech = WWW::Mechanize->new;
 $mech->get('http://www.example.com');
 print $mech->content;

というスクリプトを書いて実行すると、PAR リポジトリから WWW::Mechanize がロードされて正しく実行される。

ここでリポジトリを Web サーバへアップロードして、repository のところに URL を指定するようにすることもできる。 例えばリポジトリを http://www.example.com/PAR/ に配置したとすると

 #!/usr/bin/perl
 use PAR { repository => 'http://www.example.com/PAR/' };
 use WWW::Mechanize;
 my $mech = WWW::Mechanize->new;
 $mech->get('http://www.example.com');
 print $mech->content;

と書き換えることで、インストールしていない WWW::Mechanize を使用できるようになる。

Perl プログラムを実行形式化する

先ほどの Perl スクリプトを get_top_page.pl という名前で保存して pp で実行可能ファイル化する。

 pp -o get_top_page.exe -M PAR::Repository::Client get_top_page.pl

とすれば get_top_page.exe という実行可能ファイルが作成される。 WWW::Mechanize はオンデマンドで http://www.example.com/PAR/ からフェッチされるので、アップデートが必要な場合は新しい PAR ファイルを作成してリポジトリを更新するだけでよい。 EXE ファイルを作成しなおして利用者に配付しなすといった作業も不要だ。

スクリプトもリポジトリにおく

さらには実行するスクリプトをも PAR リポジトリに置いておくことが可能だ。

例えば WWW-Mechanize に含まれている mech-dump をオンデマンドにフェッチして実行する実行形式ファイルは以下のコマンドで作成できる。

 pp -o mech-dump.exe -M PAR::Repository::Client \
   -e "use PAR { repository => 'http://www.example.com/PAR/', \
                 run => 'mech-dump' }"

まとめ

ActivePerl では PPM があるとはいえ、普通のユーザにちょっとしたプログラムを使ってもらうのに「ActivePerl をインストールして、PPM パッケージをインストールして、……」というのは手間すぎる。

pp で プログラムに必要なものを全てバンドルした実行形式化ファイルにするという方法ももちろんあるのだが、頻繁にアップデートするようなスクリプトの場合には、起動のための部分だけ pp で作成しておいてあとは PAR リポジトリで集中管理するというのもちょっと魅力的である。

Perl スクリプトを PAR ファイルにして PAR リポジトリに登録する

PAR リポジトリから Perl モジュールをネットワーク配信するためには、以下の手順で PAR ファイルを作成する。

 perl Makefile.PL
 make
 make test
 perl -MPAR::Dist -e blib_to_par

blib ディレクトリ以下のファイルもとに PAR ファイルが作成されるので、でき上がった PAR ファイルを リポジトリに登録すれば良い(PAR::Repository でビルド済み Perl モジュールをネットワーク配信)。

ではちょっとした Perl スクリプトを PAR リポジトリからロードして使えるようにするにはどうすればよいか。もちろん h2xs などで一式そろえ make して blib ツリーを作るようにすればいいが、たった 1 つのスクリプトファイルだけの時などは大袈裟だ。

この場合は pp でいける。

 echo 'print "hello world!"' > myscript.pl
 pp -o myscript.par -p myscript.pl
 parrepo inject -r /tmp/PAR myscript.par -v 1.00 \
   -a MSWin32-x86-multi-thread -p 5.8.8 \
   --any-arch --any-version

スクリプトのメタデータがないので、parrepo に登録する際に明示的にオプションで指定してあげる必要がある。

-v

プログラムのバージョン番号

-a

アーキテクチャ

-p

Perl のバージョン

--any-arch

アーキテクチャ非依存で動くならば指定しておく

--any-version

任意の Perl のバージョンで動くならば指定しておく。

PAR ファイル(にした Perl スクリプト)が --any-arch で --any-version であっても、-a と -p は必須だ (PAR::Repository の中にアーキテクチャ/バージョンつきで登録された上でシンボリックリンクの形で any 扱いにされるため)。

これで PAR リポジトリからスクリプトを実行できるようになる。 スクリプトの更新もリポジトリ側で行うだけで良くなる。

 perl -e "use PAR { repository => 'http://www.example.com/PAR/',
                    run => 'myscript.pl'}"

お好みで実行形式ファイルにしておけば Perl をインストールすることなく実行できるようになるので便利。

 pp -o myscript.exe -M PAR::Repository::Client \
   -e "use PAR { repository => 'http://www.example.com/PAR/',
                 run => 'myscript.pl'}"

ちなみに PAR リポジトリを使わずに、直接 PAR ファイルを指定して実行できることもできる。

 perl -e "use PAR { file => 'http://www.example.com/myscript.par', \
                    run => 'myscript.pl' }

ちょっとした用途ではこちらでも良いけれど、アーキテクチャ別の管理やらモジュールの管理やらを考えると PAR リポジトリを作ってしまった方が楽。