Re: xmkmf & imake

[Osamu OISHI <oishi@ims.ac.jp>]

OBATA Akio wrote:
> > -Iのパスであるなら
> > devel/nbitools/buildlink3.mkと
> > pkg/libexec/itools/xmkmf
> > のスクリプト中及びUSE_TOOLSの処理に従って決められます。
> > 今のnbitoolの/buildlink3.mkでは
> > XMKMF_CMD=      ${BUILDLINK_PREFIX.nbitools}/libexec/itools/xmkmf
> > になっていますが、昔はimakeを使っていたのかもしれません。
> > #xmkmfだとスクリプト中で強制的にパス指定するのでwrapperは関係無くなります。
> 
> xmkmfや imake は大丈夫ですが、最終的には cpp を呼び出すので、
> そこでwrapperに食われます。
CFLAGSやCPPFLAGSの話だとすると、
たぶん、まだまっとうな解決法はありません。
これらの環境変数はいろいろな所で設定されているので
設定された状態をコンパイルの直前まで予測できないからです。
#pre-buildでwrapperで設定したファイル自体を書きなおすことはできます

> > コンソールのみの使用を考慮せずX前提にするならnbitoolsは元より必要ありませんが
> > ハンドヘルドPCあたりでmglの上で使っている人が困りませんか？
> 
> Xは動いている必要は無いんで、ディスク容量の問題ですかね。
> X11_TYPE=native で xcomp.tgz だけ入れても、大きすぎるとか、
> x11/imake とか x11/xorg-imake だと展開できないとか。
pkgsrcが要求するものはpkgsrc内で用意しておかないと
bootstrapを使った他のplatformで障害が出やすいので
xの機能の一部を導入したい場合の理想はxのpkgsrcに依存させることですが
pkgsrcのxは依存関係が無茶苦茶厳しいのと
itools程度には細かく分かれていないので結構な容量になります。
 
> > 今のままで良ければ
> > USE_TOOLS+=     imake
> > を削って問題が無ければそれでいいと思います。
> 
> ひとまずはこれでしょうね。
> sj3-* はそうなっているわけですし。
nbitoolが作られた経緯からすればこれが一番まともな方法でしょう。
でも、xを使わないアプリケーションがxのtoolを使っている事と、
pkgsrc的にはimakeを使うと必ずxに依存することが原因なので
綺麗に解決したいなら、アプリケーション的にconfigureを書いてしまう事でしょうか。

--
大石　修