[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
せかいは ひろがる ちきゅーは まわる。