一般的な Perl モジュールのソースパッケージに含まれる Makefile 生成スクリプト。
PDL を使用しているプログラムの高速化のため、再び PDL::PP でコードを書こうとマニュアルを見直したりしている。
PDL::PP にも Inline 系の Inline::Pdlpp モジュールが用意されているのか。 PDL::PP の仕様は結構わかりにくくて(かなり)慣れないと大変。 何度も書いてはテストしてみることになるので、そういった意味でも Inline できるのはすごい便利。
Inline::Pdlpp で関数ができあがったら 整理して PDL::Core::Dev のサポートのもとで Makefile.PL を書くようにすれば、いっちょあがり。
インストール方法は「Instant Client10g」を参考にした。
Oracle Technology Network License のもとで配布されている、Oracle Database 10g の instant client を利用する。 30日間試用可能。
をダウンロード。
/usr/local/oracle の下に展開。シンボリックリンクをいくつか設定する。
mkdir /usr/local/oracle cd /usr/local/oracle unzip /tmp/instantclient-basic-linux32-10.1.0.3.zip unzip /tmp/instantclient-sdk-linux32-10.1.0.3.zip unzip /tmp/instantclient-sqlplus-linux32-10.1.0.3.zip cd instantclient10_1 ln -s . lib ln -s libclntsh.so.10.1 libclntsh.so ln -s libocci.so.10.1 libocci.so
環境変数を設定する
export ORACLE_HOME=/usr/local/oracle/instantclient10_1 export LD_LIBRARY_PATH=$ORACLE_HOME:$LD_LIBRARY_PATH
まずはソースアーカイブを展開。
tar ztvf DBD-Oracle-1.16.tar.gz cd DBD-Oracle-1.16
次に Makefile.PL を編集
5a6,7 > push(@ARGV, '-l'); > 279c281 < my @h_dirs = find_headers(); --- > #my @h_dirs = find_headers(); 283c285 < push @h_dirs, 'network/public'; --- > #push @h_dirs, 'network/public'; 289c291,292 < my $inc = join " ", map { "-I$OH/$_" } @h_dirs; --- > #my $inc = join " ", map { "-I$OH/$_" } @h_dirs; > my $inc ="-I/usr/local/oracle/instantclient10_1/sdk/include"; 725c728 < exit 0; --- > #exit 0; 1606a1610 > 1;
ヘッダファイルディレクトリ自動取得を止めて決め打ちにし、また Makefile.PL 実行時に -l を指定するようにする。 それから dh-make-perl がモジュール依存関係取得するため Makefile.PL を require した際に真を返さないでエラーになってしまうようなので、これも修正。
でパッケージ化。
rm META.yml # あると dh-make-perl が deb パッケージ名をつけ間違える? dh-make-perl --build --notest
deb パッケージ
libdbd-oracle-perl_1.16-1_i386.deb
ができあがるので、これを dpkg でインストール。
とりあえず、手近のサーバに接続して、簡単な select が動くことを確認。
いまのところ DBD::Oracle を使用するPerlプログラム実行時にも LD_LIBRARY_PATH を同様に設定しておく必要あり。
Makefile.PL 書き換え時に、
$opts{dynamic_lib}->{OTHERLDFLAGS} .= '-Wl,-rpath -Wl,/usr/local/oracle/instantclient10_1';
と -rpath を指定してみたが、
DBI connect('host=192.168.x.x;sid=dbsid','usr',...) failed: ERROR OCIEnvNlsCreate (check ORACLE_HOME and NLS settings etc.) at test.pl line 3 ERROR OCIEnvNlsCreate (check ORACLE_HOME and NLS settings etc.) at test.pl line 5.
というエラーが出て駄目。
私が 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ファイルなんかをひとまとめにしてアーカイブにするとか。
本当にちょっとしたであれば、手動でアーカイブすれば良いのだが、
あたりを考慮しなければならない時は面倒くさくなってくる。
自動化としては
あたりがぱっと思い浮かぶ。 しかし、最初の2つは毎回同じようなものを書くのが面倒だし保守もしにくい。 GNU Autotools はちょっとごっつすぎだし、Windows での環境構築も面倒。
ということで最初は ExtUtils::MakeMaker を使うという線で考えてみた。 もともと Perl モジュール用で汎用用途にはちょっと邪魔な振舞いもあるが、使えないことはないと思う。 しかし make (GNU Make あるいは nmake など) に依存しているという欠点がある。
ということで 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 で動作確認)。
上記のようなファイルを Build.PL という名前で作っておけば
perl Build.PL ./Build manifest ./Build ./Build test ./Build dist
等として、アーカイブ作成が容易にできるようになる。
しばらくこの方法でいろいろ試してみることにしてみよう。
ソフトウェアのレビュー日。 最近ミーティングの調整やドキュメントの作成などばかりで、ソースコードに触れる機会がほとんどなかったので Eclipse なんか入れちゃったりしてウキウキ。
……あれ? ビルドまだ自動化してないの? いや、普通まず最初にビルド自動化しておくでしょ。configure.ac とか Makefile.am とか Makefile とか Makefile.PL とか Build.PL とか書いちゃうでしょ。 Java ならまあ build.xml とか書いとくでしょ。 make dist (相当が)できるようなターゲット書いておくでしょ。
……無いのね。Eclipse でぬくぬく書いてるのね。コード書いている間はいいよ。 でもね、節目のビルドはね、そういうのでやってね。ビルドファイルの含めているソースアーカイブもコマンド一発で作れるようにしておいてね。
はい。では、書きますよ。今回は私が。 次はちゃんと書いてね。
WiKicker には依存している Perl モジュールとして、必須なものとオプションなものがある。 必須なものは例えば Log::Log4perl など。 一方 Cache::Memcached や HTML::Scrubber などは、追加機能を使用したい場合のみ必要である。
一般的な Perl モジュールパッケージと同様、WiKicker では Makefile.PL に ExtUtils::MakeMaker を使っている。 必須な依存 Perl モジュールは PREREQ_PM に指定してあるが、オプションのものについては独自にチェックして警告をするにとどめていた。 しかしこれだと、オプションのものは CPAN.pm を使って自動的にインストールすることができない。
ということで検討した結果、Module::Install を用いることにした。 Module::Install を用いて Makefile.PL を作成すると、
などの機能が使えるようになる。
Module::Install の実行に必要なファイルはパッケージの inc ディレクトリ以下に自動的にコピーされ配布パッケージに含められるので、インストールする側はそのために余分なインストールを強いられることもない。
最終的に内部で ExtUtils::MakeMaker を使っているので、それの機能はほぼ全て使える。
Perl のバージョンも 5.004 から使えるとのことで、Perl 5.005_03 以上を対象としている WiKicker で使っても問題なし。
ということで、Makefile.PL をさらっと書き換え。
合わせて WiKicker に含まれていた実験的な機能を削除して、(オプションな)依存モジュールも減らすことにした。
次回のリリース版から、Module::Install ベースだ。
WiKicker をオフラインで簡単にインストールできるようにしたい。 WiKicker 自体は
perl Makefile.PL make make test make install
で簡単にインストールできるのだが、事前に CPAN にある依存 Perl モジュール(とそれらが依存している Perl モジュールら)をインストールしておかなければならない。
オンライン環境では CPAN.pm を使って芋蔓式にインストールできる。 WiKicker は次回のリリースから Module::Install を採用するので、perl Makefile.PL 時にそれらを行うことができるようにもなる。
しかしオフライン環境になると、話は変わってくる。
普通にやろうとするとあらかじめ依存関係を全部洗い出して事前にダウンロードしておき、依存関係の順番を考えながらインストールしていかなければならない。
これがかなり面倒。しかも各モジュールのバージョンアップにともない、その時その 時で変化する可能性があるので、適宜確認しなければならない。
でれば CPAN.pm の力を借りたい。
CPAN.pm はインストール時に $CPAN::Config->{keep_source_where} (通常 ~/.cpan/sources) に溜め込むので、これを CD-ROM 等に書き込んでオフラインインストールで使用することができる (cf. perldoc CPAN)。
だいたいはこれでうまくいくのだが問題もあって、この方法だと(WiKicker などの)野良パッケージを、うまく一緒にすることができない。
野良パッケージを扱うには CPAN::Site、あるいは CPAN::Mini::Inject あたりを使えば良さそうだ。
今回はまず、CPAN::Site での手順を調べてみる。
~/perl-5.8.8 以下にクリーンな Perl 5.8.8 をインストールしてインストールセットを作成していく。
rm -rf ~/.cpan ~/perl-5.8.8/bin/perl -MCPAN -e shell cpan> install LWP cpan> install CPAN::Site cpan> exit
これで CPAN::Site が使えるようになるとともに、CPAN::Site と LWP および依存モジュールのソースアーカイブが ~/.cpan/sources 以下にたまる。
WiKicker のインストール中に libwww-perl を途中で入れると CPAN.pm が使ってこともあってかうまくいかないので、先に一緒に入れてしまう。
野良パッケージら (今回は WiKicker のみ)を含んだ ローカル pseudo CPAN サーバを作成する。
mkdir -p ~/public_html/CPAN/authors/id/N/NA/NANEY cp WiKicker-0.xx.tar.gz ~/public_html/CPAN/authors/id/N/NA/NANEY ~/perl-5.8.8/bin/mkpackages ~/public_html/CPAN
CPAN::Site に含まれている mkpackages を使うことで、CPAN::Site が参照することのできるインデックスファイルが作成される。
次に ローカル CPAN サーバと、CPAN (ミラー) からパッケージを自動ダウンロードしてインストールする。ここでは CPAN.pm のかわりに CPAN::Site を使用する。
~/perl-5.8.8/bin/perl -MCPAN::Site -e shell cpan> o conf urllist unshift http://localhost/~myname/CPAN cpan> reload index cpan> install WiKicker cpan> exit
ここでローカル CPAN サーバを file:/// 等で指定すると、そこから読みとったファイルは ~/.cpan/sources/ 以下にコピーされないので一箇所にまとめることができないので注意 (かなりはまった)。
これが終わると、WiKicker とそれに必要なファイルが ~/.cpan/sources にたまる。
これを適宜アーカイブして保存する。
別の環境で例えば /usr/local/perl-5.8.8 にインストールされた Perl に WiKicker をオフラインでインストールするとする。
先の工程で作成したファイルセットが /tmp/CPAN においてあるものとする。
/usr/local/perl-5.8.8/bin/perl -MCPAN -e shell # 初期化でオフラインのため CPAN ミラーの選択ができずに URL の入力を # 求められたところで file:///tmp/CPAN を指定 cpan> install LWP cpan> install CPAN::Site cpan> exit
まずは以上で CPAN::Site が入るで、CPAN::Site で shell を起動しなおす。
/usr/local/perl-5.8.8/bin/perl -MCPAN::Site -e shell cpan> install WiKicker cpan> exit
これで /tmp/CPAN から芋蔓式に WiKicker がインストールされる。
Debian のパッケージリポジトリなどとは違って、CPAN は基本的に「一つのリポジトリおよびそのミラー」という概念しかないようである。 したがってモジュールのインデックスファイルも1組しかなく、複数のサイトから異なるモジュールセットを配布するということができるようになっていない。
これに対し、自前パッケージ群用にも1セットインデックスファイルを作って扱えるようにしようというのが CPAN::Site である。
これを用いると「もう一つのリポジトリ」を扱えるようになるが、逆にいうと利用する場合は CPAN::Site をインストールしなければならないということでもある。
2005年10月6日以来、約2カ月ぶりのリリース。
Makefile.PL を Module::Install ベースにして、依存 Perl モジュールのインストールを楽にした。 Wiki 機能の方は大きな変更なし。DiKicker には はてなブックマーク上の検索結果を表示する機能を追加。
また今回は、実験的な実装でほとんど使われていないと思われるモジュールについて、メンテナンスの問題から削除を行った。 大きなところでは、GnuPG による電子署名によりアップロード利用者をチェックする画像アップロードページ/機能を削除。
利用している方がいれば削除した機能は復活させようと思うが、多分いないかなと。
アップロード機能は、今後のユーザ管理機能の追加時にあらためて追加する予定。
ゴールデンウィークに突入。 9連休を利用して、一気に WiKicker コーディングを企んでいる。
さっそくちょこちょこ修正してパッケージングし、www.naney.org へインストール。 …… Perl Makefile.PL でコケる。
どうも use inc::Module::Install; でエラーを起してしまっているようだ。 Makefile.PL は変更していないので、そうすると Module::Install の問題っぽい。
tarball をパッケージングするホスト側の Module::Install を 0.57 まで落としたところ、Perl 5.005_03 でも通るようになった。
Module::Install is a package for writing installers for CPAN (or CPAN-like) distributions that are clean, simple, minimalist, act in a strictly correct manner with both the ExtUtils::MakeMaker and Module::Build build systems, and will run on any Perl installation version 5.004 or newer. (Module::Install 0.61 より)
とあるように古い Perl もサポートにも気を払っているのが気にいって ExtUtils::MakeMaker から移行しただけにちょっと残念。
今後また 5.005_03 でも動くようになるのか、それとも捨てられるのか要チェック。
WiKicker をベースとしたシステム用の認証・承認データベース開発であるが、結局 DBIx::Class をいじる時間がないので、素の DBI + DBD::SQLite でいくことにした。 SQL でゴリゴリ書くことになるけど、こっちの方が DBIx::Class の挙動を調べながら書くより(まずは)早く完成できるので。
WiKicker の Makefile.PL で指定している依存モジュール指定からも DBIx::Class および関連モジュールを削除。
naney.org メールサーバの移転に次いで、Web サーバの移転作業。
現行 Web サーバと Unison でファイル同期している Web コンテンツを、さくらのレンタルサーバへ Unison でファイル同期。
nDiki 用に DiKicker (WiKicker) を make install。
%bash $perl -MCPAN -e mkmyconfig $perl -MCPAN -e shell o conf makepl_arg PREFIX=/home/naney/local/WiKicker o conf mbuildpl_arg --install_base=/home/naney/local/WiKicker o conf commit notest install CGI::SpeedyCGI $tar zxvf WiKicker-0.420.tar.gz $cd WiKicker-0.420 $export PERL5LIB=$HOME/local/WiKicker/lib/perl5/site_perl/5.8.9 $perl Makefile.PL PREFIX=$HOME/local/WiKicker $make $make install
以前きっちり Module::Install で Makefile.PL を作っておいたおかげで、比較的スムーズにインストールできた(自画自賛)。
ちょっとはまったところは CGI::SpeedyCGI の make test を実行する(される)と SSH 接続がサーバ側から切られてしまうという現象にあったところ。 テスト用に大量にスクリプトが起動されるの検出して自動的に kick されたのだろうか。
さくらのレンタルサーバでは .htaccess Options が使えないようなので削除。 ExecCGI や MultiViews が有効になっているようなので問題なし。
Perl 5.005_03 用に書いてあったスクリプトについて、Perl 5.8.9 で文字化けしないように utf8 まわりを修正。
1時間毎に実行したい処理を列挙するシェルスクリプトを1つ作って、コントロールパネルから1時間毎に実行するように設定。
現行サーバでは任意の crontab を設定できたので、1時間毎はちょっと物足りない。 おいおい負荷にならない範囲で、外部から定期的に HTTP アクセスして処理を定期的に実行できるようにもするかな。
まだ動いていないスクリプトもあるけれど(大きいところだと NaneyOrgWiki (Wiki))現行サーバの解約日もせまっているので、サーバ移転させてしまうことに。
VALUE-DOMAIN で DNS サーバ設定を変更し www.naney.org でさくらのレンタルサーバにアクセスできるように A レコードを変更。
今のところ特に重い等もなく順調。 現行サーバでは深夜非常に重くなる時間帯があったのだが、それが無くなるのが嬉しい。 また容量が100MB*1から10GB*2になったので心理的にセーブしなくて良くなった。
年内に移行できて良かった良かった。
[ さくらのレンタルサーバ プレミアム ]
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。