accomplish nothing

Bloggerのテンプレートを本格的に編集し始めたものの、テンプレートのマークアップが実にデザイン偏重で、正直どうかと思った。foo-wapperといった風に名付けられた大量のdiv要素とかを見ていると、これを書いた人間を小一時間問い詰めたくなる。サランラップ系のCMに出てくるような、何でもラップしとけばオーケーみたいなタイプに違いない。

こういうのは、構造とデザインを分けた方が、無駄なタグを書かなくて良い分だけ楽だろうに。

Nevada b83aでpkgsrcのgmakeをビルドするとき、GMAKE_LOCALE=noを指定しないと、gettextやgcc経由で回り回ってgmakeに戻ってきて、循環参照のエラーと共に失敗する。笑えない。

# GMAKE_LOCALE=no; export GMAKE_LOCALE
# bmake
# bmake install

Nevadaでのソフトウェアの管理の手間を省くために、NetBSDで主に利用されているパッケージシステムのpkgsrcを、Nevada b83a（以下b83a）に導入する。流れとしては次のようになる。

1. 一番新しいpkgsrcのアーカイブをダウンロードする
2. pkgsrcのアーカイブを展開する
3. pkgsrcを最新の状態に更新する
4. bootstrapスクリプトを実行する
5. mk.confでpkgsrcの設定をする

以下詳細。まず、一番新しいpkgsrcのアーカイブを、NetBSDのFTPサーバからダウンロードする。gzipとbzip2の二種類あるが、b83aにはGNU tarもbzip2も標準で付いてくるので、どちらを選んでも構わない。

# cd /tmp
# curl ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.bz2 > pkgsrc.tar.bz2
# md5sum pkgsrc.tar.bz2
# curl ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.bz2.MD5

チェックサムの一致を確認したら、アーカイブを展開する。NetBSDでは、pkgsrcを/usr/pkgsrcに置くが、Solarisではユーザアプリケーションを/optにインストールする慣習があるようなので、/opt/pkgsrc/pkgsrcに展開する。/opt/pkgsrcにはpkgsrcで管理するソフトウェアをインストールし、/opt/pkgsrc/pkgsrcにはpkgsrc自体を置く。

# mkdir /opt/pkgsrc; cd /opt/pkgsrc
# bzcat /tmp/pkgsrc.tar.bz2 | tar xof -

次にpkgsrcの更新。ダウンロードしてきたアーカイブも、最新と言ってほぼ差し支えないが、pkgsrcは常に更新され続けているため、アーカイブと最新のバージョンの間には差がある場合が多い。できるだけ新しい方が都合が良いので、CVSでpkgsrcを更新する。b83aにCVSは収録されていないので、Solaris Operating System - Freewareからパッケージ化されたCVSをダウンロードし、インストールする。

# bzip2 -d SFWcvs.pkg.bz2
# pkgadd -d SFWcvs.pkg

CVSのインストールが済んだら、CVSでpkgsrcを更新する。

# CVSROOT=anoncvs@anoncvs.NetBSD.org:/cvsroot; export CVSROOT
# CVS_RSH=ssh; export CVS_RSH
# cd /etc/pkgsrc/pkgsrc; cvs update -dP

bootstrapスクリプトを実行し、pkgsrcに必要なツールをコンパイルする。gccは/usr/sfw/binにあるので、パスを通しておく。

# PATH=$PATH:/usr/sfw/bin
# cd bootstrap
# ./bootstrap --prefix=/opt/pkgsrc --sysconfdir=/opt/pkgsrc/etc --pkgdbdir=/var/opt/pkgsrc/db/pkg --varbase=/var/opt/pkgsrc

あとは、libtoolで/bin/kshがクラッシュする問題を避けるために、mk.confを編集して終わり。

CONFIG_SHELL=   /usr/bin/bash
WRAPPER_SHELL=  /usr/bin/bash

MinGWでBiglooをコンパイルする際の手順。

1. アーカイブをMinGWのtarで展開する
2. tarがシンボリックリンクの処理に失敗したファイルを手動で処理する
3. configure
4. make
5. make test
6. make install
7. make compile-bee
8. make install-bee

まず、BiglooのアーカイブをMinGWのtarで展開。ここで、WindowsのアーカイバやCygwinのtarを使ってはいけない。理由は、Cygwin環境へのBiglooのインストールにおける注意点でも触れているけど、アーカイブ内のシンボリックリンク。Windowsのアーカイバで展開すると、シンボリックリンクはまず処理されない。Cygwinで展開すると、シンボリックリンクをWindowsのショートカットで代用するけど、シンボリックリンクの処理に別のアプローチを取っているMinGWでは、ショートカットをシンボリックリンクと認識しない。

次に、MinGWのtarがシンボリックリンクの処理に失敗したファイルを、手動で処理する。MinGWのシンボリックリンクの処理は非常に明快で、リンクする対象をコピーするだけという、富豪的なアプローチを取っている。同期に関してだけは使う側が注意する必要があるものの、MinGWの目的を考えると現実的な落とし所だと思う。しかし、今回はこれが仇となっている。アーカイブの中で、リンクする対象よりもシンボリックリンクが前に格納されている場合、コピーしようにも元のファイルがまだ無いので、エラーになってしまう。Bigloo 3.0c-4の時点では、

• bde/jas/as.scm
• bde/jas/classfile.scm
• bde/jas/lib.scm
• bde/jas/peep.scm
• bde/jas/produce.scm
• bde/jas/profile.scm
• bde/jas/stack.scm
• bde/jas/wide.scm

がエラーになるので、comptime/Jas/以下の各ファイルに対して、

$ cd bde/jas
$ ln -s ../../comptime/Jas/as.scm .

といった感じにMinGWのlnでシンボリックリンクの処理をしてやれば大丈夫。

configureについて。標準だと/usr/local以下へのインストールが想定されているので、これを変更する。Cygwinと違って、MinGWでコンパイルされたバイナリは、マイクロソフトのCランタイムライブラリをそのまま使っていて、特殊なパス表記を解釈できるようなエミュレーションレイヤが無い。/usr/localや、MinGW特有の/c/Bigloo、Cygwin特有の/cygdrive/c/Biglooといった表記は全て解釈されないので注意する。C:/Biglooとかなら大丈夫。INSTALLにMinGW向けの情報が載っているので参考にすること。また、BEEという開発環境が付属しているので、インストールするなら、Emacsのパスも同時に指定する。

$ ./configure --prefix=C:/Bigloo --emacs=C:/Emacs/22.1/bin/emacs.exe

といった風に指定すれば良い。

あとは、特に問題無くコンパイルできるはず。GCC 3.Xを使う場合は--cflags=-fno-reorder-blocksを指定するのを忘れない、CygwinではなくMSYSを使う、Cygwinのツールを混ぜない、といった基本的なことを守れば普通に成功する。

追加で注意事項。Biglooではスレッドがサポートされているけど、MinGWでコンパイルする場合、3.0c-4時点では強制的にスレッドサポートが無効にされる。これは、Biglooが採用しているBohem GCが、MinGWでコンパイルしたとき、マルチスレッド下できちんと動作しないからで、一時的なことだと、Biglooの作者のManuel SerranoさんがChangeLogに書いてる。スレッドを使いたい場合、user-levelの物を使うか、BiglooをCygwinでコンパイルすること。

Emacsは、ひとつのフォントセットとして定義することで、M+と他のフォントとの混植が簡単にできる。まだ漢字部分は作りかけのM+だけど、他のフォントと組み合わせれば、現時点でも十分実用になる。

フォントセットの定義については、余所でも色々解説されているから省略。ここで本題。TESTFLIGHT 014時点では、M+ FONTSで配布されているフォントファイルには、NTEmacsで使う上で問題がある。

問題点はふたつ。

• フォントファミリ名に+が入っているので、文字を表示するフォントとしてM+を使えない
• OS/2テーブルのulCodePageRangeにLatin 1が含まれないので、Latin 1の範囲ではM+を使えない

解決策としては、フォントファイルを書き換えるのが手っ取り早い。ttfname3を使って編集すると、バイナリエディタなどを使って編集するよりは楽が出来る。使い方はマニュアル参照。TrueTypeはビッグエンディアンなので、Codepage1を編集するときに注意する。

以下詳細。まずファミリ名について。MicrosoftのTrueTypeの規格を流し読みした限りでは、OS/2とWindowsではUnicodeで記述しろ、とは書いてあるけど、記号類に関する制限とかは書いてない。メモ帳などでも普通に使えるので、恐らくNTEmacsが原因。

次にOS/2テーブルのulCodePageRange。これは、フォントに含まれるコードページを指定しているんだけど、M+ではこれにLatin 1が含まれていないため、Latin 1の範囲で使えない。Latin 1が含まれることをプログラムに伝えるために、最下位ビットを立てると、NTEmacsでもLatin 1部分をM+で表示できるようになる。……多分こういう仕組み。こちらはまるで自信なし。