Mingw/Cygwin port status

Mingw版を自動テストに追加。全て通過しているように見えるが、実際には一部のテストは動いていない(Windowsの例外で終了している)。すべてをgdb経由で動かすとかする必要が有りそうだ。
@の付かないecho offとか懐かしいな。。バッチファイルの行頭に@で表示を省略できるようになったのは確かMS-DOS4か5からなので、昔の98向けゲームは起動するときによくecho offと出ていた。
Cygwinではほぼ全てのテストが通過しているけど修正点をまだ纏めていない。
config.hの記述内容に関して一定の合意が多分必要で、ルールが出来るまでは別途CFLAGS/CXXFLAGSを指定させる方式の予定。
Windows/Cygwin向けの環境フラグは以下の通り :

  • _WIN32 - MingwとVCで自動的に定義。
  • _MSC_VER - VCでのみ自動的に定義
  • MOSH_MINGW32 - (将来的に)config.hやライブラリインクルードヘッダで定義
  • MOSH_CYGWIN32 - (将来的に)config.hやライブラリインクルードヘッダで定義

わざわざMOSH_をプレフィックスした別のフラグを準備しているのは紛らわしいかもしれない。もっとも、これらの環境フラグが使われる機会はそれほど多くないはずなので重要な問題とは考えていない。
セマンティックなフラグを準備するかどうかの方が重要な問題で、例えば、ソースコード上のwidecharをscheme内部のusc4stringに変換するマクロUCは環境ごとに異なる内容になるが、これを分ける際に、

  • if defined(_WIN32) || defined(MOSH_CYGWIN32)
  • ifdef MOSH_WIDECHAR_16

の2通りの分け方が考えられる。後者のように、ポータビリティの問題で分岐しているところに名前を付けるのか、常にアーキテクチャ名を参照するのかというのが絶妙なところ。一般的なコードは前者が多いように思える。(これは間違ったフラグの使用を未然に防ぐ)
個人的には後者のように、コードの分岐には名前を付けるようにしている。これは、例えばテストケースを準備する際に、widechar=32bitなアーキテクチャとwidechar=16bitなアーキテクチャのどちらかにしか影響していないようなケースを指摘するのに役立つ。