Mingw/Cygwin support status(r1435)

あんまりローカルブランチのことをあっちのWikiに書くのは良くないということで今後はこっちに。
Cygwinサポートは乗り気では無いんだけど、Windowsユーザに気軽にコードを修正してもらうにはサポートするしかないというマーケティング上の理由。ただし、リリース時期の予測を鑑みて1.7系からのサポート。Cygwin 1.7は今年の前半にはリリースされる。
Cygwin 1.7からIPv6が使えるようになったり、ソケットの扱いが改善されたりするなど多くの是正がなされている。Cygwin 1.5はあまりにも大量の間違いが有るので(まぁ動くとは思うけど)サポートしない。LinuxMingwに移行すること。
Mingw上のビルドは論理的には可能だけどあまりオススメできない。

ステータス

Cygwinサポートのために追加のifdefを導入する予定。

開発体制

基本的にはVC版がオフィシャルで、メンテナンスされている。仮にTrunkを拾ってきたとしてもMingwCygwinではコンパイルできないことが多い。

MingwCygwinでは、Linux版のビルドシステムとの共存という仕事が有るので、積極的にはマージできない。

3 windows ports

つまり、Windowsだけで

の3種類のportを作業していることになる。機能性という点では、VC版とMingw版は同一、Cygwin版はSDL以外の機能を提供する予定。CygwinはGlibも提供されない可能性が高い。
Cygwin上からMingw版をコンパイルすることはサポートしていない(-mno-cygwinを使っても!)。GlibやSDLの制限に拠る。おそらくバイナリは動作するが、ファイルシステムrootの位置が変わってしまうのでmake check等で間違ったことが起こる。
さらに、Mingw版やCygwin版はオフィシャルのビルドと異なり最初からスレッドサポートを導入している。これらには追加のロックが伴うのでパフォーマンスの問題は依然有る(特にFASLでオブジェクトを作るのが遅いので起動時間が長い)。
MingwCygwinでは、いわゆるdirect threaded codeが使える。

スレッド版 / 非スレッド版

スレッド版はmoshgcではなくオフィシャルのgcに差し替えている。多分moshGCは--enable-threadでスレッドサポートを有効にしたときに正しくないコンパイルフラグを生成する。この辺は検証しきれていない。
今の所GCの問題は観測されていない。通らないテストがこの辺に由来する可能性は有る。

buildbot

コード変更はbuildbotで自動的にチェックしている。基本的にMingwでの作業が一番面倒で、APIはWin32でありながらビルドシステムはLinuxと互換してなければいけない。。
今の所、ia32(Mingw/Linux)、amd64(Linux)でテストしている。このリストに無いアーキテクチャは、Wikiで『互換性が有る』と書いていても互換性が無いかもしれない。
Mac OS対応は今後交渉予定。Darwinなら直ぐできるけど、Darwinで動くけどMacOSではダメというケースが有り得るので没。
PowerPC Linux版のテストは先延ばし。LLVM bindingの書き直しが済んだらCell B.E.だけの対応予定。
VCはビルドとテストを自動化するための良い手段が思いつかない。CMakeあたりでビルドシステムを作り直す(LLVM方式)か、ちゃんとしたnmakefileを書くかのどっちかだろうなぁ。。
Cygwin以外は全てLinux上のコンパイラないしクロスコンパイラでコンパイルしている。
Cygwinは何故かXen上で動かすと異常に遅いので対応策を検討中。追記 : SMPにしていた所為だった。次のエントリ参照。
Windows上ではmoshのtest\test.batは使用せず(テストがWindows例外で終了しても成功と見なされるため)、テストの出力を全部ログして目視で(grepで)チェックしている。