[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: xmkmf & imake
OBATA Akio wrote:
> > > 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の下に無かったとかそういう謎の動きをしたわけで。
>
> 大石さんのおっしゃってる問題って何でしょう?
私の方も勘違いしているのかもしれませんが
始めの話はimakeのconfigが別の所に置かれていているので
そのパスが見つからないためconfigが読み込めないって話ではなかったでしたっけ。
configやxmkmfが見えるならサーチするパスを調べる情報はその中に書かれているので
当然読み込むべきusr/pkg以下のパスも設定されると思った訳です。
その後にcppの-Iのパスが見えなくなるという話が出たので
imakeで設定されたパスが、別のところに記述されているCFLAGS等でリセットされて
cppに渡っていないと解釈しました。
CFLAGSなどはpkgsrcのMakefile中でも記述できますが、
pkgsrcのデフォルト設定や、platformの環境変数でも定義されるので
Makefile中に書かれた事だけではその中身を判断することができないと書きました。
> > pkgsrcのxは依存関係が無茶苦茶厳しいのと
> > itools程度には細かく分かれていないので結構な容量になります。
>
> 元のX自体がまあ、分割するようには考えられていませんから、
> 致し方ないところですね。
> # x11/imake と x11/xorg-imake に限れば、何にも依存してないし、
> # 大きさ自体も devel/nbitools とそんなに変わらないようですが。
コメントに答えるの反則のような気もしますが、
昔、meta-pkgs/XFree86関連のもの入れようとしたら素のxが入っていないと
エラーが出てコンパイルできないものがあった気がしたもので。
あと、x11/imakeはソースで20MB程度で展開すると130MB程度ありますけど
クロスコンパイルを前提にしてますか?(ハンドヘルドpcの流れなので)
--
大石 修