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

Re: allegro

SUNAGAWA Keiki wrote:
> > packageしか使わない人の事まで考えるとpkgsrcを分けた方がい
> > いのかもしれませんが、この場合、pkgsrcが環境の組み合わせで
> > 増殖するので、可能ならば避けたいです。
> 
> どうするかは方針によりますね。何か決っていましたっけ?
> 
> 最近は条件が複雑だと保守が難しくなるので分けた方がいいかなと
> 思っています。環境が4種類で増えないのであればif-endifで頑張
> るのもありでしょう。
fontなんかだとdistfileが個別にバージョンアップするので分けた方がいいですし、
bin,libとdocあたりが別fileの場合は、使わない物もあるので分けた方がいいと思います。

allegroの場合は、一つのsource fileで複数の条件依存なので
その依存関係はkinput2のcannna、wnn、sj3への関係に似ていますし、
Xへの依存はghostscript的です。

binaryを作らずpkgsrcのみの提供の場合はif〜endifで対処しても
保守の労力はそんなに変わらないと思います。
一方で、binaryを提供する場合は環境依存をすべて識別しないといけません。
すべての条件が満たされたbinaryでないと、動かないばかりか、
svgalibはioplでレベル変更後、I/Oを直接叩き、
ossもsourceが見れないので深くはわかりませんが、多分I/Oを叩くので、
場合によっては、機械が固まるだけでなく誤動作で壊れます。
ONLY_FOR_PLATFORMでアーキテクチャ的制限はかけますが、
同じアーキテクチャの場合に間違えて使われて実行されると非常にまずいのです。
#installで他のpackageにコマンド依存するのもスマートじゃないです。
#ossのpackage自体はinstallではじかれるけど、
#ossのlibに依存したallegroのpackageができると問題が残ります。
#最終手段としては、mmxとossとsvgalibをdisableしてしまえば何も問題は出ない。

> devel/cpuflagsとxdpyinfo|grep releaseでどうでしょうか。
こっちは試してみます。

とりあえず叩き台のpkgsrcを作ってみます。

大石修＠分子研