【ITニュース解説】How I Finally Got g++ Working on Windows (And You Can Too!)

Windows環境でC++言語のプログラムを開発する際、多くの開発者が利用するコンパイラであるg++を導入することは、しばしば初心者にとって困難な課題となる。筆者もまた、新しくセットアップしたWindowsマシンでC++コードをコンパイルしようとした際、「g++が見つからない」というおなじみのエラーメッセージに直面した。これは、Windowsオペレーティングシステムには標準でg++コンパイラが組み込まれていないために発生する典型的な問題である。

この問題を解決するため、筆者はいくつかの方法を検討した。まず、Microsoftが提供する統合開発環境であるVisual Studioをインストールするという選択肢があった。しかし、Visual Studioは非常に多機能でダウンロード容量も大きく、単にC++コードをコンパイルする目的には過剰であると考えられた。また、既存のスクリプトがg++の使用を前提としていたため、Visual Studioに付属するコンパイラであるcl.exeに合わせるにはスクリプトの修正が必要となる点も課題だった。

次に検討されたのは、MinGW-w64を利用するという伝統的な方法である。MinGW-w64は、オープンソースのGNU Compiler Collection (GCC) をWindows環境で動作させるためのツール群であり、長年にわたって多くの開発者に利用されてきた。しかし、以前は非公式なインストーラーをダウンロードしたり、手動でシステム環境変数PATHを設定したりと、インストールと設定が非常に煩雑であったという記憶が筆者にはあった。

そこで筆者は、Windows 10以降に標準搭載されている新しいパッケージマネージャー「winget」の存在を思い出した。wingetを使えば、コマンドラインからソフトウェアを簡単にインストールできる。wingetでMinGW-w64を検索した結果、「MSYS2」が見つかった。MSYS2は、MinGW-w64をWindows上で効率的に導入し管理するための環境であり、Linuxのパッケージマネージャーであるpacmanと同様の機能をWindows上で提供する。

この方針に基づき、筆者はまずwingetコマンドを使用してMSYS2をインストールした。インストールが完了した後、MSYS2のターミナルを開き、pacmanコマンドを使ってMinGW-w64のGCCツールチェーンを導入した。この段階でコンパイラ本体はシステムにインストールされたが、Powershellのような通常のコマンドプロンプトでg++と入力しても、まだコマンドが認識されない状態だった。これは、Windowsが実行可能ファイルを探す場所を示す「環境変数PATH」に、新しくインストールされたg++のパスが追加されていないためである。

この問題を解決するためには、手動でシステムの環境変数PATHに、g++実行ファイルが存在するディレクトリのパスを追加する必要がある。これは、Windowsのシステム設定から「環境変数」ダイアログを開き、PATH設定を編集するという複数のステップを要する作業であり、手間がかかる上に、設定変更を反映させるためにはコマンドプロンプトやPowershellを再起動しなければならない。

このような手動での設定作業の煩雑さに直面し、筆者はこの一連のプロセス全体をPowerShellスクリプトで自動化することを着想した。この自動化スクリプトは、wingetによるMSYS2のインストール、pacmanによるMinGW-w64 GCCツールチェーンの導入、そして環境変数PATHの自動設定を一度に行うことを目的とした。さらに、既存のインストール環境への対応や、エラー発生時の処理、管理者権限がない場合の挙動など、様々な状況に柔軟に対応できるような工夫が盛り込まれた。

最終的に筆者は、この自動化スクリプトをGitHubで公開し、たった一つのコマンドで実行できるようにした。Powershellのirm（Invoke-RestMethodの略）コマンドでGitHub上のスクリプトファイルをダウンロードし、iex（Invoke-Expressionの略）コマンドで即座に実行するという形式である。このワンライナーコマンドは、新しい開発マシンのセットアップや、同僚との環境共有を劇的に簡素化する。

インターネット上のスクリプトを実行することにはセキュリティ上の注意が必要だが、このスクリプトはGitHub上でコードが公開されており、誰でもその内容を事前に確認できるため、高い透明性を持つ。また、スクリプトが行うのは、既存のフリーソフトウェアをインストールし、環境設定を自動化するのみであり、悪意のある動作は含まれていない。

筆者は、インストールスクリプトと合わせて、環境をクリーンに元に戻すためのアンインストールスクリプトも作成した。これにより、g++環境が不要になった場合や、何らかの問題が発生した場合でも、環境変数や関連ファイルを容易に削除し、システムを元の状態に戻せる。

筆者が開発したこの自動化スクリプトは、手動でのインストールにかかる時間を大幅に短縮し、複雑な設定作業を排除する。エラーハンドリング機能を備え、異なるマシン間でも一貫した動作を保証するため、C++開発環境の構築を劇的に簡素化するメリットがある。このスクリプトは、新規のWindows 11環境、既存の開発ツールが導入されたWindows 10、権限が制限された企業のマシンなど、様々な環境でテストされ、適切に動作することが確認された。

この一連の経験を通じて、筆者は現代のソフトウェア開発環境において、コンパイラの導入や環境変数の設定といった基本的な作業が依然として手動に依存している現状に疑問を呈している。Node.jsのnpmやPythonのpipのように、他の言語ではパッケージマネージャーが開発環境をシームレスに管理していることに触れ、C++環境も同様に自動化されるべきだと主張する。

この作業から得られた教訓として、筆者は「自動化はドキュメントよりも優れている」こと、ワンライナーコマンドが導入の障壁を極限まで下げる強力な手段であること、堅牢なエラーハンドリングが実用的なツールを作る上で不可欠であること、そして、様々な環境でのテストと、いざという時のためのアンインストールオプション（エスケープハッチ）の提供が重要であると述べている。

最終的に、Windows環境でのg++導入という単純な目的から始まった筆者の旅は、Windowsのパッケージ管理、PowerShellスクリプトの作成、そして開発者体験の設計という深い洞察につながった。この自動化されたスクリプトは、Windows上でC++開発環境をセットアップする際の苦労を過去のものとし、多くの開発者がより本質的なプログラミングに集中できる手助けとなる。