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

Re: allegro

Noriyuki Soda wrote:
> > XFree86はversion4から3D機能をサポートしていて、
> > allegroはその機能が使えれば、その機能を使ったlibraryを作るため、
> > XFree86-3*とXFree86-4*でPLISTが異なります。
> 
> これって、実行時の環境で make することを仮定しているってことです
> よね。それは、まずいんじゃないですか?
話がループしているので簡単に説明すると
環境依存の項は4つあって1:3D、2:mmx、3:oss、4:svgalibです。
これらの環境依存性はkinput2やghostscriptと同じで、
binary配布をするときにの解決法は3種類あります。
1.すべての条件を満たした（拡張機能を一切使わない）binaryを用意する
2.すべての環境（あるいは典型的な環境）のpackageをそれぞれ用意する
3.binary配布を行わない
#付け加えておくとossがライセンス上binary配布を行えないので、
#oss依存binaryの配布は無理です。

> package の場合、make したバイナリを ftp.netbsd.org に置いて配って
> いるわけですから、make 時の環境と実行時の環境は異なります。
> 従って、make する時の環境がどうであっても、その make 環境でサポート
> 可能な全ての機能を織り込んだバイナリを作る方が良い筈です。
この文章を、すべてのサポート可能な環境のpackageを用意するという意味でとると、
2の4乗で16通りのpackageを用意するという事になります。
（現在はsvglibは使わず、またossの機能に関しては別pkgsrcにしているので4個）
#なお、port別で考えると、i386は4種類、他はXFree86で分けた2種類です。
#技術的には可能ですが、pkgsrcを分けるのは、やるかどうかの問題です。
#またi386、Xfree86-4、enable-mmxのマシンではすべての環境のbinaryが構築できます。
#（環境依存項はすべてCONFIGURE_ARGSで指定できます）

> また、X サーバーに実際に接続してみるといった処理は、bulk build 環境
> では成立しない可能性がありますから、そういう意味でもまずいです。
> あと、将来的には、package も cross build 対応にしたいでしょうから、
> 可能なら、コマンドの実行もしない方が良いです。
> 
> >> Xのextensionがバージョンによって違うのでしょうか。その
> >> extensionをアクセスするためにライブラリ関数は用モされていな
> >> いのですかね。もし用意されているのであれば、その関数の有無で
> >> 判別すべきではないでしょうか。
> AC_CHECK_LIB で extension 用の関数の有無をチェックできるなら、
> cross build の場合でも正しく動作しますし、可能なら、この方法が
> ベストだと思います。
結局、make時とinstall時でpackageとマシンの環境チェックを行う訳で、
AC_CHECK_LIBでlibraryをチェックするにしろ、
install時のコマンドや環境変数でXのversionを識別するにしろ、
やっている事の意味は同じです。
#Xのversionとlibrryの有無は機能的には同義です。
#ただOSのupdate等でバージョンと置かれているfileに不整合が出たときは、
#pkgsrcをXのversion(機能)に合わせておかないと不良なpackageができます。

大石修＠分子研