nDiki : PPM パッケージ

2004年8月27日 (金)

Wx::ActiveXビルド

Wx::ActiveXPerl 5.6.1 用バイナリ(PPM パッケージ)が配布されていないのでビルドする。 最初はPPM パッケージ化された wxPerl (Wx-0.19-wxmsw2.4.2-win32-u-5.6.1.zip) と wxWidgets 2.4.2 で作成しようと思ったが、うまくいかないので全部ビルドすることに。

wxWidgetsインストール

wxMSW-2.4.2-setup.zip を C:\usr\local\wxWindows-2.4.2 へ。

wxPerl 0.20

ドキュメントの通り、wxWidgetsビルド後、モジュールを作成。 コンパイルには Visual C++ 6 を使用。

wxWidgetsビルド

 set WXWIN=C:\usr\local\wxWindows-2.4.2
 set WXDIR=C:\usr\local\wxWindows-2.4.2
 cd %WXDIR%\src\msw
 nmake -f makefile.vc FINAL=1 dll
 cd %WXDIR%\contrib\src\stc
 nmake -f makefile.vc FINAL=1 WXUSINGDLL=1
 cd %WXDIR%\contrib\src\xrc
 nmake -f makefile.vc FINAL=1 WXUSINGDLL=1

Wx-0.20.tar.gz を展開したディレクトリに移動し(WXWIN, WXDIR は前記と同じように設定したまま)、

  perl Makefile.PL
  nmake
  nmake test
  make_ppm

PPM パッケージ化まで。

Wx::ActiveX 0.05

先に wxPerlインストールしておいてから、

 set WXWIN=C:\usr\local\wxWindows-2.4.2
 set WXDIR=C:\usr\local\wxWindows-2.4.2
  perl Makefile.PL
  nmake
  nmake test
  make_ppm

PPM パッケージ化。インストール

demo ディレクトリにあるサンプルで、IE、Flash Player、Acrobat、Windows Media Player を貼りつけられていることを確認。

スポンサード リンク
[ 8月27日全て ]

2004年9月22日 (水)

ActivePerl 5.6.1 -> 5.8.4

PDLの動作確認がとれたのでプロジェクトで使用するバージョンを v5.8.4 に上げることにする。 PPM パッケージ全部作りなおし。4時間ちょいかかった。

ついでに ithreads まわりもチェック。

[ 9月22日全て ]

2004年10月21日 (木)

bundle を作成して Perl モジュールをまとめてインストール

依存モジュールが多くなってきて、開発しているPerl モジュールの実行環境構築が面倒になってきた。

ActivePerl では PPM パッケージ化 + PPM リポジトリで芋蔓式インストールが可能である。 素のPerlだとCPANモジュールでネットワークインストールする事になる。 ここで一個づつインストールしていくのがかったるい。 ということでCPANにあるモジュールのように Bundle::* を作る事にした。

調べてみると簡単。

  • bundle はただのPerl モジュールである。
  • Bundle:: 名前空間に置く。
  • =head1 CONTENTS Podセクションを置き、各行に1つづつ依存モジュールを列挙する。

フォーマットは以下。

 Module_Name [Version_String] [- optional text]

これだけ。Pod に書かせるあたり、とりあえずから始まった感じである。

CPAN上に置あるものはきちんと tarball 化してあるが、ローカルで使う分にはこの bundle Perl モジュールを @INC のどこかに置いておけばよい。

Bundle::MyModule を作ったとすると perl -MCPAN -e shell から 'install Bundle::MyModule' でOK。

CPAN と @INC 上の '.'

カレントディレクトリの下に Bundle/MyModule.pm を置いて

 perl -I . -MCPAN -e shell

として Bundle::MyModule をインストールしようとしたのだがうまくいかない。CPANシェル上の ! コマンドで @INC を出力してみると . が含まれていない。何故? PERL5LIBに設定しても同様。 試行錯誤したところ絶対パスで指定すればOKであった。

CPAN.pm 1.76_01 を読んでみた。

 no lib "."; # we need to run chdir all over and we would get at wrong
             # libraries there

これだ。

[ 10月21日全て ]

2004年12月21日 (火)

ActivePerl 5.8.6.811

今月でていたようだ。 アップデート。Build 810 用に作ったPPM パッケージはバイナリ互換でいけそうな様子。

[ 12月21日全て ]

2005年2月23日 (水)

ActivePerlMing

ActivePerlMing を使えるようにしておきたい。

Visual Studio

Ming 0.3 beta1 のソースパッケージには Visual Studio 6.0 用のプロジェクトファイルが含まれている。 Cygwin の Bison と flex があればライブラリをビルドできるようだ。 横着して Linux 側で bison と flex で生成したファイルをコピーして(それから unistd.h をインクルードしている部分を消して)、ビルドしてみたところ一応 lib ファイルは作成成功。

しかし ActivePerl 用にPerl モジュールの make は失敗。

MinGW + nmakeActivePerl のモジュールをビルドできるらしい

調べたところ ExtUtils::FakeConfig を使うと Visual Studio が無くても MinGW + nmake でモジュールをビルドできるらしい(全てではないと思うが)。

ということで MingMinGWビルドした後、そのまま ActivePerl 用モジュールの作成まで持ち込むことにしてみる。

MinGW + MSYS + GnuWin32開発環境を構築

コンパイルに必要な環境を MinGW で、configure に必要な環境を MSYS で用意する。

bison は GnuWin32

Mingビルドに必要な Bison は MinGWMSYSインストーラに含まれていない。 bison-1.875.0-2003.02.10-1.exe というのが別途あるがうまく動かない。

ソースパッケージ(bison-2.0.tar.gz、bison-1.875.tar.gz)からはビルドできず。 MinGW/MSYSのプロジェクトにある bison-1.875-2003.02.10-1-src.tar.gz はビルドできるものの make check が通らない。

とうことで GnuWin32 の bison-1.875-4.exe (インストーラ形式)をインストール。 c:/usr/local/GnuWin32インストールした後、MSYS の /etc/fstab で /GnuWin32 にマウントし、/GnuWin32/bin に PATH を通しておく。

flexソースパッケージから

flex-2.5.4a.tar.gz を展開して

 ./configure; make; make check; make install

インストール時ハードリンクが作れなくてエラーがでているようだが無視。

zlib (Ming で必要)

MSYS 上でビルドしてインストール。zlib-1.2.2.tar.gz を展開して

 ./configure; make; make check; make install

LibUnGif for Windows (Ming で必要)

MSYS 上でビルドしてインストール。 libungif-4.1.0b1-src.zip を展開して

 rm config.cache;
 config.h内の-DHAVE_VARARGS_Hをコメントアウト。
 ./configure; make; make install

make check はエラーが出るが無視。

libpng (Ming で必要)

MSYS 上でビルドしてインストール。libpng-1.2.8-config.tar.gz を展開して

 CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure
 make; make check; make install

いよいよ Ming

MSYS 上でビルド。ming-0.3beta1.tar.gz を展開して

 CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib make static

ActivePerl 用モジュール作成

ExtUtils::FakeConfigPPM::MakeMingSWF PPM パッケージを作成する。 (MSYSシェルではなく)コマンド プロンプトを開いて、Mingソースパッケージの中の perl_ext に移動。 MSYSMinGWnmake にPATHを通しておく。

それから Makefile.PL の実行で -lz を発見できないので、libz.a を Makefile.PL と同じディレクトリにコピーしてしまう(-L/usr/local/lib を指定しても効かなかったので)。 libpng.a、libungif.a も同じくコピーしておく。

Makefile を作成。Makefile.PL では -lz しか指定していないが、libpng と libungif も必要なのでコマンドラインオプションで指定する。ExtUtils::FakeConfig の Config_m を使用して MinGW を使用するようにする。

 perl -MConfig_m Makefile.PL LIBS="-lpng -lungif -lz"

ここで生成される Makefile の中で libperl58.a を指定している部分があるが、ActivePerl では perl58.lib になるので、エディタで書き換え。 後はいつも通り

 nmake
 nmake test
 make_ppm

PPM パッケージ作成完了。

簡単なPerlプログラムでSWFファイルが作れる事を確認。 やった。

[ 2月23日全て ]

2005年3月31日 (木)

Wineを入れてみる

Linux 上で Win32 用の ActivePerl を動かして、PPM パッケージの作成や PAR による実行可能ファイルの作成をできるようにしたい。

調べたところ Wine 上でも ActivePerl が動くらしい。 さっそく Debian GNU/Linuxsid 環境にインストールしてみる。

debパッケージは以下をインストール

  • wine
  • wine-utils
  • winesetuptk
  • wine-doc
  • msttcorefonts

winesetup を実行して ~/.wine 以下を作成。 winesetup が古いのか wine を実行すると

Please use the registry key HKEY_CURRENT_CONFIG\Software\Fonts\LogPixels to set the screen resolution and remove the "Resolution" entry in the config file

という警告がでるので、[fonts] の中の

 "Resolution" = "96"

をコメントアウト。

次に msi 形式になっている ActivePerl インストーラを動かすために、Windows Installerインストールする。

失敗。設定がうまくいっていないのか、何かが足りないのか。

usr/share/wine/wineinstall で ~/.wine 以下を作っても駄目。

要調査。

[ 3月31日全て ]

2005年4月10日 (日)

Windows 上での Apache 2.0.53 では PATH_INFOシフト JIS

WiKickerWindows 上での動作確認の続き。 WiKickerPPM パッケージを作成して ActivePerl 5.8.6.811 上にインストール。 依存するモジュールで、ActivePerl に入っていないものは以下の通り。

既に手元で PPM パッケージ化済みなので、これもインストールしておく。

後は RCS をパスの通っているディレクトリに入れてタイムゾーンを設定。

 TZ=JST-9

CGI プログラムとして実行。 お、表示できた。 書き込みはと。

エラー

予想していたけれど、sendmail に依存していたところ。 sendmail が見つからない場合はメールの送信をスキップするように修正。

これでうまく動くかなと思ったら、日本語名のページを作るとうまく表示できない問題を発見。

PATH_INFOシフト JIS で渡される

WiKicker では UTF-8 文字列をURIエスケープして WikiPageURLを生成している。 このURIにアクセスされると WiKicker は、PATH_INFO から WikiName を取り出す。 この文字列がシフト JIS になってしまっている。

Windowsファイル名に使用する charset にあわせて、Apache が変換してしまっているようだ。 調べてみると他の WikiEngine でも同様の問題にあっているという記事が見つかった。

将来の 2.0 系でパッチが取り込まれて修正されるとか、そうでないとか。

現状どうするかなぁ。 WiKicker 側でシフト JIS から UTF-8 に戻すというのもできない事はないけれど、あまりやりたくはないな。 いったんシフト JIS を介しているという時点で、シフト JIS に無い文字の扱いに関する問題をかかえてしまっているし(Apache が)。

対策案:

  • Apache 1.x 系を使う (まだ未確認だが、こちらだと勝手に変換されないらしい)
  • WiKickerPATH_INFO を使わないオプションをつける(URI Query Component は勝手に変換されない)
  • WiKicker 側でシフト JIS から UTF-8 に変換する
[ 4月10日全て ]

2006年2月9日 (木)

ActivePerlPAR PPM パッケージは合わせる必要あり

以前 ActivePerlインストールした PARWindows 実行形式ファイルに変換しておいたプログラムが実は動かなかった事に気がつく。

プログラム名 - エントリポイントが見つかりません。

プロシージャ エントリ ポイント PL_memory_wrap がダイナミックリンク ライブラリ perl58.dll から見つかりませんでした。

おや。

どうやら ActivePerl 5.8.7 Build 813 上で、 ActivePerl 5.8.6 Build 811PPM パッケージ化しておいた PAR を使ったのがまずかったようだ。

ActivePerl は 5.8 系の間ではバイナリ互換だったと思うが(5.6系とは駄目)、PAR に限ってはそうはいかないらしい。まぁ、考えてみればそうなってもおかしくない。

ということで PAR PPM パッケージを作り直してインストールし、こちらであらためて exe ファイルを作成。 うまく動くようになったことを確認。

[ 2月9日全て ]

2006年7月3日 (月)

自前 PPM リポジトリの管理

Windows Perl アプリケーション用に PPM リポジトリを久しぶりに整理。

自分が使用する PPM パッケージは以下の理由から、以前より基本的に自前でビルド/保存し PPM リポジトリをローカルに作成するようにしている。

  1. 後でオフラインインストールできるようにする。
  2. 「公開リポジトリが無くなった」あるいは「公開リポジトリに欲しいパッケージが無くなった」時に困らないようにする。
  3. 動作確認された組み合わせでの PPM パッケージセットを作成・保持できるようにする。
  4. ライセンス的にクリアなものだけを含むリポジトリを用意する。 (芋蔓式インストールで、ライセンス的にクリアでないパッケージが入ってしまうのを防ぐ)。

手元では以下のように管理

 PPM
  |-- <category>
  |   `-- 8xx
  |       |-- <projects A> [ 公開 / export ]
  |       |   |-- module1.ppd -> (A)
  |       |   |-- module1.tar.gz -> (B)
  |       |   `-- ...
  |       `-- ...
  `-- pool
      |-- module1-x.yy
      |   |-- module1.x.yy.tar.gz
      |   |-- some documents...
      |   `-- build817
      |       |-- module1.ppd (A)
      |       `-- module1.tar.gz (B)
      `-- ...
pool
  • pool ディレクトリに「[モジュール]-[バージョン]」ディレクトリを作成する。同じバージョンでも、異なるバージョンは両方とも別々にキープしておく。
  • その下にソース tarball を置く。
  • ライセンス情報ファイルなども置く (touch Perl-License 等空のファイルを作成しておく)
  • PPM パッケージPPM::Make で作成し、その時に使用した ActivePerlビルド番号別にサブディレクトリを作って .tar.gz と .ppd を置く。
リポジトリ
  • ActivePerlビルド番号別にリポジトリを作成する。基本的には 6xx 系、8xx 系それぞれの中ではバイナリ互換性がある (PAR などは、ビルド番号に1対1でしか互換性がない)。
  • 必要に応じてカテゴリ別サブディレクトリを用意 (アクセス制限の都合などにより)
  • 必要に応じてプロジェクト毎にサブディレクトリを用意 (プロジェクト毎にパッケージセットを作るため)
  • リポジトリディレクトリからは pool 内の .ppd、.tar.gz へシンボリックリンクを張る。欲しいモジュールのバージョン、ビルド番号を選んでリンクする。
公開
  • SambaApache などで、PPM ディレクトリ全部あるいは特定のリポジトリ部分を公開する。
  • 必要なら export して別サーバに置く。rsync や cp の -L オプションでシンボリックリンクを実ファイルに置き換えてアーカイブを作成する。
[ 7月3日全て ]

2006年12月12日 (火)

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 ファイルを指定する従来の方式に比べてかなり便利そうである。 ということで試用してみた。

まずは

あたりをインストールし準備 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

*1ここでは Windows 上の

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 リポジトリで集中管理するというのもちょっと魅力的である。

[ 12月12日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.058581s / load averages: 0.53, 0.60, 0.60
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker