検索条件
全4件
(1/1ページ)
2008/02/13(水)BDS2006(Turbo C++)でBoostをコンパイルするときのあれこれ
2008/02/13 22:21
[環境]
BDS2006(Turbo C++) - bcc32(5.8.2)
Boost 1.34.1
boost-jam 3.1.16-1-ntx86
bjam.exe -sTOOLS=borland --toolset=borland --prefix="C:\Program Files\Borland\BDS\4.0" install
(cmd.exe上から)
さてこれは何度か失敗した上で結果的に成功したときの環境をメモしたもの。
失敗したときのことを思い返すに、何がダメだったのかよく分かっていないのだが、可能性がありそうなものを以下に全部列挙し次回の参考にしたいと思う次第。
・-sTOOLS=borlandだけだとborlandが無いといわれ、msvcでコンパイルされる（失敗）。
warning: No toolsets are configured.
warning: Configuring default toolset "msvc".
warning: If the default is wrong, you may not be able to build C++ programs.
・--toolset=borlandは必要なのかそれだけでいいのかよく分かっていないが、上記の失敗改善には有効。
・nyacusからだとダメかもしれない。
・Boost側がコンパイルさせるBCCのバージョンに対応していれば、BCBBoostは不要（おそらく通るライブラリは増えないし、コンパイルに失敗することがある）。
・今回のBoost-1.34.1はBCC32(5.8.2)には対応していた。（調査不足）
結局、
1.自分の使っているBCCのバージョンを調べ
2.Boostが対応しているか確認し
3.対応していなければBCBBoostを当て
4.--toolsetをつけてコンパイル
ということなのだろうか。しっくりこないなあ。
BCBBoostを当てたときは-STOOLの指定を自分のコンパイラに合わせたものにする。ここら辺はその都度BCBBoostのドキュメントやForumをあさること。
さて、Boostの対応はVC++のほうがしっかりしているのは周知の事実だ。Boostの機能をフルに使いたいならば、BCBは良い選択ではない。regexはいけそうだが、相変わらずtype_traits周りがダメくさい。
対応状況はBoostのtest項目などを調べればわかる。pythonは全滅しているようだが、python環境のインストールによってはいけるのかどうか？
[参考サイト]
http://www.kmonos.net/alang/boost/build.html
http://www.gesource.jp/weblog/archives/2006/12/borland_developer_studio_2006_1.html
http://d.hatena.ne.jp/ex_2/searchdiary?word=Boost
http://www.gesource.jp/programming/bcb/46.html
2008/02/12(火)BDS2006(Turbo C++)でSTLportをコンパイルするときのあれこれ
2008/02/12 23:00
BDS2006(Turbo C++)
STLport5.1.5
minGW5.1.3
STLportのインストールで軽くはまったのでメモ。
STLportのドキュメント通りに作業したのだが、どうもパスがらみでmakeが上手く通らない。色々やってみたのだが、%BDS_DIR%\Binの.cfgを見にいっていないようである。プロンプトやシステム環境変数で指定してみたのだが、やっぱりダメ。むむ手強い。
一応の解決方法だが、まずSTLport内のREADME.borlandの指定通りに.cfgを書き換え（今回は必要なかった）、コマンドライン上でset INCLUDE=%BDS_DIR%\INCLUDE をしておく。しかしこれでも通らないようなので、.cfgをビルド作業ディレクトリ(%STLport_DIR%\Build\Lib)にコピーし、bcc.mak内の
STLPORT_INCLUDE_DIR = ../../stlport
を
STLPORT_INCLUDE_DIR = "../../stlport";"C:\Program Files\Borland\BDS\4.0\include"
に書き換える。
で、
mingw32-make.exe -fbcc.mak install
やっとコンパイル完了。
うーん、なにか根本的なところで理解が足りてない気がするなあ。ただ、やっぱりBCC32あたりの検索パスは何か変ではある。
http://members.jcom.home.ne.jp/komina/wiki/424453323030362F53544C706F7274A4F2BBC8A4A4A4BFA4A4.html
でやってるように、エラーが出たら-I/-Lオプション足して打ち込み直す方がシンプルな解答である気もする。
2008/02/12(火)BCC32周りの仕様
2008/02/12 22:32
C++ Compilerとしての性能云々以前に、コマンドラインから扱う上でライブラリ検索の仕様が妙に整合性がない。Borland(Inprise)の中の人がこんなことに気づいてないはずはないのだが、一度出してしまってる以上影響が大きすぎて変えようがないのだろう。IDEとかどっかで吸収してくれということのようだ。
ライブラリやインクルードパスについて、まずBCC32,BRCC32,ilink32のいずれでも、PATH変数で汚く指定する方法では検索しにいってくれない。コマンドラインオプションで明示するか、.cfgに書く必要がある。bcc32,ilink32はこれでよいが、BRCC用の.cfgは無いようだ。
.cfgに書くときであるが、どうも.cfgをBinの中において、Binにパスを通しても見てくれないときがある。確実なのは、コンパイル作業するときの作業ディレクトリにコピーしてやること。これなら確実に見てくれるようだ。
ただこれらは、minGWからの中からの話なので、実のところ何かPATH継承外のシェルをforkしてるだけかもしれない。ということで、ここらへんはあくまでそうかもしれないという話だけで、次記事のSTLportコンパイルの時に具体的な話を書くことにする。
2008/02/03(日)Mechanize + Hpricot恐るべし
2008/02/02 24:29
さてMechanizeに関して、どうもセレクタの仕様がよく分からない。Hpricotを取り込んでいる以上XPathやCSSセレクタが使えるはずなのだが…… バージョンが絡むからなあ。結局linksで全部返させたあとの処理は、select{} 使った方がわかりやすい感じ。安全確実。