[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: allegro

>>>>> On Wed, 09 Oct 2002 17:10:33 +0900, Osamu OISHI <oishi@ims.ac.jp> said:

> 話がループしているので簡単に説明すると

う、すいません。スレッドをちゃんと追っていません。_o_

> binary配布をするときにの解決法は3種類あります。
> 1.すべての条件を満たした（拡張機能を一切使わない）binaryを用意する
> 2.すべての環境（あるいは典型的な環境）のpackageをそれぞれ用意する

pkgsrc の基本ポリシーは、1. でも 2. でもなく、
4. すべての機能を組み込んだ (全ての拡張機能をサポートする) binary を
  一つ用意する。
ですよね?
実際、kinput2 の場合、全ての機能を組み込んでも、バイナリが大きくなる
なるだけですから、デフォールトでは、4. の方法になっていたと記憶して
います。

> 3.binary配布を行わない
> #付け加えておくとossがライセンス上binary配布を行えないので、
> #oss依存binaryの配布は無理です。

>> package の場合、make したバイナリを ftp.netbsd.org に置いて配って
>> いるわけですから、make 時の環境と実行時の環境は異なります。
>> 従って、make する時の環境がどうであっても、その make 環境でサポート
>> 可能な全ての機能を織り込んだバイナリを作る方が良い筈です。

> この文章を、すべてのサポート可能な環境のpackageを用意するという意味
> でとると、2の4乗で16通りのpackageを用意するという事になります。

今回の場合に限って言うと、svgalib は、とりあえず使わないんですよね。

oss の件は、(できるかどうかは棚上げしにした) 理想論としては、下記の
2 つの方法が考えられると思います。
a. oss ありにする。pc98 のようなケースは、実行時に hw.machine を判別
  して、oss を呼び出さないようにする
b. oss ありなしで、pkgsrc を分ける

現実的な話に戻すと、pkgsrc のデフォールト設定というのは、
ftp.netbsd.org でのバイナリー配布イメージを作成する場合の設定として
扱った方が良いと思います。ソースから make する場合に関しては、make
する人が自由に設定できるわけですから、デフォールト設定をどうするか
という判断の基準にする必要はないと思います。
だとすると、ライセンス上 binary 配布を行なえない oss をデフォールト
で有効にする必要はなく、
c. デフォールトは oss なし。pkgsrc から make する人は、mk.conf の設定
  で oss も使えるようにする
というので、良いのではないでしょうか?

mmx についてですが、mmx を使うように configure したバイナリって、mmx 
なしの状況だと動作しないんでしょうか?

もし、動作するなら、デフォールトで使うようにしてしまって問題ないです
よね?

大石さんがこの点を問題として挙げているということは、動作しないという
ことでしょうか?

もし動作しない場合、理想論としては、oss の場合と同様
a. mmx ありにする。かつ、実行時に mmx の有無を判別して、呼び出すコード
  を分けるようなパッチを当てる。
b. mmx ありなしで、pkgsrc を分ける
ということになります。が、a. も b. もマンパワーの点で無理というので
あれば、結局 oss と同様、
c. デフォールトは off にして、mk.conf の設定で有効にできるようにする
ということになるんじゃないでしょうか?

> 結局、make時とinstall時でpackageとマシンの環境チェックを行う訳で、
> AC_CHECK_LIBでlibraryをチェックするにしろ、
> install時のコマンドや環境変数でXのversionを識別するにしろ、
> やっている事の意味は同じです。

> #Xのversionとlibrryの有無は機能的には同義です。

XFree86 のバージョンを調べているという意味では同じですね。
ただ、pkgsrc として見た場合には、build 環境と実行環境を、はっきり
区別するというのは非常に重要です。

build を行なうマシンでは、そもそも X server 自体がインストールされてい
ない ($DISPLAY を他のマシンに設定している)、ただし X client を build 
するために、X のライブラリは一式インストールされているというような状況
もありうるわけです。

バージョンを識別するのに xdpyinfo を使うと必ずしも意図した結果が得られ
ない (*1) わけですが、X -version を使う方法でも、上のような場合を
考えれば、やはり まずいわけです。

pc98 ポートが統合された場合、pc98 ポート特有の package binary であって
も、make は、今時の速い AT互換機を使いたくなるでしょうし、(今の pkgsrc
では問題があるわけですが) 将来的には、他のアーキテクチャの package 
binary も、cross build できると非常に嬉しいわけです。実際、debian では 
package の cross build に対応しているわけですし。

話を戻すと、バイナリ配布を行なうという立場から考えると、XFree86 は既に
大問題になっています。というのは、XFree86-4.x は Xaw の major 番号は変
わっているわ、内部に freetype やら Mesa やら含んでいるわで、異なる 
XFree86 のバージョンで作られたバイナリは、別の XFree86 のバージョンの
環境で利用しようとすると、問題が生じるからです。

ベストなのは、当然 XFree86-3 と XFree86-4 に関して、別々の package
binary に分けるということですが、現状はそうなっていませんし、マンパワー
の関係で、今後も分けることにはなりそうにないです。

で、実際のところ、どうしているんだろうと思ってみてみたんですが、

devel/pango/Makefile では
	# directory appeared in XFree86 4.*
	# if it is there, we are using XFree86 4.* and will
	# install some additional files
	.if exists(${X11BASE}/lib/X11/locale/common)

graphics/glu/Makefile や graphics/MesaLib/Makefile では、
	# Check if we got libGLU distributed with XFree86 4.x.
	.if (${OPSYS} != SunOS) && exists(${X11BASE}/include/GL/glu.h)
	_IS_BUILTIN_GLU!=	${EGREP} -c BuildGLULibrary ${X11BASE}/lib/X11/config/X11.tmpl || ${TRUE}

graphics/xpm/Makefile では
	# Check if we got Xpm distributed with XFree86 4.x or Solaris 9.
	.if (${OPSYS} != SunOS)
	.if exists(${X11BASE}/include/X11/xpm.h) && \
	    exists(${X11BASE}/lib/X11/config/X11.tmpl)
	_IS_BUILTIN_XPM!=	${EGREP} -c NormalLibXpm ${X11BASE}/lib/X11/config/X11.tmpl || ${TRUE}

ということをしているようです。

というわけで、可能なら、
b. XFree86-3.x と XFree86-4.x に分ける
それが無理なら、
c. 今回利用する X の extension が存在するかどうかを、
  imake のテンプレート (lib/X11/config) なり ライブラリのヘッダファイル
  なりを grep するとか、ライブラリファイル (libなんとか.a) を nm して
  みるとかして判別する
というのはどうでしょう?

(*1) make しているときに X を使っているとは限らないし、$DISPLAY を他の
  マシンに飛ばしている可能性だってある。実際に make 時に xdpyinfo を
  呼び出している pkgsrc が かつてあって、リリース用の bulk build 環境
  で make できないので、BROKEN とマークされてました。
--
soda