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

Re: xmkmf & imake



おばた ナノですが、

<42F1A3BB.8E26D295@ims.ac.jp> の、
   "Re: xmkmf & imake" において、
   "Osamu OISHI <oishi@ims.ac.jp>"さんは書きました:

> > xmkmfや imake は大丈夫ですが、最終的には cpp を呼び出すので、
> > そこでwrapperに食われます。
> CFLAGSやCPPFLAGSの話だとすると、
> たぶん、まだまっとうな解決法はありません。
> これらの環境変数はいろいろな所で設定されているので
> 設定された状態をコンパイルの直前まで予測できないからです。
> #pre-buildでwrapperで設定したファイル自体を書きなおすことはできます

ええっと、勘違いでなければ多分大丈夫な話だと思いますが、私の勘違い?
make がCFLAGSやら直接指定されてるのやらを使って
cc -I/usr/pkg/include ...
と呼び出して、実は cc は wrapper で、
cc -I{$WRKSRC}/.buildlink/include
に書き換えて本物が呼ばれて、って動きだと思うのですが、
私のところでうまく動かなかったときには、なぜだか imake の tmpl が
buildlinkの下に無かったとかそういう謎の動きをしたわけで。

大石さんのおっしゃってる問題って何でしょう?

> pkgsrcが要求するものはpkgsrc内で用意しておかないと
> bootstrapを使った他のplatformで障害が出やすいので
> xの機能の一部を導入したい場合の理想はxのpkgsrcに依存させることですが
> pkgsrcのxは依存関係が無茶苦茶厳しいのと
> itools程度には細かく分かれていないので結構な容量になります。

元のX自体がまあ、分割するようには考えられていませんから、
致し方ないところですね。
# x11/imake と x11/xorg-imake に限れば、何にも依存してないし、
# 大きさ自体も devel/nbitools とそんなに変わらないようですが。

> でも、xを使わないアプリケーションがxのtoolを使っている事と、
> pkgsrc的にはimakeを使うと必ずxに依存することが原因なので
> 綺麗に解決したいなら、アプリケーション的にconfigureを書いてしまう事でしょうか。

Wnnみたいに、ですかね。
Canna-3.7p3を取ってきてみたら、Imakefile の中から configure を呼んでるんですね。
何で imake にこだわってるんだろう?

-- 
お役に立てない(^^;
OBATA Akio / obata@lins.jp
せかいは ひろがる ちきゅーは まわる。