Namazu-devel-ja(旧)

[Motoyuki Kasahara <m-kasahr@xxxxxxxxx>]

笠原です。

* From: Satoru Takabayashi <satoru-t@xxxxxxxxxxxxxxxxxx>
* Date: Tue, 22 Aug 2000 16:20:30 +0900
> libnmzut は
> 
>   * libcに不足している関数を必要に応じて補う (memmoveなど)
>   * getopt.[ch], getopt1.c を使う
> 
> ために作られています (NDTPD の libディレクトリの構成を真似し
> ています)。

# 知らなかった。NDTPD を参考にしたのか。(^^;)

ライブラリ (libnmz.a, libnmz.so) 内で呼び出している関数を補おうと
しているのか、実行可能バイナリ (namazu コマンド 等) だけで使用して
いる関数を補おうとしているのかで状況は異なると思います。

実行可能バイナリで呼び出す関数を補う場合は、面倒な話はありません。
NDTPD もこれに該当します。

また、ライブラリで使用している関数を補う場合でも、インストールした
後でそのライブラリを使って何かリンクするときのことも考えなくて良い
なら、実行可能バイナリの場合と同じくらい話は楽です。

ですが、インストールした後でそのライブラリをリンクするときのことを
考える場合は、話が複雑になります。 で、今回はこの場合に該当するの
ですよね?

# 以下 strstr() を例にして書いています。
# strstr() は libnmz.a 内で呼び出している関数だとします。

もし、strstr.o を libnmz.a, libnmz.so に含めないと、strstr() が無
い環境では、「インストールの後のリンク時」に何処かから strstr.o 
を持ってこないといけないことになってしまいます。

libnmzut.a を libnmz.a と一緒にインストールすることにして、一緒に
リンクすることにしても良いのですが、一介のアプリケーションがわざ
わざ互換関数だけを集めたライブラリを別途一個インストールするのは、
個人的には好きではありません。(単純に好き/嫌いのレベルの話です。
どうも長所/短所を具体的にうまく示せないのですが)

かと言って、strstr.o とかを libnmz.a, libnma.so に入れてしまうの
も、これも個人的には好きではないです。なんで一介のライブラリがそ
んな関数のオブジェクトまで持っているんだ、というか。

長々と書きましたが、では、次のようにしたらいかがでしょう。
ライブラリとコマンドのどちらで使っているかで、扱いを正確に分けな
くてはいけないのが面倒ですが。

| A. ライブラリが使用している関数 (例: strstr) の補い方
| 
|   A.1. ソースコードの頭 (config.h の中とか) で次のように書いて、
|        strstr() のない環境 (あっても正しく動かない環境も含む) 
|        では nmz_strstr() が呼び出され、strstr() がある環境では
|        strstr() が呼ばれるようにする。
| 
| 	#ifdef HAVE_STRSTR
| 	#define nmz_strstr strstr
| 	#endif
| 
|   A.2. strstr.c は strstr() ではなく、nmz_strstr() を定義するよう
|        にする。
| 
|   A.3. nmz_strstr() のコードを持った strstr.o は libnmz.a に含め
|        る。strstr() を持っている環境では strstr.o をライブラリに
|        含めない。(含めたとしても実害はない)
| 
| B. コマンドが使用している関数 (例: getopt) の補い方
| 
|   B.1. 従来通り libnmzut.a に含めるようにする
|   B.2. 従来通り libnmzut.a はインストールしないようにする。
________________________________________________________________
                                    笠原 基之(かさはら もとゆき)