nDiki : ソースパッケージ

2005年1月8日 (土)

■ NSIS が再び Linux でコンパイルできるように

スポンサードリンク

2.01 で POSIX プラットフォームで動くようになった NSIS であるが、2.02、2.03 は Linux上ではソースパッケージからのビルドでエラーになってしまっていた。

1月5日に 2.04 がリリースされたので、こちらも試してみる。お、ビルドできた。

 tar jxvf nsis204.tar.bz2
 cd NSIS/Source
 make USE_PRECOMPILED_EXEHEADS=1
 cd ..
 su
 ./install.sh /usr/local/NSIS-2.04

インストール時に Menu ディレクトリが無くてエラーメッセージが出るのは前回と一緒。CVS リポジトリをみるとHTMLで書かれたドキュメントがあるだけのようなので、無くても問題なさそうである。付属の install.sh も改行コードが CRLF から LF に修正されているためそのまま実行できるようになった。

[ Linux 上で NSIS ]

twitter.com/Naney の follower になってください。

[ permalink ]

Linux 上で Windows 用インストーラを作成する (2004-10-14)
NSIS 2.22 は Linux でビルドできず (2006-12-20)
sid の CinePaint がプラグイン読み込みでエラー (2006-04-15)
ActivePerl で Ming (2005-02-23)
SCons は GNU Autotools のかわりになるか (2005-04-20)

[ 1月8日全て ]

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

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

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

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

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

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

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

MinGW-3.1.0-1.exe -> インストーラ形式
MSYS-1.0.10.exe -> インストーラ形式
msysDTK-1.0.1.exe -> インストーラ形式

@ bison は GnuWin32 で

Ming のビルドに必要な Bison は MinGW、MSYS のインストーラに含まれていない。 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::FakeConfig と PPM::Make で Ming の SWF PPM パッケージを作成する。 (MSYSのシェルではなく)コマンドプロンプトを開いて、Mingソースパッケージの中の perl_ext に移動。 MSYS、MinGW、nmake に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ファイルが作れる事を確認。やった。

[ permalink ]

ActivePerl をやめて Strawberry Perl へ (2009-08-25)
ActivePerl 5.8.9 build 825 + MinGW 5.... (2009-02-22)
Module::Build でソースパッケージング (2005-08-24)
PAR::Repository でビルド済み Perl モジュールをネット... (2006-12-12)
Windows 用 GNU tar (2004-08-05)

[ 2月23日全て ]

2005年4月20日 (水)

■ SCons は GNU Autotools のかわりになるか

NSIS のサイトによるとビルドに「SCons」を使うようしたらしい。

クロスプラットフォーム
Autoconf、Automake と同様の機能を統合
LaTeX もビルトインサポート

と興味深いツールになっているようだ。

現在プロジェクトLaTeXベースのドキュメント生成には GNU Make を使っているのだが、UNIX、Windows の両方でビルドできるようにするには ComSpec 環境変数の有無で使用するコマンドを切り換えたり等いろいろ面倒なので、代替ツールとして使えないかなと。

基本的な機能は Make に対する改良がなされているようであるし、コピー等ファイル操作も SCons 自体がもっているのでクロスプラットフォームでビルドできるようにするのも楽そうだ。

一方 Autoconf 系の機能については、インストール済みのライブラリの検出や実装レベルのチェック等を実装しているようである。 make check や make dist、make install 等にあたるターゲットに関する機能(あるいは規約)のようなものは無い。これは非常に残念。結局自分が Ant を使わなくなったのも GNU Autotools にあるこれらの機能に欠けているからであるし。

実は私がPerl が好きな理由の一つとして、これらサポートが充実しているという点がある。Perl では ExtUtils::MakeMaker (あるいは Module::Build)があり、ビルドからテスト、ソースパッケージのパッケージングまでフレームワークが整っている。

SCons は Python ベースで、Makefile にあたるファイルも Python スクリプトである。 SCons が影響を受けた Cons は Perl ベースであったのだが、既に2001年5月ごろから開発が止まってしまっている。残念。

ということで Make の代替には使えそうであるが、GNU Autotools と同じようなことをするにはいろいろ手をかけないといけないといった印象。

[ permalink ]

Module::Build でソースパッケージング (2005-08-24)
Windows 向けソフトウェア開発者はソースパッケージを作る習慣がない (2007-07-31)
私的10大ニュース2004 [ comp ] (2004-12-31)
ActivePerl で Ming (2005-02-23)
NSIS 2.22 は Linux でビルドできず (2006-12-20)

[ 4月20日全て ]

2005年8月24日 (水)

■ 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

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

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

[ permalink ]

SCons は GNU Autotools のかわりになるか (2005-04-20)
ActivePerl で Ming (2005-02-23)
nmake で毎回 pl2bat されるのを何とかしたい (2004-11-25)
私的10大ニュース2004 [ comp ] (2004-12-31)
WiKicker の Makefile.PL を Module::Inst... (2006-02-10)

[ 8月24日全て ]

2006年2月12日 (日)

■ 野良パッケージと依存 Perl モジュールのインストールセットを CPAN::Mini::Inject で

前回は CPAN::Site を用いたオフライン用インストールセットを作成した。

今回は空の CPAN のミラーを作り、そこに野良パッケージを突っ込んで使用する形でインストールセットを作成してみる。

~/perl-5.8.8 以下にクリーンな Perl v5.8.8 をインストールしてインストールセットを作成していく。

@ CPAN::Mini::Inject をインストールする (オンライン)

 perl -MCPAN -e shell
 cpan> install CPAN::Mini::Inject
 cpan> exit

CPAN::Mini::Inject は、インストールセットには必要ない。 ~/perl-5.8.8 にはインストールせずに、普段使っているほうにインストールしておく。

@ インストールしたい野良パッケージ用のローカル CPAN サーバを作成する (オンライン)

以下スクリプト例(エラー処理などは省略)

 #!/usr/bin/perl -w
 use strict;
 use File::Path;
 use CPAN::Mini;
 use CPAN::Mini::Inject;
 my $remote     = 'ftp://ftp.dti.ad.jp/pub/lang/CPAN/';
 my $local      = '/home/myname/public_html/CPAN';
 my $repository = '/home/myname/repository';
 mkpath([$local, $repository], 1, 0755);
 # module_filters で全てのモジュールを対象外にして、空の CPAN ミラーを作る
 CPAN::Mini->update_mirror(remote => $remote,
                           local  => $local,
                           diremode => 0755,
                           trace => 1,
                           module_filters => [ qr/./ ]);
 my $injector = CPAN::Mini::Inject->new;
 $injector->{config}{remote} = $remote;
 $injector->{config}{local} = $local;
 $injector->{config}{repository} = $repository;
 $injector->{config}{diremode} = 0755;
 # CPAN::Mini::Inject リポジトリに追加したあと、
 # CPAN ミラーへ 注入
 $injector->add(repository => $repository,
               module => 'WiKicker',
               authorid => 'NANEY',
               version => '0.xx',
               file => 'WiKicker-0.xx.tar.gz')
  ->inject;

これで、~/public_html/CPAN に野良パッケージの追加された CPAN ミラーが作成される。

@ WiKicker と依存するモジュールをインストールする (オンライン)

 rm -rf ~/.cpan
 ~/perl-5.8.8/bin/perl -MCPAN -e shell
 cpan> o conf urllist pop
 cpan> o conf urllist push http://http://localhost/CPAN
 cpan> reload index
 cpan> o conf urllist push ftp://ftp.dti.ad.jp/pub/lang/CPAN/
 cpan> install WiKicker
 cpan> exit

ここでローカル CPAN サーバを file:/// 等で指定すると、そこから読みとったファイルは ~/.cpan/sources/ 以下にコピーされないので一箇所にまとめることができないので注意。

またCPAN ではモジュールインデックスファイルは1組しか持てないようで、初期設定のままだと野良パッケージを含む CPAN ミラーのインデックスファイルが使われない。そのため一旦 urllist を空にした後、自分の CPAN ミラーを指定しインデックスファイルをロードする。その後にソースパッケージを取得するセカンダリとして通常の CPAN (ミラー)を指定するようにしている。

これが終わると、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 WiKicker
 cpan> exit

これで /tmp/CPAN から芋蔓式に WiKicker がインストールされる。

@ ポイント

CPAN::Site を利用して構築した場合は、インストール時にも CPAN::Site が必要だが、こちらはインストールセットの利用には CPAN.pm だけで良いというのが利点。

今回は CPAN::Mini で空の CPAN ミラーを作成し野良パッケージを追加した。

ここで最初から CPAN の最新パッケージの全ミラーを CPAN::Mini で作成し、これに野良パッケージを追加してインストールセットを作ってしまうという方法もある。この場合は後で必要に応じてミラーからパッケージを入れられるというメリットがあるかわりに、ミラー作成のコストがかかるというデメリットがある。

[ permalink ]

野良パッケージと依存 Perl モジュールのインストールセットをCPAN... (2006-02-11)
WiKicker の Makefile.PL を Module::Inst... (2006-02-10)
SVN::Webインストール失敗 (2006-02-17)
WiKicker に JSON でのページ出力機能を追加 (2007-04-03)
CPAN のPerl モジュールを RPM パッケージ化する (2003-04-22)

[ 2月12日全て ]

2006年4月15日 (土)

■ sid の CinePaint がプラグイン読み込みでエラー

10枚の「ゴッサム・シティ東京」を見て HDR イメージに興味を持った。

で早速日中に、手持ちのデジカメで段階露出をした写真を取りためて、家に帰って HDRI 作成に入る。 Linux だと CinePaint あたりが王道か。 CinePaint 0.21 には

"Bracketing to HDR" Plugin for CinePaint (Version 0.4.1)

が最初から入っており、段階露出で撮影したデジタル画像から HDR イメージを作成できるのである。

が。

Debian GNU/Linux sid で cinepaint 0.21-1 をインストールして起動してみると、

 /usr/lib/cinepaint/0.20-1/plug-ins/bracketing_to_hdr: symbol lookup error: /usr/lib/libcinepaint.so.0: undefined symbol: gtk_marshal_NONE__NONE
 wire_read: unexpected EOF (plug-in crashed?)

と出てしまうではないが。CinePaint 自体は起動するのだが、プラグインが読みこみ失敗してしまっているようだ。全てのプラグインの読み込みに失敗している様子である。

環境依存かと思いソースパッケージからビルドし直してみてもやっぱり同様。

そんな。

[ permalink ]

CinePaint で HDR イメージを作れるようになった (2006-04-16)
flickrfs で Flickr をマウントして写真をコピーする (2008-02-21)
今日のさえずり - ピカチュウと写真撮ってもらえる列に並んでる (2009-11-24)
Dropbox for Linux を Debian 用にビルドしてインストール (2009-11-24)
TrueCrypt 6.1a を Debian GNU/Linux sid に (2009-02-02)

[ 4月15日全て ]

2006年12月20日 (水)

■ NSIS 2.22 は Linux でビルドできず

Windows 用のインストーラ作成ツール NSIS は、スクリプトベースでインストーラを作っていくのが1つの特徴である。 NSIS スクリプトは、さすがインスーラ作成用だけあって

ファイル処理 (コピー、削除、……)
レジストリの読み書き
プログラムの実行

その他システム関連のコマンドが充実している。コンパイルするとかなりコンパクトな実行形式ファイル (EXE) を生成してくれるので、ちょっとした処理を自動化するには便利である。

今回 USB メモリに入れておいて、そのドライブ上のいくつかのディレクトリに PATH が通った状態でコマンドプロンプトを開くツールを NSIS で書いておこうかと思って試す。

NSIS は POSIX ベースシステムでビルドし実行でき、NSIS スクリプトをコンパイルできる。ということで作業を Linux で作業をしていたのだが、どうやら System::Call が使えないようだ(スクリプトのコンパイルに失敗する)。

Debian パッケージが古いせい (2.19-1.1) かと思い、ソースパッケージをビルドしてみたらまさに System 関連らしいところでコンパイルがこけている (そういう背景で Debian パッケージがアップデートされていない?)。

ということでどうも最新の NSIS は Linux では駄目っぽい。

しょうがないので久しぶりに Wine。

Wine 上に NSIS 2.22 をインストールして makensis.exe を実行してみたところ試した範囲ではうまく動いている。ついでにでき上がった実行可能ファイルも Wine 上で試せる。

しばらくは Wine 上で NSIS スクリプト書きを楽しむことにしよう (最終的には Windows 上でコンパイルしなおして動作確認するのだけれども)。

[ permalink ]

TrueCrypt で USB メモリに Windows と Linux ... (2006-12-14)
xyzzyを読み取り専用メディアから起動する (2004-07-28)
Linux 上で Windows 用インストーラを作成する (2004-10-14)
PAR::Repository でビルド済み Perl モジュールをネット... (2006-12-12)
NSIS が再び Linux でコンパイルできるように (2005-01-08)

[ 12月20日全て ]

2007年7月31日 (火)

■ Windows 向けソフトウェア開発者はソースパッケージを作る習慣がない

GNU Autotools や ExtUtils::MakeMaker (とその仲間たち)で make dist するのがあたり前になっている自分には、気持ち悪い。

ビルドの自動化とソースパッケージ作成の自動化・バージョン管理のセットアップは、最初の仕事だと思うのだが。

[ permalink ]

SCons は GNU Autotools のかわりになるか (2005-04-20)
Module::Build でソースパッケージング (2005-08-24)
ActivePerl で Ming (2005-02-23)
NSIS 2.22 は Linux でビルドできず (2006-12-20)
nmake で毎回 pl2bat されるのを何とかしたい (2004-11-25)

[ 7月31日全て ]

2008年7月19日 (土)

■ 今日のさえずり - NOMO って書くと消しゴムっぽい

@ 2008年07月18日

09:20 お年玉切手シート2枚郵便局でもらってきた。交換期間もうすぐ終了。[mb]
12:22 帰省往路の新幹線、希望の車両で指定席確保。[mb]
12:24 NOMO って書くと消しゴムっぽい。[mb]
15:53 sid アップデートしたら ** WARNING ** Failed to load ToUnicode mapping: EUC-UCS2 が出て hyperref のしおりが文字化けするようになった。
20:02 掃除機かけたらこの時間になった。帰る。[mb]

@ 2008年07月19日

11:54 デックス東京ビーチ、モンベルなくなってたか。[mb]
14:08 トイザらスで散財。[mb]
15:00 ギリシャ風のカフェ、CRUX Kafeo でアイスコーヒー。空いていて穴場。[mb]
23:25 そういえば昨日はしおり問題、dvipdfmx を 1:20080607-1 から 1:20071115-1 に戻してしのいだ。新しいやつのソースパッケージをのぞいたが EUC-UCS2 が見つからなかった。