Namazu-devel-ja(旧)

[Motoyuki Kasahara <m-kasahr@xxxxxxxxx>]

笠原です。
ここ数日メール読む環境がボロボロでしたが、なんとか復帰しました。

* From: Ryuji Abe <raeva@xxxxxxxxxxxx>
* Date: Sat, 31 Mar 2001 22:34:50 +0900

> 3月29日付でGNU gettext 0.10.36がリリースされたよう
> です。

おぉ、ということで取って来たのですが、まだコンパイルしてません。
(うう、以前のスナップショット版も、紹介しといて手を付けてません。
ごめんなさい _o_)

iconv を使ってメッセージカタログのエンコーディングは変換してくれ
る、という機能自体は至極当然というか、望まれていた機能だと思うの
ですが、ちょっと眺めた限りでは autoconf まわりの対応は大丈夫なの
か不安になりました。

libintl が iconv に依存するようになったわけですが、autoconf まわ
りはこれで大丈夫なのか。m4 を軽く眺めただけですが、ずいぶんあっ
さりしていて、本当にこれで全てのケースを想定しているのでしょうか。

考えられるケースは、「libintl の有無」×「libiconv の有無」で 4
通りあります。

	1. libintl も libiconv も必要なし
	   (どっちも libc に入ってる。Linux など)
	2. libintl だけ必要
	   (旧 gettext を使った場合)
	3. libiconv だけ必要
	   (Solaris で GNU gettext を使う場合など)
	4. libintl, libiconv 両方必要
	   (どっちも libc に入ってない。FreeBSD など)

それに、gettext を使用するソフトウェア libintl のソースコードを
一緒に配布するというのを前提にしていますよね。gettext にも 
gettextize というツールが付いていますし、automake の AM_GNU_GETTEXT
も intl サブディレクトリの有無とかをチェックするようになってます。

けれども、0.10.36 では「gettext を使うソフトウェアは libiconv の
ソースも付けるべし」という方針にはなっていないようなんですど、合っ
てますか。他のソフトウェアは libintl のソースだけ含めるようにし
ても、libiconv がないと上記の 4. のケースだと単独ではコンパイル
できないわけで、あんまり意味ないです。

個人的には、libiconv, libintl を両方とも配らないようにするか、両
方とも配るようにするしか、どちらかにするしか無くて、片方だけとい
うのは中途半端で意味が無いのではないかなぁ、と思ってます。

# ここで言うより、gettext の ML で言え、という話もありますが。(^^;)
________________________________________________________________
                                    笠原 基之(かさはら もとゆき)