wxWidgets とは、C++で作られたクロスプラットフォームGUIツールキットである。Windows, OS X, GTK+ などに対応している。商用版のある Q なんとかと比べて見劣りするとか言うんじゃないぞ

入手

開発中の最新版を入手しよう。wxWidgets のリポジトリは、現在 GitHub でホストされている。（ただし、Issue の管理は GitHub ではなく wxWidgets Trac を使っている。GitHub でのプルリクはできる）

https://github.com/wxWidgets/wxWidgets

対応コンパイラ

最近のC++コンパイラなら対応している。また、「最近」とは到底呼べないような古いコンパイラ（MSVC 2003 とか）にも対応している。古いコンパイラはさっさと切り捨てればいいのに。互換性を重視する姿勢の現れだろう。

ちなみに、wxWidgets 3.0.x（2013年リリース、最新の「安定版」）まではWindows 9x や MSVC 6.0 もサポートしていた。

互換性を重視しているからといって最近の C++ と互換性がないかというとそういうこともなくて、C++11に対応した環境であればC++11の便利な機能を使う（override とか）ようになっている。でも move semantics を使うようにはなっていないんだよなあ。また、 wxWidgets を使ったアプリケーションを書くときにイベントハンドラで無名関数を使うこともできる。

Windows 編

公式のマニュアル docs/msw/install.txt には目を通しておこう。

ビルド前に、 include/wx/msw/setup0.h を include/wx/msw/setup.h にコピーしておく。最近では setup.h が存在しなかったら自動でコピーされるようになった気もするが、「setup0.h が更新されたけど setup.h に反映されてなかった」みたいな事故が起こるかもしれないので、念のため自分でコピーしておいた方が良いだろう。なお、あなたがこの記事を読んでいる頃には setup0.h が廃止されているかもしれないので、 docs/msw/install.txt を読んでその辺を確認しておこう。

Visual C++

以下の手順は Visual Studio 2015 Communiy Edition で試したが、VS 2010 以降なら大体同じだと思う。

IDEで

build/msw/ 以下に wx_vc**.sln みたいなのがあるので、それで行ける。

サンプルのビルド：samples/minimal/ には MSVC 201x 用のプロジェクト/ソリューションが用意されている。それ以外には MSVC 201x 用のプロジェクト/ソリューションは用意されていない。

コマンドラインからnmakeで

IDEではなくて、コマンドラインからビルドしたいという場合。

64ビットの開発環境に PATH が通っている状態で、

cd build/msw
nmake /nologo /f makefile.vc SHARED=0 BUILD=debug TARGET_CPU=x64

を実行する。SHARED 変数は 0 か 1、BUILD 変数は debug か release、32ビットの場合は TARGET_CPU は指定しない。

nmake に /s オプションを渡すと、実行中のコマンドをエコーしない。GNU makeの -s と同じ。

サンプルのビルド：

cd samples/minimal
namke /nologo /f makefile.vc SHARED=0 BUILD=debug TARGET_CPU=x64

コマンドラインから MSBuild で

nmake の欠点として、 nmake は並列ビルドに対応していない。 wxWidgets には大量のソースファイルがあるので、並列ビルドができればCPUのコアをフル稼働させてビルド時間を短縮できるはずである。

ちょっとググった感じでは、並列ビルドに対応したnmakeクローン的なものが世の中に存在するようだが、ここはやはり（？）MS謹製の MSBuild を使うのが筋だろう。

MSBuild では、 Makefile ではなくて Visual Studio 用のソリューションファイルを使う。

Configuration プロパティは Debug, Release, DLL Debug, DLL Release のいずれかを、 Platform プロパティは Win32, x64 のどちらかを指定する。

例：

cd build/msw
MSBuild wx_vc14.sln /nologo /m "/p:Configuration=DLL Debug;Platform=x64"

/m または /maxcpucount が並列ビルド用のオプションである。GNU make の -j オプションみたいな感じ。

出力がうるさいという場合は /verbosity または /v オプションで minimal とか quiet を指定すれば良い。

samples/ 以下には（minimal を除いて）Visual Studio 201x 用のプロジェクトファイルは含まれていないので、 nmake を使う必要がある。まあ、サンプルのソースコードは1つか2つなので、並列ビルドの必要性は小さいだろう。

MinGW-w64/MSYS2

基本的には ./configure && make で行ける。下の「Unix 編」も参照。

注意として、 MSYSTEM 環境変数が正しく設定されてないと、環境の判定に失敗する。uname の出力が MINGW64_NT-10.0 みたいな感じなら大丈夫なはず。

スタートメニューの MinGW-w64 Win** Shell みたいなやつから起動していれば MSYSTEM 環境変数は問題ないが、 SSH で MSYS2 にログインしているとかだと問題になるかも。

Unix 編

./configure && make で行ける。ただし、 wxWidgets のソースコードと同じ場所で ./configure するのではなくて、別の場所から path-to-wx/configure みたいな感じでビルドした方がいいだろう。

独断と偏見で選ぶ、めぼしい configure オプション:

• --enable-debug: デバッグビルド。
• --enable-monolithic: wxWidgets を単一の巨大なライブラリとしてビルドする。デフォルトでは、コンポーネントごとに別のライブラリとしてビルドされる。
• --disable-shared: スタティックライブラリとしてビルドする。デフォルトでは、共有ライブラリとなる。
• --enable-cxx11: 最近追加された。-std=gnu++11 みたいなのをコンパイラに渡してくれる。
• --enable-utf8: wxString の実装に UTF-8 文字列を使う。UTF-8 ビルド。
  • UTF-8 ビルドであろうが通常の Unicode (wchar_t) ビルドであろうが、 wxString は wchar_t の配列っぽく振る舞う。指定しない場合は、 wxString は文字列を std::wstring で保持する（Windows だと UTF-16, それ以外だと UTF-32）
  • UTF-8 ビルドのメリットは、 GTK+ 等のバックエンドと文字列をやりとりする際に文字列を変換しなくて済むこと。デメリットは添字でループを回すコードのパフォーマンスが低下すること（添字でなくてイテレーターを使えばそんなに問題にはならないはず）。
• --with-gtk: 使用する GTK+ のバージョンを指定できる。デフォルトでは GTK+ 2 系が使われるが、wxWidgets 3.0 で GTK+ 3 系に対応した。
• 余談： --with-osx_cocoa: OS X でのバックエンドとして Cocoa を使う。
  • wxWidgets 2.8 の頃は OS X でのバックエンドとして Carbon （懐かしい響き！）を使っていたが、wxWidgets 3.0 で Cocoa バックエンドが実装された（configure で Carbon バックエンドと Cocoa バックエンドを切り替えられる）。
  • 現時点の開発版(3.1)では Carbon バックエンドは削除された。

これで wxWidgets をいじくる準備は整った。さあ、君も wxWidgets の開発に貢献しよう！（？？？）