Namazu-devel-ja(旧)

[knok@xxxxxxxxxxxxx (NOKUBI Takatsugu)]

<200104060533.OAA28857@xxxxxxxxxxxxxxx>の記事において
raeva@xxxxxxxxxxxxさんは書きました。

>> > # 2M もあるなんて知りませんでした ^^;
>> 
>> ちなみにGNU recode 3.6も3.5の約2倍に膨れ上がって
>> います。:) CJK supportが入るとどうしても大きく
>> なってしまいますね。

  御意。i18n/m17n の宿命ですね。

>> >   Namazu において libiconv が使えると、今 nkf/lv に依存している部分も
>> > iconv で済ませられるようになるかな? と思ったりもしたのですが、そのメリ
>> ッ
>> > トと配布物の増加のデメリットを比べると、やっぱり同梱は辛いですかね... 
>> 
>> GLib 1.3みたいにiconv()がないか、もしくはぶっ壊れて
>> いる環境ではlibiconvを別途入手して、それを使ってね
>> というのではダメでしょうか?

  Glib は壊れているかどうかまで判別しているのですか... なるほど。それ
が完璧なら問題なさそうです。

  個人的に心配だったのが、複数ある iconv の実装のどれでも同じように問
題なく動いてくれるかどうか、という点でした。
  gettext は GNU 以外は vendor の実装しかなさそうなので(この前提は合っ
てます?)、最近の Solaris への対応のように --with-included-gettext を強
制させる、といった対処で問題なさそうなのですが、iconv は果してどうなの
かな、と。

# NetBSD の current には Citrus <http://citrus.bsdclub.org/> の成果物
# が入ったとか聞いたような。

  gettext/Namazu に閉じた範囲で問題がないと言えるだけの test を
configure 時にできればいいんですかね。
-- 
野首 貴嗣
E-mail: knok@xxxxxxxxxxxxx