2013/11/29(金)2013年後半のプログラミングフォント事情

2013/11/29 17:05 PC（プログラミング）
以前(4～7年前？)調べたときとだいぶ状況が変わってるようなので久々にさらってみた。

前提はWindows7 64bit、WUXGA(1920x1200)モニタ環境。

日本語入力有りという使用方法を考える。

■結論
以前の調査では、
・IPAフォント類ではJISカバー率が低すぎて無理(これは誤認だった？)
・悔しいけどMSゴシックは悪くない
・とりあえずこだわるならOsakaとか？

うろ覚えだがこんな結論だった。

で、先に今回の結論を書くと、
「よくわからないのでMSゴシックを使おう」

はい、そこ物を投げない。

もうちょっと詳しく書くと、

●gdipp, MacType環境下なら → Ricty
●ClearType(DirectWrite)環境下で、
・ライセンスが怪しくても良いなら → Consolas + MeiryoKE Console(フォント合成)
・それがダメなら → Migu 1M(好みでMigMix 1M, VLゴシック)
●標準アンチエイリアス環境下で、
・記号類が半角表示でも良いなら → Consolas + (MSゴシック or MeiryoKE)(FontLink)
・ライセンスが怪しくても良いなら → MeiryoKEゴシック or MeiryoKE Console
・どれもダメなら → MSゴシック

以下調査。

■レンダリング周り
Windows環境では厄介なことにフォント選びよりもレンダリング環境を先に考える必要がある。
大きく分けて3つ。まあ想像通り一長一短あるわけで。

●標準アンチエイリアス
Windows標準機能。
コントロールパネル -> ディスプレイ -> ClearTypeテキストの調整。
チェックボックスをOFF。

[メリット]
・標準

[デメリット]
・アルゴリズムが悪いのか、ビットマップフォント以外はかなりぼけやすい。視認性が悪い。

●ClearType(DirectWrite)
Windows標準機能。
コントロールパネル -> ディスプレイ -> ClearTypeテキストの調整。
チェックボックスをON。

もしくはDirectWriteを実装したアプリケーションを使う。

[メリット]
・標準アンチエイリアスより視認性が向上することが多い。
・DirectWriteは実装によってはかなり調整可能(秀丸, FireFoxなど)

[デメリット]
・ClearType Tunerの調整範囲ではgdipp, MacTypeより劣る
・標準ClearTypeはサブピクセル描画による偽色をかなり盛るため、背景色によっては目立つ・衝突する
・上記により目が疲れやすくなる可能性あり
・標準ClearTypeは縦方向にアンチエイリアスをかけないため、横線が多い文字(漢字とかだよ！)で恩恵が薄い。

●gdipp, MacType
いわゆるgdi乗っ取り系。

[メリット]
・OS全体に影響
・調整次第だがClearType系よりも綺麗？

[デメリット]
・アプリケーション(独自レンダリングを持つ)によっては反映されない
・アプリケーション(古いゲーム等)によっては文字描画が壊れる
・一部、標準アンチエイリアス環境下で視認性が高かったフォントがかえって悪化する可能性がある
・乗っ取り系なのでおそらくリソースを食う
・gdippはカスタマイズ性低い
・MacTypeはgdippよりカスタマイズ性が高いが、インストーラがadwareだし中国製で英語になりきれてないところがある

[参考]
フォントスムージングの比較 - かえでのWebログ


■フォント
フォントの話に移る。

●欧文
まず、欧文フォントでもっとも趣味に合うのはConsolasだ。視認性が高く、0がslashed、小サイズでも読みやすい。ほとんどの文字で見分けが付く。若干l(半角エル)と1(いち)の見分けがあやしいが、許容範囲内。標準アンチエイリアス下でも高い視認性を誇る。

よってConsolasを軸にする。

Consolasライクな欧文フォントを探すと、
・Consolasオマージュでラインセンスが緩いInconsolata
・#が低いGoogle製Anonymous Pro
・MacのMenlo
・MenloライクなMeslo LG M

あたりを見つけた。ただし、MenloはWindowsに入れようがないので除外。

What are the best programming fonts? - Slant
Top 10 Programming Fonts

これらは日本語フォントとどうにかしてくっつけないといけない。

●日本語
またこれに近い欧文を備えるなり組み込んだりした日本語フォントとして、以下の物を見つけた。
・Ricty
プログラミング用フォント Ricty
・MigMix 1M, Migu 1M
M+とIPAの合成フォント
・VLゴシック
VL Gothic Font Family

M+に不足部分を補う物がトレンド。M+すごい。

最後にライセンスがあやしいメイリオ改造手段と、
MeiryoKe
Windows で見やすくて綺麗なフォント表示 ? MeiryoKe に変更し、MacType で滑らかにする | すぐに忘れる脳みそのためのメモ

さらにそれにConsolasを合成しちまえというもの。もうここら辺はライセンス的にはかなり怪しい。
MeiryoKe_ConsoleとConsolasの合成方法 - GONE WITH THE MEDICINE

●ライセンス
ライセンスを確認する。

欧文ではライセンスが緩い(改造・合成が出来る)のが、Inconsolata, Anonymous Pro, Meslo LG M。詳細は各Webを確認。

日本語系ではM+がまだ字体が足りてないためIPAで補完している物が多く、だいたいがIPAのライセンスに依存。

●欧文フォントの合成方法
欧文フォントはどうにかして日本語とくっつける必要がある。

フォント自体を合成して新しい一つのフォントを作る方法と、WindowsのFontlink機能を使う方法がある。またもや一長一短。

○合成
FontForge
unofficial fontforge-cygwin
等を使用する。

ASCII部(U+0021～U+007e)をはめ込むだけならさして難しくない。が、フォントの特性を理解し、綺麗に、違和感なく仕上げるのは難しい。ビットマップ絡むとさらに難解。先に上げたMeiryoKe + Consolasの合成方法なんかを参照。

合成する方はフォントのライセンスに注意。基本的にOS付属の物はたぶんライセンス×。

○FontLink
FontLinkについては
Windows 7 で日本語フォントを Segoe UI に合わせて調整
FontLink SystemLink の設定値の数字について

を参照。

レジストリをいじって、対象フォントに参照のない文字はリレー方式で次のフォントを見に行くようにする。

結果を確認するのにいちいちOSの再起動が必要。すごくめんどくさい。

Consolasなどの欧文フォントではU+25CF("●")等一部の記号が含まれている。このため、記号等で欧文フォントで描画される物と日本語フォントで描画されるものがあり表示がイマイチになる。"●"は半角、"◎"は全角とか言うことになりかねない。

●評価
自分の評価が高い順に挙げていく。
ただし、どうしても環境依存。
書体記号類一部欧文gdipp/MacTypeClearType標準アンチエイリアスライセンス
Ricty◎○○△×○
Consolas + MeiryoKE Console(フォント合成)○(合成によるズレ)○○○△×
Migu 1M(好みでMigMix 1M, VLゴシック)○○○○△○
Consolas + (MSゴシック or MeiryoKE)(FontLink)◎×○○○○(MSゴシック) ×(MeiryoKE)
MeiryoKEゴシック or MeiryoKE Console△○○○○×
MSゴシック△○○○◎○
○Ricty
ConsolasオマージュのInconsolata + Migu 1Mという理想型。
書体そのものは可読性が高く決定版とも言えるようなフォントだが……

実質、gdipp or MacType必須。

Inconsolata自体が標準アンチエイリアス環境下ではアンチエイリアスが強く出てしまう書体のため、Rictyもそれを引き継いでボケボケ・欠け欠けでかなり厳しい。

標準ClearType環境下でもちょっと厳しい。DirectWriteなら調整によっては。

gdipp, MacTypeはデメリットがいくつかあり、これに踏み切れない場合は別のフォントを考える必要がある。

○Consolas + MeiryoKE Console(フォント合成)
gdipp, MacTypeでなくともClearType系で十分な視認性を得る。
しかし、二重にライセンスがあやしい。

さらに、合成のやり方次第だが、
・文字の水平位置ずれが生じる
・Consolasが持っていた標準アンチエイリアス下での視認性を失う
等の問題がある。

ライセンスあやしいのはダメという場合、別のフォントを考える必要がある。

○Migu 1M(好みでMigMix 1M, VLゴシック)
gdipp, MacTypeでなくともClearType系で十分な視認性を得る。

Consolasよりは欧文書体が好みではない("*"が浮く)。

標準アンチエイリアス下ではアンチエイリアスが強く出てボケボケになる。

ClearTypeの描画が気に入らない場合、別のフォントを考える必要がある。

○Consolas + (MSゴシック or MeiryoKE)(FontLink)
Consolas部はビットマップでないはずだが、標準アンチエイリアス下で高い視認性を得る。MSゴシック, MeiryoKEは好み次第。MeiryoKEはゴシックでもConsoleでも。当然ライセンスあやしいのがダメならMSゴシック。

ちなみにMeiryoKEをリンクする場合は横長になる問題が知られている。レジストリの値を好みで、
"meiryoKe_602r1.ttc,MeiryoKe_Console,128,85"
や
"meiryoKe_602r1.ttc,MeiryoKe_Console,128,100"
などとして、比率を調整した方が良さそうだ。

一部の記号類(ex.U+25CF("●"))がConsolas側に含まれるため半角描画される。この際の挙動はソフトによって違いキャレットの移動も半角に成るケース・全角になるケースと様々。

これが許容できない場合、別のフォントを考える必要がある。

○MeiryoKEゴシック or MeiryoKE Console
標準アンチエイリアス下で高い視認性を得る。

0にスラッシュもドットも入っていないので、Oと見分けが付きづらい。

ライセンスあやしいのはダメという場合、別のフォントを考える必要がある。

○MSゴシック
最後に行き着いたのはやはりここ。
標準アンチエイリアス下で高い視認性を……　得る。

ビットマップを大量に持っているのが強く、やはり100dpi程度までのモニタだとビットマップフォントが光る場面はある。漢字類の罫線の太さの調整はさすが謹製といったあたり。

○おまけ
アプリケーション上でASCII部とそれ以外でフォントを変えられるものがあればそれを使うとよい。Consolas+MeiryoKE(MSゴシック)で幸せになれそう。日本語テキストエディタだと、newQX, WZ EDITOR, xyzzyあたり。もちろん汎用性はナッシング。

●総括
結局自分の使い方だが、M+に期待しつつエディタを選んでソフト合成するか、Consolas＋MSゴシック(FontLink)でしのぐといった感じになりそう。DirectWrite調整でRictyが使えないかどうかも継続的に検討してみる。

前回調べたときは発芽レベルだったはずのM+が成長して、日本語プログラミングフォント界隈の幹のようになってきた。M+で足りない文字をどうやって補うかが今のテーマで、その主役がIPA。今後M+が充実してくると、そこも意味のない議論になってくる。これがラインセンス緩いとは……　M+すごい。感謝。

また、Inconsolata, Meslo LG M, Anonymous Pro, Source Code Proと欧文でライセンスが緩く素晴らしいフォントが揃ってきた。後ろ２つはちょっと趣味ではないが、書体そのものは手が足りた感じがある。

なお、以前はOsaka(等幅)を好意的に受け止めていたがOsakaはa,o や 1,lの判別が難しく、プログラミング向きではなかった(そもそもWindowsで使うにはライセンスがダメ)。文章を読むにはいいフォントではある。

Windowsのレンダリングはいまいちだ。古くからある標準アンチエイリアスの品質は致し方なかったにしても、比較的新しいClearTypeで調整幅が少ない。DirectWriteはかなりいじれる感じだが、ClearTypeそのものに手を入れれば良かった気がする……

そんなこんなで、どうしても現時点でのWindows7の世界では、環境を意識して使うフォントを考える必要がある。

標準アンチエイリアスでの見栄えを良くするには、ビットマップを埋め込むか、Windowsの仕様を意識したフォントデザインにする必要がある。当然面倒なので、世のフォント作者はWindowsの標準アンチエイリアスを置いていく。ビットマップについてはIPAが打ち切ったことからも分かるように、切るか極小サイズにのみ残すのが主流のようだ。確かにディスプレイが(特にモバイルで)高精細化していることもあって、ビットマップはどんどん不要になる。M+は一応ビットマップを別配布しているが、これも極小サイズのみのようだ。

今後PCのディスプレイも高精細化するだろうし、Windowsのレンダリングにも手が入るだろう。こういうのはたぶん昔話になっていく。が、目下は何かしら工夫が要る段階だ。

ソフトを作る方からすると、DirectWriteを頑張ってるソフトだけ見た目が優位になる。テキスト周りを扱うソフトが競争やるなら、もうDirectWriteは必須という状況らしい。

そしてMicrosoftがWindows9でテーブルをひっくり返す。この世界ってそういう風に出来てるのよね。

なお、決まり文句ですが全て自己責任でお願いします。
コメント（1件）

2013/02/21(木)RubyでUTF-8ファイル名＆外部コマンド実行

2013/02/21 16:33 PC（プログラミング）
[2017/05/02 追記有り]
Rubyの``やsystemで外部コマンド実行するときに、実行ファイル自体や引数にUTF-8文字(SJISマッピング無し)が渡せないのであれこれ悩んだ問題。

確認はWindows7 64bit & Ruby1.9.3p0(ActiveScriptRuby)

前提。WindowsはファイルシステムがNTFSならUTF-8ファイル名を命名できる。内部コードもUTF-8になっている(はず)。しかし古いAPIを触ったり、INPUT/OUTPUT周りを見るとまだShiftJIS(Windows-31J)が多い。このズレは厄介で、ハマりどころのA代表。特にRubyの場合、UNIX寄りでWindows特有処理のケアはやっぱり甘い…

閑話休題。Windows&UTF-8の扱いが比較的良くなっているRuby1.9系(Dir.globの引数に.encode('utf-8')などでUTF-8文字列を渡すとUTF-8ファイル名が取れる)でも、マジックコメント入れてUTF-8保存しただけだと外部実行が出来ない。
# -*- encoding: utf-8 -*-
# -*- coding: utf-8 -*-

`utf8_filename`
どうにも通らない。SJISマッピング出来るファイルなら、SJISでやればいいだけの話なのだがUTF-8にあってSJISにない文字(U+2661(はーと)とか)が混ざってると動かない。


で、とりあえず色々やってみたのだが、結論から言うと綺麗に書くのは諦めた。

ちゃんと調べるべきなのだが(やってない)、どうもRubyが叩いてるAPI自体が古いんじゃないかという。

unicode - Ruby system() doesn't accept UTF-8? - Stack Overflow

なので、苦肉の策。
バッチファイルを作成して、それを実行する。
# -*- encoding: utf-8 -*-
# -*- coding: utf-8 -*-

open("tmp.bat", "w"){ |fp|
	fp.write("chcp 65001\n")
	fp.write("utf8_filename\n")
}

out = `tmp.bat`
Windowsのバッチ実行ではコードページが合えば、UTF-8ファイル名も通るのでそれを利用する。引数にファイル名を指定するときも同様。\\の数とかダブルクオート囲いとか先頭に./が必要な場合は適切にすること。

うーん、汚すぎて死にそう。

[参考]
Rubyで外部コマンドを実行して結果を受け取る方法あれこれ #Ruby - Qiita

systemuは知らなかった。

[2017/05/02 追記]
やはりきれいには書けていないが、さすがにbatを吐き出すのは汚すぎるということで苦肉の策第二段。小改善してみた。今回はnyagosを使用している。
	out = ""
	Open3.popen3("c:/********/nyagos.exe"){ |stdin, stdout, stderr, thread|
		stdin.puts("chcp 65001")
		stdin.puts("#{COMMAND} \"#{utf8_filename}\"")
		stdin.close
		out = stdout.read
	}
nyagosでなくても良いのだが、cmd.exeやnyaos.exeだとchcp 65001したあとにUTF-8を流し込めない。
ここらへんは、chcp後に貼り付けが出来るかどうかで確認する。

Windows APIを直接叩けば済むような問題に見えるんだよなあ。
ここはまた次回。
コメント（1件）

2012/06/16(土)AutoIt!でBTScanをちょっと改良

2012/06/16 11:33 PC（プログラミング）
BTScanの記事なのかAutoIt!の記事なのか判断付かないけどとりあえず書いておこう。

AutoIt!はuwsc等で知られる、いわゆるWindows自動化ツール(マクロレコーダ)である。

uwsc(無料版)と比較すると、
[劣る]
・自動記録がちょっと弱い(いわゆる座標依存系のスクリプトを吐くことが多い)
・専用エディタが微妙に使いづらい
(一度拡張子を.au3にしないとメニューが開かないって！)
・仕様に慣れるまでに時間がかかる

[優る]
・とにかく高機能
・正規表現文字列操作もファイル操作もなんでもあり
・GUIも作れる、フォームエディタ付きで作りやすい
・exeもお手軽に作れる(uwscだとPro版のみ)

といったような感じ。どっちかというとマクロいじってると言うよりほぼ一言語を覚えるのに近い。類似のことはやろうと思えば.NET系列なりRubyなりでもできるわけで、初期学習コストが高そうなAutoIt!を使うメリットはかなり微妙なところではある。とはいえ、やっぱりお手軽感はあるか。

さて、今回BTScanにちょっと機能が欲しいってんで、AutoIt!でスクリプトを書いてみた。

目的としては、カウンタリセットボタンが欲しいのと、フォルダ名の最下位部だけ変更するような機能を追加したい。

AutoIt!で書くとこんな感じ。
#include <ButtonConstants.au3>
#include <EditConstants.au3>
#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
#Region ### START Koda GUI section ### Form=
$Form1 = GUICreate("BTScan Tool", 623, 75, 192, 114)
GUISetFont(9, 400, 0, "ＭＳ Ｐゴシック")
$inputFolder = GUICtrlCreateInput("", 8, 8, 489, 20)
$buttonReset = GUICtrlCreateButton("カウンタリセット", 456, 40, 161, 25)
$buttonFolderSet = GUICtrlCreateButton("フォルダ名セット", 504, 8, 113, 25)
GUISetState(@SW_SHOW)
#EndRegion ### END Koda GUI section ###

Run("c:\\hogehoge\\BTScan\\BTScan.exe")
WinWaitActive("[Class:#32770]")

While 1
	$nMsg = GUIGetMsg()
	Switch $nMsg
		Case $GUI_EVENT_CLOSE
			Exit
		Case $buttonFolderSet
			$org = ControlGetText("BTScan 3", "", 1000)
			$newFolder = GUICtrlRead($inputFolder)
			$newPath = StringRegExpReplace($org, "^(.*?)\\([^\\]*)$", "$1\\" & $newFolder)
			ControlSetText("BTScan 3", "", 1000, $newPath)
		Case $buttonReset
			ControlSetText("BTScan 3", "", 1005, "1")
	EndSwitch
WEnd
これを実行すると、ボタン2つテキストボックス1つのフォームがBTScanと共に立ち上がる。hogehogeは適当に読み替えて欲しい。例外処理とかは全く考慮無し。

ちなみに、コメントで囲まれたGUI部分はフォームエディタをWYSIWYGにいじってそのまま貼り付けただけ。

このフォームは別のファイルで保存しておける。コピペの手間が発生するとは言え十分にありレベル。

…うーん、でもやっぱり他の言語使った方が良い？

(2012/7/12) スクリプト微修正。TWAINダイアログ出てても変更反映可に。
コメント（0件）

2011/12/27(火).NETのSerialPortでケーブルを抜くと例外

2011/12/27 13:40 PC（プログラミング）
.NET(WinXP, .NET 3.5で発生)のSerialPortクラスで、USB-Serial変換ケーブルを使用している際に起こる問題。このケーブルに紐づくCOMポートをOpen()後、Close()前にケーブルを抜くと例外が発生する。

原因は.NET側のバグ。ケーブルの挿抜というかCOMポートが消えることを考慮していない。

発生する例外は把握している限りで2種(UnauthorizedAccessException, ObjectDisposedException)。前者は、Dispose()中に発生する。後者は、SerialPort内部で動いてるThreadが出してくる。

UnauthorizedAccessExceptionはラッパークラスを作って、Dispose()をオーバーライドしtry~catchで囲ってやることで対処可能。以下を参照。簡単なのでコードは書かない。

街角のリブロガー: C# SerialPortのエラー「UnauthorizedAccessException」対策

ObjectDisposedExceptionの方はちょっと難しい。発生箇所は.NET内部の別スレッドのようで、捕まえられる場所を思いつかない(存在しない？)しタイミングも不定。Thread.GetDomain().UnhandledExceptionで発生タイミングはとらえられるが、ここではキャンセルできない。古い.NET、おそらく1.1以下だとこの手の例外は処理継続となるのだが、.NET 2.0以降はアプリが落ちてしまう(WinXP/Win7, .NET 3.5で確認)。

ということで、どうもコードでの容易な対処方法がないようだ。アプリケーション構成ファイルでの回避策があるらしいので以下を参照。

SerialPort Crashes after disconnect of USB COM port | Microsoft Connect

こんな感じでよい。

program.cs
[STAThread]
static void Main()
{
	...

	//メインスレッド以外の非ハンドル例外処理
	Thread.GetDomain().UnhandledException +=
		new UnhandledExceptionEventHandler(Application_UnhandledException);

	...
}

public static void Application_UnhandledException(
	object sender,
	UnhandledExceptionEventArgs e
){
	if( e.ExceptionObject != null &&
		e.ExceptionObject.GetType() == typeof(ObjectDisposedException)) {
		
		//.NET3.5のSerialPortのバグで、ケーブル挿抜後にハンドル不能の
		//ObjectDisposedExceptionが返ることがある。このため、未ハンドル例外処理にて
		//ObjectDisposedExceptionについてのみ無視する。

		//何もしない
	} else {
		//何かメッセージを出力
		
		Application.Exit();
	}
}
以下のアプリケーション構成ファイルをアプリケーションと同じディレクトリに置く(hoge.exeが実行ファイルなら、hoge.exe.configとなる)。

hoge.exe.config
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
	<runtime>
		<legacyUnhandledExceptionPolicy enabled="1"/>
	</runtime>
</configuration>
構成ファイルを上記のように書くと、非ハンドル例外に関しては処理継続となる。釈然としないが、どうもこれが楽な方法らしい。

その他の非ハンドル例外を無視して良ければ、program.cs側の記述は不要。

.NETのバージョン変更、OSの変更で直る可能性有り。
コメント（5件）

2008/04/20(日)音量アイコンが消える

2008/04/20 16:22 PC（プログラミング）
再起動、復帰時などにタスクトレイ上の音量アイコンが消える問題。

発生状況等まとめると、

１．[コントロールパネル->サウンドとオーディオデバイス->タスクバーに音量アイコンを配置する]にチェックは入っている。

２．にもかかわらず起動時に表示されないことが多い。

３．チェックを入れ直して適用すると表示される。

４．音量アイコン以外にも、「ハードウェアの安全な取り外し」や「Daemon Tools」のアイコンが表示されていない。
という状況。

さて、毎度のことながら原因ははっきりとはつかめなかったが対処方法は発見した。

http://hotstreet.vaio.sony.co.jp/article/article.php?id=6166
ここにあるとおり、どうもUPnPまわりのタスクトレイ表示で何か阻害が起こるらしい。

従って対処方法としては、

１．[マイネットワーク->ネットワークタスク->ネットワークに接続しているUPnPデバイスのアイコンを非表示する]をクリック

２．再起動
で終了。これで全部表示されるように改善された。やれやれ

ネットワークタスクが表示されていなければ、[ツール->フォルダオプション->フォルダに共通の作業を表示する]にチェックを入れ、フォルダの表示を切って、サイドバーにネットワークタスクが表示されるようにする。

なお、すでに[マイネットワーク->ネットワークタスク->ネットワークに接続しているUPnPデバイスのアイコンを表示する]となっていれば、この対処法は外れ。ごめんなさい。

起動時に重いタスクが走ってるとアイコン登録に失敗するという情報もキャッチしたのだが確認できなかった。ちゃんとログオンのステップを踏んでいる人はこの問題は発生しないかもしれない。

2008/02/13(水)BDS2006(Turbo C++)でBoostをコンパイルするときのあれこれ

2008/02/13 22:21 PC（プログラミング）
先に結論から。通ったときのコマンド列と環境を書いておこう。

[環境]

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 PC（プログラミング）
[環境]

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オプション足して打ち込み直す方がシンプルな解答である気もする。
OK キャンセル 確認 その他