wxWidgetsをWindowsで使う

鷺澤伸介
（初稿 2026.4.7）
（最終改訂 2026.4.7）

Visual StudioやMSYS2を使わずに、WindowsにwxWidgetsを「直（じか）に」インストールするための覚え書きです。
wxWidgetsをWindowsにインストールする
バイナリ版は古いコンパイラ用？
MSYS2での導入は簡単お手軽だが……
PB氏によるスタートガイド（無難だが問題もあり）
推奨：CMakeとNinjaを使う方法（ただし問題もあり）

wxWidgetsをWindowsにインストールする

Visual StudioやMSYS2などの開発環境を導入することなく、Windowsに「直に」wxWidgetsをインストールするための方法について調べてみたところ、びっくりするほど情報が少ないことが分かりました。公式サイトにはもちろんWindows向けのインストールガイドがあるのですけれども、どこであれ公式サイトの説明というものはどうにも分かりにくい傾向があって、wxWidgetsの場合も例外ではありません（英語なのも面倒です）。wxWidgetsのインストールは、環境がWindowsだろうとLinuxだろうとmacOSだろうと、ソースコードからビルドするのが基本なようで、その点では非常に敷居が高いと言えるでしょう。ともあれ、本稿は、「アーカイバとかテキストエディタとかコンパイラとか、まずはそういう最低限のツールだけでWindows版wxWidgetsを使ってみたいんだが？開発環境との依存関係がないのなら、アンインストールはwxWidgetsのフォルダを捨てるだけだから楽だろうし」という人（私がまさにこのタイプです）向けの内容です。

バイナリ版は古いコンパイラ用？

私は使ったことがないので詳しいことは書けませんが、Windows用にはビルド済のバイナリ版も配布されています。バイナリ版ならダウンロードして展開すればすぐに使うことができますから、これが最も容易な導入方法であることは確かです。ただし、そのリストを見ると、古いバージョンのコンパイラ用のものばかりが並んでおり、またVisual Studio用やMinGW用のものはありますが、Clang用のものは見当たらないようです。ということは、バイナリ版は、導入がお手軽である反面ユーザーが限られる、ということになるでしょう。古いVisual StudioやMinGWを使っている人は、まずはバイナリ版のダウンロードリストを確認してみて、自分のコンパイラのバージョンで使えそうなら導入すればよいと思います。

MSYS2での導入は簡単お手軽だが……

「CDデータベース制作覚え書き」のページにも書いたように、私はwxWidgetsについてはMSYS2パッケージ版を使うことが多い。MSYS2のGCC用とClang用二つのwxWidgetsパッケージ版をインストールするためには、msys2.exeを起動して次のpacmanコマンドを打つだけです。
★私がこれを書くために、新たにWindows11にインストールしたMSYS2のコンパイラとwxWidgetsのバージョンは、GCC：15.2.0、Clang：22.1.2、wxWidgets：3.2.10でした。MSYS2のMinGW用wxWidgetsは公式でも少し古いバイナリ版が配布されていますが、MSYS2リポジトリにあるものはほぼ最新のwxWidgetsとなっています。Hello Worldサンプルコードでビルドしてみたところ、すべてビルドは成功しましたが、Clangの共有版だけは大量の「-Wignored-attributes」警告フラグが出て、たいへんウザい思いをしました。Clangの静的版の方は何事もなく終わったというのに。まあ警告が出るだけでビルドはできるので、この警告を抑制する「-Wno-ignored-attributes」フラグをくっつけてビルドすればウザい思いはしなくて済むものの、原因はいったいどこにあるのでしょう？あまり共有版でビルドしないので印象に残りにくいのですけれども、以前古いPCにインストールしたMSYS2でもこの現象が見られた気がします。
PCスペックや通信の環境・混雑状況にもよるでしょうけれど、これ全部やってもたぶん5分もかからないと思います（私は2分40秒で終わりました）。私がwxWidgetsのパッケージ（MinGW用）を初めてインストールしたときは、確か2分かそこらで終わってしまって拍子抜けした覚えがあります。その前、いちばん最初にwxWidgetsをインストールしたときは、MSYS2を使ったとはいえソースからビルドするという標準的な方法で行ったのですが、makeに30分以上もかかってちょっと閉口した記憶があって、パッケージ版もそれくらいかかるのではないかと身構えていたのです。結局、MinGW用とClang用二つのwxWidgetsパッケージのインストールは5分くらいであっけなく完了し、しかもどちらも（少なくとも静的版に限れば）まったく問題なく使うことができましたから、初めてWindowsでwxWidgetsを使ってみようと思う人には、MSYS2のパッケージ版を導入することを「わりと強く」推奨したいと思います。Windowsに直にインストールする方法の説明がネット上にあまりたくさん見つからないのは、MSYS2での導入があまりにも簡単だからということが原因の一つになっているのではないかという気がします。まあ「WindowsならVisual Studioで使いましょう」ということなのかもしれませんが。
wxWidgetsには、共有ライブラリDebug版・共有ライブラリRelease版・静的ライブラリDebug版・静的ライブラリRelease版の4種類のキットがあり、それぞれは別々にビルド＆インストールする必要があります。MSYS2のwxWidgetsパッケージの中身は、どうやらRelease版に限られているらしく、Debug版は同梱されていないようです。また、ビルド済のセットですから、インストールは部品をコピーするだけで時間がかからない反面、Configで細かく設定をいじることは当然できません。そうなると、MSYS2のパッケージは、「導入はむちゃくちゃ楽だけれども自由度はないキットである」ということになるでしょうか。
★もっとも、wxWidgetsのConfig項目は数が多いため、パッケージ作成者に「これがいいよ」と決めてもらった方が楽だと考える人も多いでしょう。私なんかもその口です。
★MSYS2パッケージ版で、ターミナル直打ちでwxWidgetsアプリをビルドする場合は、
g++ hello.cpp `wx-config --cppflags --libs`
g++ hello.cpp `wx-config-static --cppflags --libs` -static
と、わずかに書き換えるだけで共有/静的を切り換えることができます。

PB氏によるスタートガイド（無難だが問題もあり）

英語ですが、MinGWを使用して、WindowsにwxWidgetsならびにCode::Blocks（フリーのIDEです）をインストールするための、おそらく最も標準的な方法を解説したpdfドキュメントがGitHubに上がっています。初版が2020年6月とけっこう新しいプロジェクトで、現在でも更新されているようです（これを書いている2026年4月段階での最新版は2025年5月2日更新版）。タイトルは『PB's Guide to Starting with wxWidgets on Microsoft Windows with MinGW and Code::Blocks』（MinGWとCode::Blocksを使ってMicrosoft Windows上でwxWidgetsを始めるためのPBによるガイド）。wxWidgetsをソースからビルドして使えるようにする方法だけでなく、wxWidgetsそのものに対する説明も豊富に含まれていますので、本体ビルドにこの文書の方法を使うか否かにかかわらず、wxWidgetsを使おうと思う人は一度は目を通しておくとよいでしょう。この解説のとおりにやればまずたいていは成功すると思いますし、実際私も以前のPCで成功したのですが、ちょっと気になる点もありました。
1. wxWidgetsを使ったプログラムのビルド方法がよく分からないこと
……wxWidgets自体はC/C++コンパイラだけあればセッティング可能です。ただし、このガイドはCode::Blocksのインストールを前提としているため、wxWidgets本体をインストールした後、それを使ったプログラムのビルドについてはCode::Blocksを使ってやってくださいということになっており、wxWidgetsだけをインストールした状態での自作プログラムのビルド方法については説明がありません。
2. Clangでのセットアップ方法の説明がないこと
……以前と違って、今はWindowsでもClangが導入しやすくなっているので、Clangを使って環境を構築したいと思う人もいるでしょう。wxWidgetsは、Windows上でコンパイラにClangを使ってセットアップすることもできますし、セットアップ用のCMakeListsの中を見るとClangが使われた場合の選択肢もちゃんと用意されています。ところが、Windows用のビルドフォルダであるbuild\mswの中には、「gcc」と「vc」をファイル名に含んだ2種類ずつのConfigファイルとmakefileしかなく、「clang」を含んだそれらは見当たりません。PB氏のスタートガイドではCMakeListsではなくmakefileの方を使っており、そのためこのガイドの方法では、wxWidgetsをDL＆展開（解凍）しただけではClangを使ってのビルドはできないということになります。makeでClang版をビルドしたければ、今のところは自分でClang用のmakefileを用意するしかありません。
3. ソースフォルダ自体の中にインストールした状態で使っていること
……DLして展開したwxWidgetsソースフォルダ自身の中にビルドして、そのまま使っているのもちょっと気になりました。付属のmakefileをオプションなしで実行するとそうなってしまうのでしょうが、生成物は別のフォルダに移し、ソースフォルダはできるだけ汚さずに残しておきたいような気がします。つまり、ソースフォルダ→（ビルド）→外の作業フォルダ→（インストール）→外のインストールフォルダ、という感じで、私としてはそれぞれのステップの生成物が混じらないようにしたいところです。
リポジトリにはガイドブックだけでなく、一連のインストールコマンドを記したバッチファイルもアップされていますから、そこから必要なものを取ってきて自分の好みに合うように書き換えてから実行するようにすれば、楽に作業が進められるでしょう。PB氏が最小限構成に付け加えているのはCXXFLAGS="-std=c++20"（C++20を標準とする）くらいです。また、並列処理のパラメーター「-j4」を設定していて、そのため処理速度が大幅にアップすることが期待されます。ただ、これは公式サイトにも説明されているのですが、並列処理についてはmakefileに修復不可能なバグがあり、それを避けるためには、1回目はコマンドの末尾に「setup_h」と書いてそれをターゲットとして実行し、2回目はそれを消して実行するように、とのことです。このバグの分、インストールには余計に時間が取られることになります。しかし、私が以前やってみたところでは、4種全部セットアップしても計45分くらいで終わりましたし、2026年のPCならもっと早く終わるはずです。私はPB氏が書いた「-j4」のまま書き換えずにやりましたが、マシンのコア数に応じて数字を増やしてもよいでしょう。

推奨：CMakeとNinjaを使う方法（ただし問題もあり）

PB氏のスタートガイドとバッチファイルがあれば、MinGW用のセットアップはできます。しかし、Clang用のセットアップができないのはどうにももの足りません。そこへいくと、wxWidgets付属のCMakeListsを使ったセットアップならClang版もインストールできますし、公式もWindows用のセットアップではバイナリ版の次にこの方法を挙げていますから、2026年春現在ではこれが事実上のデファクトスタンダードなのでしょう（「Installing wxWidgets for Windows」のページ、CMakeを使う場合は「CMake Overview」のページに行くよう促される）。ここでは、CMakeとNinjaを使ったセットアップについて書いてみたいと思います。
私の環境（＝本稿での事実上の環境条件）……Cドライブ直下に
の各フォルダを置き、上から三つ目までのフォルダ内のbinフォルダにはいずれもパスを通してあります。Ninjaについては、専用のフォルダに入れておいてもよいのですが、CMakeフォルダの中に放り込んでおけばNinja専用のパスを通す必要がなくなるので、そのようにしてあります。↓
CMakeフォルダ内のNinja
★Windows用のソースアーカイヴは、zip、7z、installerと3種類が用意されています。このうちinstaller版は、「バイナリは入っていません」と注意書きがあるようにソースファイルの自己解凍（展開）形式版にすぎず、それなのに捨てるときはコンパネからアンインストール操作をする必要があります。確か、zip版や7z版と違ってヘルプファイルが同梱されていたような気がしますが、そのヘルプの内容はネット上ですべて読むことができたと思います。となると、zip版か7z版のどちらかをDLすることになりますが、特にこだわりがなければより圧縮率の高い（＝ファイルサイズが小さい）7z版を選ぶのがよいでしょう。
★どうでもいい話題。WikiでもAIでも、MinGWは「開発環境」であると説明されていますが、当のAIに「MSYS2などとの抱き合わせならともかく、MinGW単独なら『ツールチェーン』ではないのか？」と尋ねたところ、「そのとおり、厳密には『ツールチェーン』が正しい」と言っていました。「だったら今後はあらためるのか？」と尋ねたら、「あらためます」ですって。本当かなあｗ。AIは調子がいいですからね。
wxWidgets公式サイトの「CMake Overview」のページを確認すると、先にGUI操作が説明されているので、それに従います。cmake-gui.exeならConfig項目がずらっと表示され、何が設定できるのかがよく分かるので便利です。公式の説明（英語）は、
  1. CMake GUIを起動します。
  2. ソースフォルダとしてwxWidgetsのルートを指定します。
  3. ビルドファイルが生成されるべきパスを指定します。wxWidgetsのルートフォルダ以外のパスを使うことが推奨されます。
  4. 「Configure」ボタンを押すと、あなたが使いたいIDEまたはビルドシステムはどれかと尋ねられるでしょう。
  5. 必要に応じて：オプションをカスタマイズします。
  6. 「Generate」ボタンを押します。
  7. お好きなIDEでwxWidgetsプロジェクトを開きます。
となっています。CMakeの使用上の注意としてよく言われているように、ここでもビルドフォルダ（作業用中間ファイル格納フォルダ）はルートフォルダ以外のフォルダを指定するようにと注意されていますね。ここではとりあえずMinGWの静的ライブラリRelease版を作り、次にClang用の同じものを作ることにします。MSYS2ではそれしか使ってこなかったので、正直私はそれだけあれば事足りるのですが、本来は上にも書いたように、共有ライブラリDebug版・共有ライブラリRelease版・静的ライブラリDebug版・静的ライブラリRelease版と4種類作っておくべきなのかもしれません。さらに、MinGWとClangの2種類のコンパイラを使うのなら、全部で8種類のキットを作ることになります。まあ静的ライブラリRelease版がうまく行ったら、それにプラスして共有ライブラリRelease版くらいは入れておいてもよいかもしれません。MSYS2のパッケージでも静的・共有両方のRelease版が入りますしね。
★AIによると、wxWidgetsでDebug版までビルド＆インストールする人は稀なのだとか。AIが言うことなので嘘か本当かは何とも言えませんが、少なくともChatGPT、Gemini、Claudeは同じような回答だったので、必ずしもハルシネーションというわけでもないのかもしれません。Copilot？押し付けがましいので使ってませんｗ。
★それにしても、wxWidgetsのインストールに関しては、AIにはけっこう嘘をつかれましたねえｗ。しかも複数のAIに。Windowsに直にインストールする方法だけでなく、何とMSYS2に導入する方法でも同じでした（パッケージ名の間違いや、Clangコンパイラ──mingw-w64-clang-x86_64-clangとmingw-w64-ucrt-x86_64-clangの2種類がある──の混乱など）。「それじゃこのpacmanコマンドでとりあえずインストールするわ」「パッケージ名が違います。こうです」「はあ？MSYS2パッケージ・サーチからコピペしたんだけど……そんなパッケージ名、検索してもヒットしないぞ？」「おっしゃる通りです。ここはあなたの方が正確です」「おいこら！」とまあ、こんな感じ。まったく……ｗ。結局、どちらのインストール方法も、私が公式サイトその他で情報を集めながら進めた方法がいちばん正確だったというオチとなりました。AIにいくつか嘘を教えられたせいで、今書いたような検証の機会が発生し、余計に時間がかかってしまいました。……AIって、複雑なタスクを難なくやってのけるかと思うと、むちゃくちゃ基本的なことを間違えることもあって、私にはまだまだ上手に使いこなせる気がしません。まあでも、そういうのも面白いと言えば面白いし、私が気づかなったことに気づかせてくれた場面もありましたから、今後もAIには、適度に距離を置きながら、面倒なタスクを手伝ってもらおうと思っています。
★外国語の読解では、すべて鵜呑みにはできないけれども、AIはかなり役に立ってくれています。ネット機械翻訳とは違って、「AIさんのここの訳、分かりにくいんだけど？」「ああ、そこはこういう意味です。確かに言葉が足りませんね」とか、「ここはこういう意味じゃないの？」「違います。逆です」「そんな用法、辞書に載ってたかなあ？」「少し古い言い回しかもしれませんが、ありますよ」「ふ～ん。まあ文脈的にはそうじゃないと通らないしねえ」「納得していただけましたか！」とか、こんな具合に対話しながら進められるのが素晴らしい。
とりあえず今は、Cドライブ直下に次のようなフォルダを作って作業するものとします。
wxw
├─ wxwg  // MinGW用インストールフォルダ。
├─ wxwc  // Clang用インストールフォルダ。
├─ wxwg_build  // MinGW用作業フォルダ。
└─ wxwc_build  // Clang用作業フォルダ。
wxWidgets-3.2.10  // ソースフォルダ。

CMakeとNinjaを使ったwxWidgetsインストール手順

①cmake-gui.exeを起動して、ソースフォルダとビルドフォルダを指定してから「Configure」ボタンを押します。ビルドフォルダは、「Configure」ボタンを押したときに存在しなければ「ないので作りますか？」と尋ねてくるので、「Yes」を押します。
──今回の場合は、「Grouped」と「Advanced」はどちらもチェックを外しておいた方がよいでしょう。
CMake操作1
CMake操作2
②ジェネレーターを指定するパネルが現れるので、プルダウンから「Ninja」を選びます。その下のラジオボタンは、環境にコンパイラが複数存在する場合は2番目の「Specify native compilers」を選び、次の画面で現在使いたいコンパイラのパスを入力します。
CMake操作3
──MinGWの場合は下図のようになります。コンパイラのbinフォルダ内には似たようなファイルがたくさんあるので、間違えないように気をつけましょう。
CMake操作4
③「Finish」ボタンを押すと、元の画面に戻ってConfigureが始まります。終わると下の画像のようになるはずです。この例では35秒かかっていますね。今回は「Advanced（詳細な、高度な）」のチェックを外しているので、表示される項目が厳選されて選びやすくなっています。
──「Grouped」と「Advanced」のチェックを入れるとどうなるのかは、チェックを入れたり外したりしてご確認ください。最初のConfigが終わったこのタイミングなら、この二つのチェックの効果が分かります。まあ「文字どおり」なんですけれどもねｗ。
CMake操作5
表示されている項目のうち、次の3項目を変更します。
★CMAKE_BUILD_TYPEは、Debug版を入れる場合は、たぶんデフォルトがDebugですのでそのままにします。CMAKE_INSTALL_PREFIXは、デフォルトは「C:\Program Files (x86)/wxWidgets」フォルダですが、Program Filesだと管理者権限がどうのこうのと言われる可能性がありますので、ここではよりシンプルなパスのフォルダに変更しています。wxBUILD_SHAREDは「共有（ライブラリ）ビルド」の意で、対義語は「静的（ライブラリ）ビルド」となります。ここでは静的リンク実行ファイル（dllなど外部パーツを同梱しなくても、単独で起動できるexeファイル）が作れるようにしたいので、チェックを外します。それと、私は変更しませんが、もし上のPB氏と同じようにC++20を標準にしたければ、wxBUILD_CXX_STANDARDの値「COMPILER_DEFAULT」をクリックするとプルダウンから選べます。……COMPILER_DEFAULTは、__cplusplusの値をcoutで表示させてみたところ、MinGW15.2.0とClang22.1.1ではともに「201703」でしたから、C++17が標準ということになります。
C++標準選択
④もう一度「Configure」ボタンを押します。すると赤色が消えて、変更が反映されます。
──もしさらに変更したければ、変更→Configureを繰り返してください。
CMake操作6
★wxBUILD_MONOLITHICは、ご覧のようにデフォルトでオフになっています。今は静的ライブラリ版をビルドしているところなのであまり関係ないと思いますが、これは要するにたくさんあるdllを単体にマージする機能です。「dllが少なくなるなら散らかった感じにならなくていいじゃん」と思う人もいるでしょうし、私も共有ライブラリ版をビルドするときにこれにチェックを入れるかどうかちょっと迷ったのですが、PB氏は上のガイドで、「Monolithicビルドを使う大きな利点は一つも思いつかないので、デフォルトのMultilibビルドにこだわることをお勧めし、このガイドではこのビルドを使うことにします」と書いていました。
⑤正しく設定されたら、「Generate」ボタンを押します。Ninjaファイルが一瞬で作られます。cmake-gui.exeを使うのはここまでです。
★「Generate」ボタンを押したかどうかは、下のペインを見れば分かります。
Generate記録
⑥作業フォルダ「C:\wxw\wxwg_build」を開き、そのフォルダを起点としたPowerShellまたはコマンドプロンプトを起動します。Windows11なら、フォルダ内の余白を右クリックして「ターミナルで開く」を選ぶとよいでしょう。旧来どおりフォルダのアドレスバーに「cmd」または「pwsh」（古いPowerShellの場合は「powershell」）と入力した後にEnterを押して起動してもOK。
★PowerShellにしてもコマンドプロンプトにしても、文字コードを65001（utf-8）にしておいた方がよいかもしれません。「chcp」で確認、「chcp 65001」で変更、「chcp 932」で元に戻せます（932はShift-JIS）。
⑦「ninja」と入力してEnterを押します。ビルドが始まります。
CMake操作7
──ご覧のように、かなり大量の警告が出つつも、2分もかからず終了すると思われます（私の環境では80秒くらいでした）。Ninjaは確かに速い。ここまでの作業は、テキパキやればたぶん5分かそこらで終えることができるでしょう。これだけ速ければインストール作業がさほど負担にならないので、失敗してもあまりめげずに済みそうです。
──運がよければ、PCは976ステップの処理を最後までノンストップで駆け抜けてくれるでしょうが、場合によっては途中で止まってしまうこともあるかもしれません。もし止まったとしても、そこで諦めることなく、「ninja」コマンドを再実行してみてください。おそらく止まった地点から何事もなかったかのように再スタートすると思われます。私が以前のPCでインストール作業を何度か試していた間では、多いときは4～5回止まったものですが、そのたびに再開して、最終的に完了できれば特に問題はないようでした。
⑧「ninja install」と打ち込んでEnterを押します。すると生成物のうち必要なもののみが、Config時に設定したインストールフォルダ（今回はC:/wxw/wxwg）にコピーされます。これはあっという間に終わります。
CMake操作8
以上でインストール作業はひとまず終了です。お疲れさまでした！
★作業フォルダのwxwg_buildは3.5GBくらいあるのに対し、インストールフォルダのwxwgはわずか90MBくらいです。この作業フォルダは今後も使う可能性があるので、このままにしておきましょう。
★それにしても、cmake-gui.exeは文字が小さすぎると思いませんか？Windows11ではさらに文字色が薄くもなりましたし。この大きさはさすがに老眼泣かせです。「cmake gui font size small」などのキーワードでググるとけっこうヒットするので、外国にも同じように感じている人が一定数いることが分かります。ネット上にはこの話題についてのかなり昔の投稿も見つかるというのに、2026年現在でも文字は小さいままです。もしかして、開発者は「GUIが見づらいのならばCUIでやれば？」とでも考えているのでしょうか？

CMakeとNinjaを使ったwxWidgetsアプリのビルド──問題とその対策

次に、今インストールしたwxWidgetsの試用を兼ねて、このツール用に書いたプログラムをビルドする方法について書いてみます。上のPB氏のガイドでは、「Code::Blocksを使ってビルドしましょう」ということになっていました。なるほどCode::BlocksならDebug版とRelease版を切り換えるのも楽だし、共有ライブラリ版ではちゃんと実行ファイルとdllをリンクしてくれるしで、便利であることは確かです。しかし、今回はとにかく最低限のツールだけでWindows版wxWidgetsに触るというのがテーマですから、wxWidgetsだけのためにCode::Blocksのような決して小さくもシンプルでもないIDEを導入するわけにはいきません。
★wxWidgetsの場合、共有ライブラリ版は、ビルドに成功して実行ファイルを起動しても、下のようなアラートが続けざまに出て起動できないのが普通です。PB氏のガイドでもこれは説明されています。
共有ライブラリビルド起動エラー1 共有ライブラリビルド起動エラー2
wxbase32ud_gcc_custom.dllとwxmsw32ud_core_gcc_custom.dllは、libフォルダ内の、「gcc_x64_dll」などの「_dll」で終わる名前のフォルダの中にありますので、それを実行ファイルと同じフォルダにコピペすれば起動できるようになります。また、ソースファイルのフォルダをカレントとして、そこからbuild/a.exeとかコマンドを打って起動させるのなら、実行ファイルではなくソースファイルと同じ階層に置いてもたぶん大丈夫です（Windowsは、必要なファイルが実行ファイルのフォルダ内になければ、次にカレントフォルダ内を検索するから）。CMake処理での実行ファイルは通常build用フォルダの中に生成されますが、build用フォルダは時々全部捨ててやり直すことがあって、そうなるとせっかくその中にコピペしたdllファイルも一緒に捨てることになりますから、dllファイルはソースファイルのフォルダに入れておき、実行ファイルはそこからコマンドで起動する方がよいと思います。ただし、ダブルクリックで起動する場合は、実行ファイルのあるフォルダがカレントにならざるを得ないので、そこにdllを置いておくしかありません。なお、上の画像の例では「32ud」と数字の後に ud が続いていますが、これはDebug用のライブラリで、Release用では「32u」と d が付かず u のみになります。
これがMSYS2やLinuxなどのUNIX系の環境なら、wx-configが使えるので「g++ hello.cpp `wx-config --cppflags --libs`」みたいな短いコマンドでビルドすることもできるのですが、Windows直置き版ではこの手は使えないようです。公式の「Installing wxWidgets」ページのBuilding Your Applicationの項には、まず「CMakeを使う場合」が書いてあり、Windowsだとあとは「Visual Studioを使う方法がある」くらいしか書いてありません。また、「Installing wxWidgets for Windows」のページでは、後半のBuilding Applications Using wxWidgetsの項に、やはりまず「CMakeを使う場合」があって、その後に「Using MSVS」「Using Other Compilers or Command Line」と説明が続きます。で、その「CMakeを使う場合」の説明は、「CMake Overview」ページの後半、Using CMake with your applicationsの項に書いてあります（前半は上でも参照したwxWidgets本体のビルド方法）。ただし、詳細はCMake公式のFindwxWidgets（モジュール名です）のページを参照せよとのこと。とにかくここでは本体のビルド＆インストール同様、CMakeを使う方法で進めることにしましょう。
CMakeの便利さについてはまずまず分かっているつもりです。CMakeListsの書き方さえ理解してしまえば、makeとかNinjaとか複数のビルドツール用のスクリプトが出力できて、しかも見た感じmakefileよりもかなり簡潔に書けるようです。ただし、書法や挙動が独特な部分もあって、C/C++、あるいはそれを利用するwxWidgetsなどのローカル言語とは別に、さらにCMake用の勉強が必要になるということですから、面倒くさくて、これまでそんなに積極的に使おうとは思わなかったのです。だいたい、私程度の初歩的なアプリ開発においては、上記のようなターミナル直打ちビルドで十分でしたしね。
まずはwxWidgetsとCMakeのコードが必要ですので、公式サイトから入手します。Hello World Exampleのページ（2026年4月現在、公式のトップページのリンクから行けます）のいちばん下、「Here is the entire program that can be copied and pasted:」と書いてあるその下の行から最後までをコピーしてテキストファイルに貼り付け、ファイル名を「wxhello.cpp」として適当なフォルダを作って保存します（私はCドライブ直下に「wxtest01」というフォルダを作ってそこに入れました）。次に、CMake公式の「FindwxWidgets」ページにある「Example: Using Variables」から下の記載例をコピーしてテキストファイルに貼り、「CMakeLists.txt」という名前で今作ったcppファイルと同じフォルダに保存します。CMakeの方は、wxWidgets公式の「CMake Overview」のページにある使用例を使ってもよいのですが、それよりも本家本元の方が安全だろうと判断しました。
★wxWidgets用のcppファイルの名前は適当でかまいませんが、CMake用のテキストファイルは必ず「CMakeLists.txt」という名前でなければなりません。
wxWidgets公式のHello World（途中まで）
CMake公式のFindwxWidgets使用例（不足あり）
wxWidgets公式謹製のサンプルコードには特に手を入れなくてもよさそうですが、CMakeの方はこのままでは使えません。コメントに、「MinGWユーザーは、ライブラリの順番が重要であることに注意してください」「また、プロジェクト固有の実行可能ファイル/ライブラリのターゲットそれぞれについても（同様です）」と書いてありますね。gl core base netという4種類のライブラリをこの順で書くべし、ということでしょうか？ ともあれ、これは公式が書いた使用例なのだから、このままの並び順なら問題は出ないでしょう。なお、glとはOpenGLサポートのことだそうです。
★wxWidgetsの方のCMakeサンプルコードは find_package(wxWidgets REQUIRED COMPONENTS net core base) となっています。netがcore baseよりも先に書いてあるけれど、これでも大丈夫なのでしょうか？
それでは、上のCMakeListsに少し手を入れて使えるようにしてみます。コメントは消しておきます。また、COMPONENTSは、何も指定しない場合はcoreとbaseを検索するそうで、この二つが必須なのでしょう。たぶんfind_package(wxWidgets)だけでもたいていはいけると思うのですが、ここではCMake公式の真似をしてCOMPONENTSをくっつけておきます。
テスト用CMakeLists
これで準備ができましたので、いよいよビルドします。現在、wxtest01フォルダの中には、「CMakeLists.txt」「wxhello.cpp」の二つのファイルがある状態です。wxtest01フォルダからコマンドプロンプトまたはPowerShell、いずれかのシェルを開き、次のCMakeコマンドを打ってEnterを押します。
「-S .」は「ビルドするプロジェクトのルートフォルダはここ［.］」の意、「-B build」は「ビルドに使う作業フォルダ名は［build］、なければ作る」の意、「-G Ninja」は「ビルドに使うジェネレーターにはNinjaを使う」の意です。CMakeのコマンドライン入力は、オプションの後のスペースを省略してもよいので（例：「-S.」「-Bbuild」「-GNinja」）、その方が一般的らしいですが、ここでは分かりやすいようにスペースを空けておきます。これでEnterを押すと、次のように表示されました。
Configが一見成功したように見えるので、次に
と打って、CMakeを通じてNinjaにbuildを命じると、
失敗してしまいましたね。「wx/wx.hが見つからない」と言っています。Configの段階でも、よく見ると下の方に「Could NOT find wxWidgets (missing: wxWidgets_LIBRARIES wxWidgets_INCLUDE_DIRS)」と表示されていました。wxWidgetsのライブラリとインクルードのフォルダが見つからなかった、と。wxWidgetsのルートフォルダは、CMakeLists内に「set(wxWidgets_ROOT_DIR "C:/wxw/wxwg")」とちゃんと指定しておいたのに、それでも見つからないとはこれいかに？
実はこの問題、ネットで検索すると、英語のサイトばかりですがわりとたくさんヒットします。ところが、私の探し方が甘いのか、決定的な解決策のようなものは探し当てられませんでした。情報として確かなのは「FindwxWidgets.cmakeに不具合がある」ということで、それを捨てて動かす方法を説明してくれている人もいましたが（Stack Overflowの「Cmake Could not find wxWigets」）、FindwxWidgets.cmakeのどこに問題があるのかは分からないままでした。そのFindwxWidgets.cmakeを使わない方法を、今扱っているHello Worldプログラムで試してみたところ、あっけなくビルドに成功しました。ところが、ClangでビルドしたwxWidgetsを指定してみると、エラーが出てうまくいきません。
★FindwxWidgets.cmakeというのは、たくさんあるCMakeのモジュールの一つで、環境にwxWidgetsがあるかどうかを探し、見つかったら各種変数を設定してくれるという便利ツールです。
Clangでビルドできないのでは、MSYS2パッケージ版に戻った方がマシということになってしまいます。この方法は不採用とし、それよりもFindwxWidgets.cmakeの不具合箇所を探ることにしました。そちらはClangどころかMinGWでもビルドできないのですが、不具合箇所を特定して対策することができれば、もしかするとMinGWでもClangでも処理できるようになるかもしれません。……実は、前のWindows10PCで、上のPB氏のガイドに従ってビルドした方、すなわちmakeでビルドしたwxWidgetsは、CMake＆NinjaでHello Worldを試したところ、特に問題なくビルドできていたのです。いったい何が違うのか、と思いつつ、両方のインストールフォルダを開いてみたら、一発で原因が分かってしまいました。make版とCMake＆Ninja版とで、ライブラリフォルダの名前が違っていたのです。
makeでビルドした方のフォルダ名には「_x64」が付きません。そちらならビルドに成功するということになると、FindwxWidgets.cmakeはどうやら「_x64」が付かない名前でターゲットを検索しているらしい。それなら、検索対象をセットしている部分を見つけて「_x64」を加えてしまえばうまくいくかもしれない。もしFindwxWidgets.cmakeの書き換えが無理そうなら、いろいろ齟齬が出そうであまりやりたくはないが、フォルダ名の方を変更してみよう。──とまあそんなふうに考えて、FindwxWidgets.cmakeの中の書き換え対象箇所を探してみることにしたのでした。
★「Installing wxWidgets for Windows」ページのBuilding Applications Using wxWidgets → Using Other Compilers or Command Lineの項の説明の中には、今問題となっているライブラリフォルダ名の「_x64」に言及している部分があります。これは「MSVS以外のコンパイラでは使用されない」と書いてありますが、実際は、CMakeで本体をビルドすると、PCが64ビットであるならば、MinGWでもClangでもライブラリフォルダ名に「_x64」が付いてしまいます。
cmake/share/cmake-4.3/Modulesフォルダ内にあるFindwxWidgets.cmakeをテキストエディタで開き、「gcc」で検索をかけてみると、たった一箇所だけヒットします。そこに跳んで見てみると、前後に「MINGW」「MSVC」「vc」などの名前が見え、MSVCの条件分岐ブロック内には「_x64」を変数に代入している部分が見つかります。どうやらこのあたりが検索ターゲットを設定している箇所で間違いなさそうです。「_x64」はなぜかMSVCの条件分岐内にしか設定されていませんが、その処理をMSVCだけでなくMinGWにも利くようにしてやればいけるのではないかと思いました。そこで、まずFindwxWidgets.cmakeをコピーして一方のファイル名を「FindwxWidgets_org.cmake」と変え、こちらはいつでも戻れるように触らないことに決め、もう一方を「FindwxWidgets.cmake」と正式名称にして、それをエディタで開き、683行目（CMake4.3の場合）から後を次のように書き換えました。
FindwxWidgets.cmakeのカスタマイズ①
★「if(CMAKE_SIZEOF_VOID_P EQUAL 8)」というのは、「もしボイドポインタのサイズが8と等しければ」の意味です。64ビット = 8バイトです。
この内容でFindwxWidgets.cmakeを保存して、上の「テスト用CMakeLists」を、同じように「cmake -S . -B build -G Ninja」で実行しました。すると、以下のように表示されました。
今度は「Found wxWidgets」となって、何やらファイルが読み込まれていますね。ではビルドしてみましょう。すると……
膨大な量のエラーが出て、またしても失敗してしまいました。実はこれ、wxWidgets3.2.9から発生するようになった新しい不具合なのです。私が調べたところでは、3.2.8.1までなら上の修正だけでうまくいくのですが、本稿で使っている3.2.10のようなそれより後のバージョンでは、CMakeが対応してくれない限りはこの不具合にも対処しなければなりません。
原因は、本体をビルドしたときに、3.2.9以降ではlibフォルダの中に新しく空のフォルダが作られるようになったことにあります。インストール先のフォルダを開き、その中のlib\gcc_x64_libフォルダを開いてみてください。この段階で下図のように「mswud」というフォルダができていたら、それも開いてみましょう。おそらく中は空だと思われます。もう一つの「mswu」の方を開いてみると、こちらにはwx/setup.hとbuild.cfgが入っているはずです。
3.2.9以降で生成される空のフォルダ
wxWidgets3.2.8.1までは、Release版をビルドしただけでは「mswud」フォルダは生成されませんでした。このフォルダはDebug版をビルド＆インストールしたときに初めて生成される仕様だったのです。FindwxWidgets.cmakeはその仕様に基づいて書かれていますので、この空のフォルダが存在すると上のようなエラーになってしまうようです。よって、対応策は次の三つになります。
★wxWidgets3.2.9以降対応のカスタマイズ★
上記のように、wxWidgets3.2.8.1以前のバージョンではこの不具合は起こりませんので、もしそれをお使いならこの対応策は不要です（すでにwxhelloのビルドに成功しているはず）。今はRelease版をビルド＆インストールしたところですが、もしDebug版を入れていたら、もう一つのフォルダ「mswu」の方が空になったはずです。どちらにしても空のフォルダが存在しているとまずいので、次の方策のいずれかを採ってください。
【方策1】空のフォルダを捨ててください。逆に、「mswu」または「mswud」フォルダが空ではなく、中にファイルやフォルダが入っていたら、その場合はそれらのフォルダは必要でビルドもできますので、捨ててはいけません。
【方策2】Debug版とRelease版を両方ともインストールすれば、これらのフォルダは空ではなくなりますので、静的キットなら静的キットで、共有キットなら共有キットで、Debug版とRelease版を両方とも入れるようにするのも解決法になります。
【方策3】FindwxWindows.cmakeの770行目あたり（CMake4.3の場合）に
とあるのに、
FindwxWidgets.cmakeのカスタマイズ⓪
と加筆するのも効果があると思われます。オリジナルはフォルダの存在だけを確認していますが（変数CFGには「mswu」などのフォルダ名が入る）、加筆した方は「中にwx/setup.hが入っているか」まで確認していますので、フォルダがあっても中が空なら処理対象外にできるはずです。
ここでは【方策3】を採用して進めたいと思います。上記のように対策して、あらためてConfigを実行してみます。
今回も「Found wxWidgets」となっていろいろファイルが読み込まれましたが、よく見ると、先ほどと違ってlibファイルがたくさん読み込まれています。どうやら成功のようです。続けて、やはりさっきと同じように「cmake --build build」と打ってNinjaによるビルドを実行します。今度はエラーにはなりません。それが終わったら、buildフォルダ内にできたa.exeを「build/a」（コマンドプロンプトの場合は「build\a」）で起動してみましょう。
Hello World 01
★ステータスバーが日本語になっていますが、これはもちろん私が書き換えたもので、wxWidgetsが勝手に翻訳してくれたわけではありませんｗ。原文は「Welcome to wxWidgets!」です。
というわけで、無事フォームを表示することができました。一安心といったところですが、実はもう一つ確かめておきたいことがあります。buildフォルダを開いて、今できた実行ファイルa.exeをコピーしてから、デスクトップでもどこでも任意の場所にペーストします。そしてそれをダブルクリックしてみましょう。
Hello World 02
「dllがないよ！」と文句を言われることもなく普通に起動しました。ちゃんと静的リンク実行ファイルになっているようです。ただ、ダブルクリックで起動した場合は、フォームの背後にコマンドプロンプトが出てしまっていますね。これはWindows GUIあるあるなのだそうで、-mwindowsというリンカオプションを付け加えることで抑制することができます。
テスト用CMakeLists（改1）
これでもう一度同じことを繰り返してみると、
Hello World 03
今度はコマンドプロンプトが起動することなく、フォームだけが現れました。

Clangを使ってwxWidgetsをインストールする

それでは、次にClangを使って同じことをしてみましょう。上の「CMakeとNinjaを使ったwxWidgetsインストール手順」を繰り返すだけですが、所々設定を変更する必要があります。
★本体のビルドは、Clangを使う方が警告が少ないし、速度も速いし、ビルド中の停止率も低いし、（静的ライブラリRelease版で）インストールフォルダの大きさも60MBほどとかなり小さくなるしで、MinGWよりもメリットが多いように思います。
無事インストールまで達したら、こちらもテストです。新しいテストフォルダは作らず、先のwxtest01を続けて使うことにします。CMakeListsのwxWidgets_ROOT_DIRを、今インストールしたフォルダに書き換えます。
テスト用CMakeLists（改1）フォルダ変更
これでCMakeコマンドを打つと……
またしても「wxWidgetsが見つからなかった」と言われてしまいました。まあでも、何となくこうなるんじゃないかという気はしていました。だって、さっきFindwxWidgets.cmakeを書き換えたとき、そこにはMINGWとMSVCしか条件分岐がなかったのですから。今インストールしたClang版wxWidgetsのlibフォルダ内を見ると、「clang_x64_lib」というフォルダが作られています（MinGW版では「gcc_x64_lib」でした）。つまり、FindwxWidgetsの検索ターゲットを「clang_x64_lib」にセットしない限り、FindwxWidgetsはwxWidgetsを決して探し当てることができないということです。
★これはwxWidgetsの不具合なのかCMakeの不具合なのか？まあ両方のせいですかねｗ。wxWidgetsは、makeを使った場合とCMakeを使った場合とで生成されるフォルダ名を統一するべきでしょう。CMakeの方は、FindwxWidgetsをClangにも対応させるべきです。
★ついでに、lib\clang_x64_libフォルダを開いて中を見てみてください。wxWidgets3.2.9以降をお使いなら、やはり「空のmswudフォルダ」ができていると思います。もし上の【方策1】を採っている場合は、このフォルダも捨ててください。本稿では【方策3】を採用していますので、ここでは何もしません。
FindwxWidgets.cmakeにClang用の選択肢を書き加えるのは、特に難しい作業ではありません。ただし、既存のコードの挙動を把握しておかないと沼にはまりかねないので、注意が必要です。先ほどの「FindwxWidgets.cmakeのカスタマイズ①」を再掲しますが、条件式の「if(MINGW)」に着目してください。これ、「現在MinGWを使っているか」の意味ではなくて、どうやら「環境内にMinGWが存在するか」を判定しているようなのです。「elseif(MSVC)」もおそらく同じです。
ゆえに、MinGWが入っている環境においては、条件式if(MINGW)が最初にあると必ずその条件節に入ることになるので、PCがClangなどほかのコンパイラを搭載していてそれを選びたくても、選びようがなくなってしまうのです。従って、もしClang用の分岐を加えるのなら、その条件節をif(MINGW)よりも前に出しておく必要があります。
分岐条件はシンプルに、「Clangを指定しているか否か」でよいのではないかと思います。CMakeListsの中で、Clangが使いたければCMAKE_CXX_COMPILERにclang++を指定し、それによって分岐するようにします。686行目から下記のように書き換え、念のためMSVC条件節は除外しておきます。CMakeの場合は「==」のような記号の演算子は使えないので、数値の場合は「EQUAL」、文字列の場合は「STREQUAL」と書かねばなりません。
FindwxWidgets.cmakeのカスタマイズ②
こうしておいて、CMakeListsに次のように加筆します。ちょっと問題のあるやり方なのですが、それについては後で触れます。
テスト用CMakeLists（改2）
これで準備OK。さあどうなるでしょうか？
今度は「Found wxWidgets」になりました。しかもちゃんとClangでインストールしたフォルダのlibファイルを探し当てていますね。もう成功の予感しかしませんが、確認のためにビルドしてから実行ファイルを起動しましょう。
CMake操作Clang版4
無事起動できました。画像の前面のパネルは、メニューのFile→Helloを選ぶか、またはCtrl+Hを押すと現れるインフォメーションです。日本語は私が書き加えたものです。今回生成された実行ファイルも、ストレージのどこにコピーしても単独で起動できます。しかし、今回の実行ファイルの方がファイルサイズがだいぶ小さくなっています。先にMinGWで作ったものは11MBくらいあったのですが、今回Clangで作ったものは7MBちょっとです。どちらも静的ライブラリRelease版でビルドしているはずなのに、ファイルサイズにこんなに差が出るとは。実行ファイルの起動も、Clang版の方が心持ち速いような気がします。私がwxWidgetsのセットアップでClang版にこだわるのは、こういうことがあるからなのです。本体のビルド＆インストールからして、ClangはMinGWよりも軽やかで、警告も少ない感じでしたしね。

共有ライブラリ版やDebug版もインストールしたくなったら？

ほかのキットもビルド＆インストールしたくなったら、cmake-gui.exeの設定を変えて上と同じやり方で進めればOKです。AIの言うことを信じるなら、よほどのwxWidgetsガチ勢以外はDebug版まで入れる必要はないような気がしますが、MSYS2のパッケージ同様、Release版の共有ライブラリ版キットくらいは入れておいてもよいかもしれません。作業するときは、MinGW用とClang用とで環境が入り混じらないように気をつけましょう。まあ失敗して最初からやり直すにしても、cmake-guiの設定（下記）にやや神経を使う必要があるものの、最近のPCならビルドの時間はあまりかからないと思うので、身構えず気楽に試してみればよいと思います。やり直す場合は、ビルド用フォルダとインストール先フォルダを捨てるだけですしね。
なお、本稿では、この後いろいろ切り換えの方法を説明しなければなりませんので、MinGW用もClang用もすべてのキットをあらためて「C:\wxwlab」というフォルダ内にビルド＆インストールしてから進めることにします。それぞれのコンパイラごとに四つずつ、全部で八つのキットをビルドすることになりましたが、たぶん15分もかからなかったと思います。全体のサイズは8GBくらい。ただ、もし「これ以上は触らないのでbuildフォルダは廃棄する」ということなら、本体は合計1.65GB程度と、MinGW用とClang用両方のフルキットがあるにしてはかなりコンパクトになります（Clang用だけなら700MBもありません）。テスト用のソースフォルダも新しく「C:\wxwlabtest01」を使います。ソースファイルは上で使った「wxhello.cpp」のコピーですが、メッセージをほんの少し書き換えました。
★最初のインストールフォルダ「C:\wxw」に追加してもよかったのですけれども、上記のようにwxWidgets3.2.9から新しい不具合というか、FindwxWidgets.cmakeとの齟齬が発生してしまいましたので、「C:\wxw」の方はその不具合が発生する状態で温存することにしました。もし追加ビルド＆インストールしてRelease版とDebug版が揃うと、その不具合は解消するのです（「mswu」「mswud」フォルダがどちらも空ではなくなるため）。そういうわけで、実験用に全キットをビルド＆インストールするのは別のフォルダにしました。

コンパイラ・ライブラリ・ビルドタイプを切り換えて使うには？

もしwxWidgetsのキットを複数インストールした場合は、それらの切り換え方法も知っておかねばなりません。本稿に従ってMinGW用静的ライブラリRelease版とClang用静的ライブラリRelease版をビルド＆インストールしたのなら、すでに複数のキットが存在していますので、それらを切り換えるための方法を決めておきましょう。
コンパイラ切り換えの場合、実は上で試したようなやり方は良くありません。コンパイラを切り換えたら、必ずConfigもやり直すべきだからです。上の「テスト用CMakeLists（改2）」でコンパイラを指定したCMake変数のCMAKE_C(XX)_COMPILERは「ノーマル変数」（その処理でのみ有効な変数）ですから、あのままでは同じ名前の「キャッシュ変数」（CMakeCache.txtというキャッシュファイルに記録されている永続的な変数）の方は書き換えられておらず、それが何らかの齟齬の原因となる可能性があります。それに、コンパイラを変えた場合はそれに連動していろいろな部分が変更されますので、できればbuildフォルダも捨てて新しいものに変えた方がよいくらいで、昔のCMakeではそれが必須だったのだとか。
★要するに、CMAKE_C(XX)_COMPILERは、Configのときに「キャッシュ変数」としてCMakeCacheに書き込まれたのですけれども、上のようにCMakeLists内であらためて指定すると、一時的にそちらが優先されてキャッシュ変数の値を隠蔽するのです（これを「ノーマル変数」「通常変数」などと言う）。しかし、キャッシュ変数の方は元のままですから、次にCMAKE_C(XX)_COMPILERを指定しないで処理した場合は、今度はキャッシュ変数が隠蔽されず、その値に戻ってしまうわけです。……「ノーマル変数」の方が《一時的》で、「キャッシュ変数」の方が《永続的》というのは、イメージとは逆の、CMake独特の用語法ですよね。
そういう次第ですから、上でやったような方法は、うまくいったからと言って常用するわけにはいきません。コンパイラを切り換えて使いたい場合は、cmakeコマンドを打つときに、下記のように-Dオプションで変更したいコンパイラを指定する必要があります（-Dオプションはキャッシュ変数を書き換え、Configもやり直される）。
コンパイラ切り換えでは、CとC++両方を指定する必要がありますので、-Dオプションだとご覧のようにとても長くなります。もし短いコマンドで代用したければ、これの代わりに-Cオプションというのが使えます。コマンドラインで打ち込む内容を別ファイルに書いておき、コマンドではそのファイル名を指定する、というやり方です。ファイル名を短くしておけば、打ち込む文字数も少なくて済むわけです。
では、その読み込むためのファイルを用意しておきましょう。当該ファイルに特に拡張子は指定されていないので、打ち込むコマンドを短くするためにも拡張子なしのテキストファイルにします。以下のようなコマンドを書いた二つの拡張子なしテキストファイルをソースフォルダに入れておきます。
setg（GCC設定用テキストファイル）
setc（Clang設定用テキストファイル）

共有/静的とDebug/Releaseの切り換えは？

これらは普通に以下のコマンドが使えます。
ただし、共有/静的の方は、これまたFindwxWidgets.cmakeに書き足す必要があります。上の「カスタマイズ②」のすぐ下、「if(BUILD_SHARED_LIBS)」と書いてある行のすぐ上に行を挿入し、そこに「unset(CACHE{wxWidgets_LIB_DIR})」──これはCMake4.2以降の新しい書き方なので、それより古いバージョンを使う場合は「unset(wxWidgets_LIB_DIR CACHE)」──と書き込んでください。
FindwxWidgets.cmakeのカスタマイズ③
こうしておかないと、初回Config以外ではBUILD_SHARED_LIBSの値がCMakeCacheに書き込まれた状態となり、そうなるとその下のfind_pathが働いてくれなくなってしまうようなのです。初回Config時には変数wxWidgets_LIB_DIRは「-NOTFOUND」状態でしょうから、find_pathは対象ファイル（NAMES以下に並んでいるもの）をちゃんと探しに行ってくれますが、そのときに見つけたパスをCMakeCacheに一旦書き込んでしまうと、次からは「これ、前に見つけてるやん」と思って探索しない仕様のようです。もちろん、こんな加工をしなくても、共有/静的の切り換えのたびにbuildフォルダを捨ててからやり直すようにすれば、切り換えはきちんと反映されます。上のような加工は、buildフォルダを捨てる手間を省きたいための、言わば「ものぐさビルド向け」のものということになるでしょうか。……AIに尋ねると、「共有/静的の切り換えでは、buildフォルダをいちいち捨てた方が安全です」と言われます。まあそりゃそうですよね。FindwxWidgets.cmakeを書いた人も、おそらくその前提なのでしょう。
★「コンパイラ切り換え」の場合は、buildフォルダを「必ず」作り直した方がよいことについては、この下で触れます。

各変更項目をCMakeListsに書き加える

準備として、次のようなCMakeLists.txtを用意します。
テスト用CMakeLists（改3）
■新規1──コンパイラ切り換え（GCCかClangか）解説
このブロックは、コンパイラ名によってwxWidgets_ROOT_DIRの代入値を変更する分岐処理。Config後、コンパイラ名は
C:/llvm-mingw/bin/clang++.exe
のように「フルパス」でCMAKE_C(XX)_COMPILERに書き込まれるので、get_filename_componentを使ってC++の「コンパイラ名だけ（拡張子もなし）」を取り出して、CMAKE_CXX_COMPILERにノーマル変数として一時的に上書き代入する。こうすれば「clang++」かどうかで条件分岐が書ける。FindwxWidgets.cmakeに加筆した条件分岐も同様に
if("${CMAKE_CXX_COMPILER}" STREQUAL "clang++")
とコンパイラ名だけで判定しているので、この処理は必須である。
★本稿での仕様として、Clangを使いたければ最初のConfig時に必ずClangを指定するオプションをコマンドラインに打つことになりますので（上記「FindwxWidgets.cmakeのカスタマイズ②」のあたりを参照）、Clangの場合はC++用のコンパイラ名は常にオプションで指定した「clang++」となります。ですから、この例のように「clang++」を分岐条件にするのなら正しく動作します。しかし、もし「g++」で分岐条件を書いたとすると、失敗する可能性が出てきます。なぜなら、本稿での仕様では、GCCを使いたいとき、Clangと違って最初のConfig時に必ずしもGCC指定オプションを打たなくてもよいのですけれども、その場合、CMakeは「gcc.exe」「g++.exe」ではなく、それらの古い名称の異名同内容ファイルである「cc.exe」「c++.exe」の方を探して読み込むと思われるからです。もちろん、GCCの場合もコンパイラ指定オプションを面倒がらずにコマンドラインに打ち込んで、使うべきコンパイラの名前は「cc」「c++」ではなく「gcc」「g++」であることを明示しておけば、分岐条件が「g++」であったとしても正しく動作します。
■新規2──ライブラリ切り換え（共有か静的か）解説
これは、BUILD_SHARED_LIBSの項目と初期値をCMakeCache内に生成させる処理。BUILD_SHARED_LIBSは、この下のCMAKE_BUILD_TYPEと違って、値を指定しない限り項目そのものがCMakeCache内に生成されない。よって、このコマンドによって項目および初期値（OFF=静的）を生成させる。この下のCMAKE_BUILD_TYPEと同じように書いても大丈夫だと思うが、こちらはBOOL型なのでoptionを使って1行で書ける、というか、この項目の生成にoptionを使っているのは公式の真似である。optionは、すでにその項目が設定されている場合は何もしないので、項目の生成は最初のConfig時にしか実行されない。もちろん、値を変更することはコマンドラインでいつでもできる。
■新規3──ビルドタイプ切り換え（DebugかReleaseか）解説
このブロックは、CMAKE_BUILD_TYPEの初期値をCMakeCacheに書き込む処理。CMAKE_BUILD_TYPEは、CMakeCache内に項目は生成されても、指定しない限り値は空白になる。そこで、明示的にデフォルト値：Releaseを書き込んでおく。最初のConfig時に一度値を書き込んでしまえば、次からはこのブロックは無視される。
■新規4──確認メッセージ解説
この下は、設定が反映されているかどうかを確認するためのmessageコマンド。「C++コンパイラフルパス」の方は、キャッシュ変数、すなわちCMakeCacheに書き込まれた永続的な変数の値を表示する。それに対し、同じ名前の変数を扱う「C++コンパイラ名」の方は、ノーマル変数、すなわちこの処理の間だけキャッシュ変数を隠蔽する一時的な変数の値を表示する。get_filename_componentによって、フルパスではなく拡張子もカットしたコンパイラ名だけを取り出している。■新規1の解説参照。

【コンパイラ切り換え：方法1】切り換えるたびにbuildフォルダを削除する

私が実験したところでは、選択肢②の共有・静的切り換えと選択肢③のRelease・Debug切り換えは同時にできるけれども、選択肢①のコンパイラ切り換えだけは単独で行う必要がありました。すなわち、①を指定せず②③を指定した場合は②③の切り換えが成功しますが、①②③とか①②とか①③とか、コンパイラ切り換えと同時にやろうとすると、②③は変更されないままでした。原因はよく分かりません。しかし、コンパイラ切り換え時の昔の流儀に従って（？）、build用のフォルダを削除してから実行すれば、①②③すべて同時にちゃんと反映されました。どうやら②③の切り換えを①のコンパイラ切り換えと同時に行う場合は、過去の作業ファイルの削除は（少なくとも私の環境では）必須であるようです。フォルダ削除はシェルごとにコマンドが異なるので厄介ですが、幸いCMakeにもそのコマンドがあるようなので、それを使えば環境に左右されずに済みそうです。
では、上のコマンドでbuildフォルダを消してから、-Cや-Dオプションなしのコマンドを打ってみましょう。
下の方の日本語混じりの4行に着目してください。C++のコンパイラは、上の注で触れたように、やはり「g++」ではなく旧名ファイルの「c++」の方を拾ってしまっていますね。ビルドタイプと共有ライブラリか否かについては、きちんと値が設定されました。これらは、もし上の■新規2と■新規3を書かないと、
と、値が空白になります。BUILD_SHARED_LIBSは、CMakeCacheの中に値どころか項目すら作られません。ただ、これらが空白であってもビルドはできました。実行ファイルのサイズから見て、どうやら「静的ライブラリRelease版」が作られるようです。これは四つのキットが全部ビルド＆インストールされている環境でもそうなります。FindwxWidgets.cmakeが、これらが空白だった場合には「静的ライブラリ」「Release」を選ぶよう設定されているのでしょう。もし「静的ライブラリRelease版」キットがインストールされていなくても、あるものの中から別のものを選んでくれるようです。
Hello World 04
では、おそらく実行ファイルが最も小さくなるであろう「Clang共有ライブラリRelease版」を作ってみましょう。これは、MSYS2で大量の警告が出ていたものです。
例によってbuildフォルダを削除してから、上のコマンドを打ってみましょう。
うまくいったようなのでビルドしてみたところ、何の警告も出ずに完了しました。生成された実行ファイルは166KBというコンパクトさでした。dllファイル二つを近くに置かねばなりませんが、ちゃんと実行できましたし、何の問題もありませんでした。
もう一つ、今度はファイルサイズがいちばん大きくなるであろう「GCC静的ライブラリDebug版」を作ってみます。
下の方の日本語メッセージに注目してください。今度は-CオプションでGCCを指定したので、旧名ファイルの「c++」ではなく、ちゃんと「g++」の方を見つけて採用していますね。ビルドと実行は、これまた何の問題もなし。ただ、実行ファイルは100MB近くありました。さっきの166KBに比べると600倍もの大きさです。「静的ライブラリDebug版」はこのようにファイルサイズが非常に大きくなりますが、同じDebug版でも「共有ライブラリDebug版」ならそれほどでもありません。後で実験してみましょう。

【コンパイラ切り換え：方法2】buildフォルダを分ける

方法1では、コンパイラを切り換えるたびにbuildフォルダを削除していたので、そのためのコマンドが一つ多く必要になり、毎回コマンドを2回実行する必要がありました。しかし、こちらの方法なら、最初からGCC用とClang用のbuildフォルダをそれぞれ別に用意しますので、buildフォルダを削除するコマンドを打つ必要はありません。その代わり、buildフォルダが二つになりますから、その分ストレージの容量が多く必要になります。
★ただし、上にも書いたように、共有/静的の切り換えの場合も、コンパイラ切り換えと同様にbuildフォルダを作り直した方が安全であることは確かです。本稿では、「FindwxWidgets.cmakeのカスタマイズ③」において、buildフォルダを温存しても共有/静的が切り換えられるような加工をしましたが、オリジナルはbuildフォルダを作り直さなければならない仕様だったのです。
やり方は、まず-CオプションでGCCを指定したコマンドとClangを指定したコマンドを両方実行しますが、その際、両者でbuildフォルダの名称を変えておきます。
こうしてからソースファイルのフォルダを見ると、build_g、build_cという二つの新しいフォルダが生成されていました。爾後、buildフォルダを捨ててやり直す事態にならない限りは、コンパイラ切り換えのための-Cあるいは-Dオプションはもう二度と打つ必要はなく、コンパイラ切り換えはこれらのbuildフォルダの指定を変えることによって行うことができます。ビルドと実行も、次のようにbuildフォルダを変えるだけです。
★二つのbuildフォルダの名前について、ここでは「build_g」「build_c」のように末尾を変えただけにしていますが、これだと似ていて紛らわしいので、両者をもっとガラッと変えてしまうのもありだと思います。ただ、末尾を変えただけの場合の利点もあって、それは「最後の1文字を変えただけでコンパイラの変更ができる」という点です。
どちらも何の問題もなく起動できました。実行ファイルのサイズから見て、どちらも指定どおり「静的ライブラリRelease版」が作られたようです。
次に、設定を変更してビルドしてみましょう。上で「後で実験してみましょう」と書いておいたGCCによる「共有ライブラリDebug版」を作ってみたいと思います。GCCの「静的ライブラリDebug版」の実行ファイルは100MB近くもの大きさがありましたが、これを共有に変更するとどれくらい小さくなるのか？コマンドは、GCC用もClang用もすでにbuildフォルダを作っていますので、GCCでビルドしたければ-Bの指定を「build_g」とするだけでよく、もうコンパイラ変更用の-Cオプションや-Dオプションを付ける必要はありません。
うまく切り換えられたようなので、ビルドしてから実行ファイルのサイズを見てみると、677KBでした。同じDebug版でも静的ライブラリの方は100MB近くもあったのに、えらい違いですねｗ。
次はClangで「静的ライブラリDebug版」を作ってみます。GCCのように100MB近くにもなるのかどうか。
静的ライブラリであることは変わらず（＝clang_x64_libフォルダの中身を読みに行くことは変わらず）、ReleaseがDebugに変わっただけですので、ライブラリをずらずらと読み込み直す手続は省略されています。ビルドと実行にも何の問題もありませんでした。で、実行ファイルの大きさですが、だいたい47MBといったところです。大きいけれども、GCC版の100MBに比べると半分ほどのサイズとなっています。
最後に、Clangによる「共有ライブラリDebug版」を作っておきます。
今度は読みに行くべきライブラリフォルダが変わったので（clang_x64_lib → clang_x64_dll）、あらためてファイルが読み込み直されました。ビルドも実行も問題なし。実行ファイルの大きさは833KBとなりました。GCCの方は677KBでしたから、意外にもGCCの実行ファイルよりも大きくなっています。Clangでビルドした実行ファイルのうち、唯一この「共有ライブラリDebug版」だけが、GCCで作ったものよりも大きくなりました。

デモとサンプルを使いたくなったら？

demosよりボンズ
demosよりbombs.exe
samplesよりウィジェッツ
samplesよりwidgets.exe
wxWidgetsには、デモとサンプルが付いています。これらをCMakeを使ってビルドするのは特に難しくはありませんが、私がやってみて気づいた注意点を次に挙げておきます。
  1. demosとsamplesは、コンパイラ・共有/静的ライブラリ・ビルドタイプなどの設定の影響を受ける。
  2. demosとsamplesの実行ファイルその他は、buildフォルダ内のlib/gcc_x64_dllやclang_x64_libといったフォルダの中に生成されるため、本体用のライブラリファイルとごちゃまぜになる。
  3. 本体をビルドしてから追加でdemosまたはsamplesをビルドする場合は、本体をビルドしたときと同じbuildフォルダを指定しないと、また最初から、すなわち本体のビルドから始まってしまう。
1.は、「exeファイル単独で起動でき」、「ファイルサイズがなるべく小さくなるもの」を選ぶとすると、「Clang・静的・Release」の組み合わせになるかと思います。demosまたはsamplesの追加ビルドの場合、この組み合わせの本体キットがすでにビルド＆インストールされていないと、本体キットのビルドから始まってしまいますので注意。
2.は、本体のように必要なファイルだけをインストールフォルダにコピーさせる方法もあるのかもしれませんが、私には分かりません。まあbuildフォルダ内にごちゃまぜになった状態でも、どれが本体用のファイルなのかはだいたい分かりますので、それ以外の実行ファイルの名称からどんな内容なのかは推測できると思います。
3.は、すでに本体がビルド済みの状態でdemosやsamplesだけをビルドしたい場合、まっさらなフォルダをbuildフォルダに指定してしまうと、CMakeとNinjaは「本体がまだない」と判断して本体のビルドから始めてしまいます。本体がすでにビルドされている場合は「追加ビルド」になるわけですから、本体をビルドしたときのCMakeCacheをCMakeに読ませる必要があります。
これらのビルドは、cmake-guiを次のようにセットします。下の画像は、本稿の最初、MinGW用の静的ライブラリRelease版本体をビルド＆インストールしたときに、これらも同時にビルドする場合の設定をやってみて、その様子をついでに撮影したものです。
デモ選択
demosをビルド
サンプル選択
samplesをビルド
これらを全部ビルドすると、demosでは10個のファイルが、samplesでは17個のフォルダと198個のファイルが、buildフォルダ内の「gcc_x64_lib」等のフォルダの中に作られます。225個もの新たなアイテムが増えるわけですから、当該フォルダ内がゴチャゴチャするのは当然です。実行ファイルは何となく分かるのですが、それ以外はどのフォルダやファイルがどのアイテムに所属するものなのか、よく分かりません。
私は別にこの状態でもかまわないのですけれども、もし「そんな状態ではあまりにも散らかりすぎていて使いにくかろう」というのでしたら、例えば次のような方法が考えられます。付属のCMakeListsではビルドするアプリを選べず、デモならデモで、サンプルならサンプルで、まとめてビルドするしかないようなので、これ以上の分類方法は私には思いつきません。
★サンプルの方は、上の画像に見るように、「SOME」と「ALL」が選べます。
  1. 適当な作業用フォルダを作り、そこに「Clang用静的ライブラリRelease版」を単独でビルド。静的リンク実行ファイルを作るなら、これがいちばんファイルサイズが小さくなる。もちろんGCCを使ってもかまわない。お好みで。
  2. 「（ビルドフォルダ）\lib\clang_x64_lib」を開いて中のフォルダとファイルを確認しておく。wxWidgets3.2.9以降なら上記のようにフォルダ「2個」とaファイルが23個できていると思われる。それ以前のバージョンならフォルダは「1個」である。
  3. 追加ビルドで、demosを全部ビルドする。
  4. 「（ビルドフォルダ）\lib\clang_x64_lib」を開いて、新しくできたファイル10個を「wxdemos」などと名前を付けた別のフォルダに移動させる。
  5. 追加ビルドで、samplesを全部ビルドする。
  6. 「（ビルドフォルダ）\lib\clang_x64_lib」を開いて、新しくできたフォルダ17個とファイル198個を「wxsamples」などと名前を付けた別のフォルダに移動させる。
  7. 「Clang用静的ライブラリRelease版」をビルドした作業用フォルダには本体だけが残っている状態だが、もう使わないのでフォルダごと削除。
★試していないので何とも言えませんが、demosにもsamplesにもmakefileが付いているので、それを使ってビルドすることもできます。というか、公式の「Samples Overview」のページでは、WindowsでMSVC（Microsoft Visual C++ Compiler）を使わないとなると、その方法でのbuild方法しか書かれていません。makeでビルドするのなら、demosおよびsamplesのフォルダのみならず、各アプリのソースフォルダそれぞれにもmakefileが同梱されていますから、アプリ単独でビルドすることも可能でしょう。ただ、Clangを使いたい場合は、コンパイラ指定の変数を書き換えるなどの加工が必要になるかもしれません。また、makefileを使う場合、本体をmakefileでビルド＆インストールしてから行う必要がありそうで、その後demosもsamplesもビルドした本体のタイプ（静的ライブラリRelease版など）に合わせてコマンドを打つことになります。上にも触れたように、makefileを使った本体のビルド方法については、英語ですが『PB's Guide to Starting with wxWidgets on Microsoft Windows with MinGW and Code::Blocks』をご覧ください。
ご意見・ご教示等ございましたら こちら からお送りください。
Copyright © 2026 鷺澤伸介 All rights reserved.