本稿の内容に関して
本稿は GDEXTENSION の開発環境構築を行った際のメモの共有を意図した、一連の記事の１番目。
対象としている Godot エンジンのバージョンは 4.2.1。
本稿では 開発環境に使うツール類のインストール方法や使い方を紹介している。
モチベーション（もしくは戯言）
GDEXTENSION の開発環境構築に関してまとめたので公開しようと思う。
Godot エンジンは OSS でありながら、UNITY、Unreal Engine のオルタナティブとして検討価値のあるゲームエンジン。現在 バージョン 4.2.1 であり最も勢いがある成長株として注目している。この勢いは blender や gimp が一大勢力となる前夜のころに似ていて、勉強しておく必要性を感じた。
Godot エンジンは 独自言語である GDScript なるプログラミング言語（もしくは C#）で記述するが、GDEXTENSION という機能により、C++ で記述した機能をダイナミックリンクライブラリとして機能拡張することができる。
一般に C++ を用いたい理由は大きくはパフォーマンス性能の向上と C++ の歴史が提供する膨大な量のライブラリ利用だと思う。Godot エンジンを優れた 2D 及び 3D のユーザーインターフェースソリューションとして捉えた場合、C++ ライブラリを用いて作成した自作の機能を GDEXTENSION として作りこみ、一つの Godot アプリケーションとして提供できる意義は大きい。
ところで Godot エンジンの開発者達は scons を愛しているようで、Cmake ではなく scons を選択している。気持ちは分からなくもない。Godot エンジンは複雑なマルチプラットフォームアプリケーションであり、開発環境でもある。クロスプラットフォームのビルド環境を Cmake で書くのは非常に骨が折れる作業であることは想像に難くない。
scons は python ベースのビルドツールで、設定ファイルである SConstruct や SConscript は python のスクリプトをそのまま記述できる。適切なスクリプト言語連携がない Cmake とは違い、クロスプラットフォーム環境の細かな制御が安易になる。
ではあるが、現状において殆どの C++ ライブラリは Cmake を用いてビルドされている。GDEXTENSION をビルドする側の視点に立つと Cmake で作られたライブラリを scons で用いるという課題を解決しなければならない。これは相当な初心者キラー要素であろう。
更に残念なことに日本国内では scons は人気が無く、日本語の情報が少ない。このことが、C++ ライブラリを用いた GDEXTENSION 開発のハードルを跳ね上げている。
更に更に残念なことに scons はクセが強い。ある程度大きなプロジェクトの scons 設定ファイルを読み下すのに、scons のマニュアルを読んだだけでは理解できない場合が多すぎる。慣れてくるとアタリマエになってくるのだろうが、そのアタリマエが初学者には遠い。
そして、Godot エンジンのビルドシステムは scons だけでできているわけではなく、YAML だなんだと支援ツールの記述を理解する必要がある。C/C++/Cmake の開発経験があるという状態から始めても、学習コストは決して少なくない。
このような事情故に C++ での GDEXTENSION 開発は高難易度となり、新規参入者が増えていかない。このような状況は変えていかねばならない。
結局必要なライブラリが使えて、ビルドを通す方法さえ明確化できれば、日本の C++ 開発者人口は多いのだから、一定数の新規参入は見込める筈だ。
2D 及び 3D ソリューションの表現プラットフォームとして、ROS2 及び rviz を使うケースが多いと思うが、ROS2 の最大の難点は クロスプラットフォーム対応がプアで、Windows ベースとして考えた場合でも Visual Studio の、しかも特定のバージョンしかサポートしていなかったりする。
アカデミック界隈では何かしら再現可能な実施例を示すことが重要で、逆に言えば何かしらの再現可能な実施例を示すことさえできればそれで満足してしまっているように見える。しかし、QR コードを示して相手のスマホで自作 WEB アプリを開かせ、「これが私が開発したテクノロジーです」とやれた方が良いに決まっている。
ROS2 及び rviz の代替として QT、wxWidgets、GTK+、FLTK といった既存の C++ ベースのクロスプラットフォーム GUI ソリューションを探すも 2D、3Dという観点から見ると自作しなければならない部分があまりにも多すぎる。ならばいっそのこと UNITY はどうだと思っていたところに例の Unity Runtime Fee 問題がきて、プロプライエタリなソフトウェアに嫌気がさしてしまった。このような方は少なからずおられるのではないだろうか。
Godot エンジンは非常によくできている。素性が良い。2D 及び 3D の GUI プラットフォームとして現状でも十分役に立つと思う。「こうすればあなたの成果を組み込める」という手順さえ明確化できれば、Godot エンジン（GDEXTENSION）は日本でもっともっと使われていく筈だ。ROS2 と rviz の組み合わせに並ぶ、大学や企業での研究結果デモプログラムの標準プラットフォームになりえると思う。アカデミック界隈を取り込むことができれば、Godot エンジンの未来は輝かしいものになるだろう。
一連の記事では比較的需要が多いと思われる opencv を例にとり、Cmake でビルドされた C++ ライブラリを GDEXTENSION に組み込む方法を共有すべく検討する。
なお、godot-cpp は一応 Cmake もサポートするようだ。これが常に動作するのならば Cmake でビルド環境を組むのも良い選択肢に見える。しかし godot-cpp の Cmake による MinGW-w64 ビルドは Godot エンジンのバージョンによって挙動が変わり付き合いきれない。メインは scons なので村の掟には素直に従おうと思う。
GDEXTENSION 開発環境構築にあたり、Windows 用の C++ ツールチェーンの選択肢はいくつかあるが、本稿では MinGW-w64 に固執する。他の有力候補である Visual Studio を選択しない理由は、大きく二つ。
- 企業ではライセンスの問題があり、無料の Visual studio community を使えない場合がある。
- Visual studio community を含め、バージョンが多すぎて説明が煩雑になる。
mingw は GNU GCC の Windows 実装であり、無料で使用することができる。MinGW-w64 は mingw の 64bit 環境用の実装。Godot は mingw をサポートする。つまりは万人が無料で GDEXTENSION 開発に使えて、なおかつ説明しやすい選択が MinGW-w64 となる。
ただし、多くの C++ ライブラリの Windows 向けメインターゲットは Visual Studio であり、MinGW-w64 はマイナー選択となる。よって MinGW-w64 を用いた C++ ライブラリのビルドは手探りであることが多く、イバラの道でもある。共にイバラの道を歩もうではないか。
Godot エンジンの特徴と今回構築する開発環境
Godot エンジンは Windows / macOS / Android / iOS / WEB とマルチプラットフォームをサポートする。Godot エンジンは、GDScript で記述したアプリケーションをプラットフォーム非依存のバイトコードにコンパイルし、各プラットフォームで動作する Godot エンジン（エクスポートテンプレート）でバイトコードを解釈する構造により、マルチプラットフォームを実現している。この辺の仕組みは Java にやや近い。この仕組みのために、GDScript で記述された Godot エンジンアプリケーションはプラットフォームごとにビルド環境を用意することなく、それぞれのプラットフォーム向けの実行ファイルを生成することができる。チュートリアルをなぞって作った 3D ゲームがコンパイルすることなく WEB ブラウザで動作するのはとても楽しい。
ただし GDEXTENSION 機能は C++ で機能実装するため、各プラットフォームで動作するソースコードをそれぞれのプラットフォームのネイティブ C＋＋ コンパイラでビルドして共用ライブラリを生成する必要がある。つまり、開発環境も必要ならばそれぞれ仕向けに用意する必要がある。本稿では Windows X86 64bit アーキテクチャプラットフォーム用を構築するとともに、将来例えば Android 用や WEB 用を追加し、切り替えられるように検討する。
ディレクトリ構造計画
Godot GDEXTENSION 関連のソフトウェア開発を行うにあたり、c:\dev ディレクトリを作成しその下にできるだけ開発環境を纏めてゆく。
c:\>mkdir dev c:\>cd dev c:\dev>
更に、build に必要なツール類は c:\dev\tools ディレクトリを作成し、その下にできるだけまとめてゆく。
c:\dev>mkdir tools c:\>cd tools c:\dev\tools>
ツール類
curl
curl は WEB 上の http サイトや ftp サイトからダウンロードしてローカルに格納するために使う。
開発環境構築ではパッケージアーカイブファイルをダウンロードし、解凍し、ビルドに用いる。アーカイブファイルは置いておくと邪魔になるので使用後は消すことになるが、開発環境構築では似た作業を何度も繰り返す事が多い。GUI で行うには Chrome などの WEB ブラウザで目的のサイトを開き、ダウンロードし、目的のディレクトリに移動させるなどの操作となり、作業性を損なうので curl を用いて CUI で作業すると便利。
windows10 及び windows11 では curl は標準で含まれる。デフォルト状態で PATH が通っているので、コマンドプロンプトから使用することができる。
c:\dev>where curl C:\Windows\System32\curl.exe c:\dev>curl --help Usage: curl [options...] <url> -d, --data <data> HTTP POST data -f, --fail Fail fast with no output on HTTP errors -h, --help <category> Get help for commands -i, --include Include protocol response headers in the output -o, --output <file> Write to file instead of stdout -O, --remote-name Write output to a file named as the remote file -s, --silent Silent mode -T, --upload-file <file> Transfer local FILE to destination -u, --user <user:password> Server user and password -A, --user-agent <name> Send User-Agent <name> to server -v, --verbose Make the operation more talkative -V, --version Show version number and quit This is not the full help, this menu is stripped into categories. Use "--help category" to get an overview of all categories. For all options use the manual or "--help all". c:\dev>
本稿の範囲では以下のように、リモートファイルをリモートファイル名でダウンロードする用途でしか使わない。
c:\dev>curl -O https://hoge.com/<remoteFile>
c:\dev 配下に \<remoteFile\> の名前でダウンロードファイルが生成する。
7-zip
Windows10 及び Windows11 ではコマンドプロンプトで zip および ７z ファイルを取り扱うコマンドが用意されていない。
ここでは 7-zip をインストールする。7-zipは高圧縮率のファイルアーカイバであり、Godot の配布形式である .zip にも対応している。
7-zip は以下のサイトで配布されている。
このサイトを開くと以下の図のようにダウンロードリンクがあるので必要なものをダウンロードする。
windows11 であれば “64bit x64” を選ぶ。ダウンロードされるのは以下のような実行ファイル形式のインストーラー。
7z2301-x64.exe
問題無ければマウスの左ダブルクリックで実行する。以下のように格納ディレクトリを聞いてくるので希望するディレクトリを指定する。
7-zip は Godot の開発以外にも使用できる汎用ツールであるため、デフォルトの “C:\Program Files\7-Zip\” で良い。デフォルト以外のディレクトリにインストールする場合は、記録しておく。
ここでインストールした 7-zip は Windows 用 GUI アプリケーションであるが、コマンドプロンプトからのコンソールアプリケーションとしても使うことができる。インストールしただけでは環境変数 PATH が通っていないので、コマンドプロンプトから使うためには以下のようにして PATH を通す必要がある。以下は実行例で、7-zip のコマンドラインからの使用方法が出力される。
c:\dev>SET PATH=%PATH%;"C:\Program Files\7-Zip\" C:\dev>7z 7-Zip 23.01 (x64) : Copyright (c) 1999-2023 Igor Pavlov : 2023-06-20 Usage: 7z <command> [<switches>...] <archive_name> [<file_names>...] [@listfile] <Commands> a : Add files to archive b : Benchmark d : Delete files from archive e : Extract files from archive (without using directory names) h : Calculate hash values for files i : Show information about supported formats l : List contents of archive rn : Rename files in archive t : Test integrity of archive u : Update files to archive x : eXtract files with full paths ～ 以後長いので省略 ～ C:\dev>
コマンドプロンプトでの SET コマンドで PATH を変更する場合は一時的なものであり、コマンドプロンプトを閉じると変更は失われることに注意。これはシステム全体の環境変数 PATH 設定を汚染しないともいえる。
もしくは 環境変数 PATH に登録せずに以下のように毎回フルパスを指定して実行しても良い。
c:\dev>"C:\Program Files\7-Zip\7z.exe" --help
tar
tar は UNIX 系で多用されるアーカイブフォーマットで、それを取り扱うツールでもある。
多くの C++ ライブラリが tar もしくは tar.gz 形式で配布されていて、取得したライブラリの展開に tar は必要となる。意外なことに、Windows10 及び Windows11 では tar は標準で含まれる。デフォルト状態で PATH が通っているので、コマンドプロンプトから使用することができる。
c:\>where tar
C:\Windows\System32\tar.exe
c:\>tar --help
tar(bsdtar): manipulate archive files
First option must be a mode specifier:
-c Create -r Add/Replace -t List -u Update -x Extract
Common Options:
-b # Use # 512-byte records per I/O block
-f <filename> Location of archive (default \\.\tape0)
-v Verbose
-w Interactive
Create: tar -c [options] [<file> | <dir> | @<archive> | -C <dir> ]
<file>, <dir> add these items to archive
-z, -j, -J, --lzma Compress archive with gzip/bzip2/xz/lzma
--format {ustar|pax|cpio|shar} Select archive format
--exclude <pattern> Skip files that match pattern
-C <dir> Change to <dir> before processing remaining files
@<archive> Add entries from <archive> to output
List: tar -t [options] [<patterns>]
<patterns> If specified, list only entries that match
Extract: tar -x [options] [<patterns>]
<patterns> If specified, extract only entries that match
-k Keep (don't overwrite) existing files
-m Don't restore modification times
-O Write entries to stdout, don't restore to disk
-p Restore permissions (including ACLs, owner, file flags)
bsdtar 3.6.2 - libarchive 3.6.2 zlib/1.2.5.f-ipp liblzma/5.2.5 bz2lib/1.0.8 libzstd/1.5.4
c:\>
git
git は本来、プログラムソースコードなどのバージョン管理／差分管理ソフトであるが、本記事の範囲では GitHub などの GIT レポジトリからソースコード一式をダウンロードするツールとして使用する。
Windows 用実装の配布サイトは以下。
最新バージョンを選んで問題ない。バージョンを気にして入れ替えるようなツールではなく、新しいバージョンに入れ替えても然程副作用は考えにくいツールであるため、サイトの指示通りにインストールし、インストーラーの機能で PATH を通しておく。
通常は以下にインストールされる。
C:\Program Files\Git\
以下に PATH は通しておく必要がある。
C:\Program Files\Git\cmd
Cmake
Cmake は、コンパイラに依存しないビルド自動化のためのツール。make や ninja といった、より低レベル作業用のビルドツールと連携する。昨今では多くの C++ ライブラリやツールが Cmake でビルドするよう設計されているので必要となる。
配布サイトは以下で、Windows 用のインストーラーを選択する。
最新バージョンを選んで問題ない。 バージョンを気にして入れ替えるようなツールではなく、新しいバージョンに入れ替えても然程副作用は考えにくいツールであるため、 サイトの指示通りにインストールし、インストーラーの機能で PATH を通しておく。通常は以下にインストールされる。
C:\Program Files\CMake\
以下に PATH は通しておく必要がある。
C:\Program Files\CMake\bin
Python3
Python3 は scons を動作させるために必要。
Python3 はどの実装を選ぶか、インストール先をどこにするかなど悩みが多い。一口に Windows 用の python といっても 公式（python.org）にするか Anaconda にするか、はたまた Miniconda にするかなど選択肢が多い。また、用途によって Python3 のバージョンを強く指定しているもの (ROS2など) がある。更に、ライブラリのバージョンを気にする場合などがあり、同じバージョンの python3 を複数インストールし、異なるバージョンのライブラリをインストールする必要がある場合もある。blender や gimp2、MinGW、Emscripten など、独自に python を内包しているツールも多々あって、知らないうちに python に PATH を通してしまっていた、などといったケースも考えられる。
Godot の使用するビルドツールである scons は python 3.6+ をサポートしている。ここでは 公式（python.org）からpython 3.12 を scons 専用にインストールして、使用するときだけ有効とする方法を考える。
Python 公式の配布サイトは以下。
このサイトを開くと以下のようになる。
タイトル下のメニュータブの “Downloads” → “Windows” をクリックすると “Python Releases for Windows” のページに飛ぶ。
このページの “Latest Python 3 Release – Python 3.12.0” を左クリックすると “Python 3.12.0” のページに飛ぶ。
このページの をスクロールしてゆくと下の方に “Files” の項があり、その中に “Windows installer (64-bit)” のリンクがある。
クリックすると、以下の実行ファイルがダウンロードされるので問題無ければ実行する。
python-3.12.0-amd64.exe
“Customize installation” を選択する。
“Optional Features” のダイアログで “py lancher” と “for all users (requires admin privileges)” のチェックを外し、”Next” をクリックする。
尚、次の “scons” の項で出てくる pip はこのダイアログの “pip” のチェックを付けたままにしておくことでインストールされる。
“Advanced Options” のダイアログで全てのチェックを外し、 “Custmize install location” に以下のディレクトリを指定する。
C:\dev\tools\Python\Python312
指定できたら、”Install” をクリックするとインストールが始まる。
インストールが成功すると以下のようなダイアログが表示される。
MAX_PATH limitation の警告が出るが、scons を使うだけであれば無視して構わない。
使用する場合は以下の PATH を一時的に環境変数 PATH に追加する。
C:\dev\tools\Python\Python312\Scripts C:\dev\tools\Python\Python312
具体的には以下のようにする。
c:\dev>SET PATH=C:\dev\tools\Python\Python312\Scripts; C:\dev\tools\Python\Python312;%PATH%
ポイントは既存設定 PATH を示す %PATH% より前に python 用 PATH を追加すること。これにより既存インストールの python より先に、今回インストールされた python 3.12 が検索され、使用される。
とはいえ、このように複数の python がインストールされている環境では事故を起こしやすい。例えば上記 SET コマンドを発行し忘れて、従来の環境に余計な pip install を行ってしまう場合などが考えられる。
環境変数 PATH からpython 関連を除外し、必要な時に必要な python の PATH を通すと良い。
Anaconda や Miniconda を使用せず、公式の python のみを使う場合は “py launcher” で管理するのも良いだろう。
以下のようにしてバージョン表示されれば、インストールは問題ない。
c:\dev>python -V Python 3.12.0
同様に pip も確認しておく。
c:\dev\freeglut-3.4.0\build\bin>pip -V pip 23.3.1 from C:\dev\tools\Python\Python312\Lib\site-packages\pip (python 3.12)
scons
scons は Cmake と同様、コンパイラに依存しないビルド自動化ツール。
scons は python で実装されていて、Python3 を必要とする。ここでは前項で python3 がインストール済みである前提とする。
scons のインストールは pip を用いて簡単にできる。pip とは Python のパッケージ管理システムであり、パッケージソフトウェアをインストール・管理する。多くの Python パッケージは、Python Package Index 上にある。 pipは Python 3.4以降からデフォルトで付属するようになった。
先ず PATH を通し、pip を更新しておく。
c:\dev>SET PATH=C:\dev\tools\Python\Python312\Scripts;C:\dev\tools\Python\Python312;%PATH%
C:\dev>python -m pip install --upgrade pip
Requirement already satisfied: pip in .\tools\python\python312\lib\site-packages (23.2.1)
Collecting pip
Obtaining dependency information for pip from https://files.pythonhosted.org/packages/47/6a/453160888fab7c6a432a6e25f8afe6256d0d9f2cbd25971021da6491d899/pip-23.3.1-py3-none-any.whl.metadata
Downloading pip-23.3.1-py3-none-any.whl.metadata (3.5 kB)
Using cached pip-23.3.1-py3-none-any.whl (2.1 MB)
Installing collected packages: pip
Attempting uninstall: pip
Found existing installation: pip 23.2.1
Uninstalling pip-23.2.1:
Successfully uninstalled pip-23.2.1
Successfully installed pip-23.3.1
c:\dev>
pip が最新になった後、pip により scons をインストールする。
c:\dev>python -m pip install scons Collecting scons Obtaining dependency information for scons from https://files.pythonhosted.org/packages/84/cc/bd930d748822161f7f3a0c939baf50a6a7cd8cae825470571dcde6489a70/SCons-4.6.0-py3-none-any.whl.metadata Downloading SCons-4.6.0-py3-none-any.whl.metadata (9.0 kB) Collecting setuptools (from scons) Obtaining dependency information for setuptools from https://files.pythonhosted.org/packages/bb/e1/ed2dd0850446b8697ad28d118df885ad04140c64ace06c4bd559f7c8a94f/setuptools-69.0.2-py3-none-any.whl.metadata Downloading setuptools-69.0.2-py3-none-any.whl.metadata (6.3 kB) Downloading SCons-4.6.0-py3-none-any.whl (4.3 MB) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4.3/4.3 MB 11.9 MB/s eta 0:00:00 Downloading setuptools-69.0.2-py3-none-any.whl (819 kB) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 819.5/819.5 kB 12.8 MB/s eta 0:00:00 Installing collected packages: setuptools, scons Successfully installed scons-4.6.0 setuptools-69.0.2
scons （に限らず pip でインストールした python モジュール）は .\Scripts ディレクトリにインストールされる。今回の場合は以下のディレクトリになる。
C:\dev\tools\Python\Python312\Scripts
scons を使う場合は、python を使う場合と同様に、以下の PATH を一時的に環境変数 PATH に追加する。
C:\dev\tools\Python\Python312\Scripts C:\dev\tools\Python\Python312
具体的には以下のようにする。
c:\dev>SET PATH=C:\dev\tools\Python\Python312\Scripts;C:\dev\tools\Python\Python312;%PATH% c:\dev>scons --help usage: scons [OPTIONS] [VARIABLES] [TARGETS] SCons Options: -c, --clean, --remove Remove specified targets and dependencies -C DIR, --directory=DIR Change to DIR before doing anything --cache-debug=FILE Print CacheDir debug info to FILE ～ 以後長いので省略 ～ c:\dev>
MinGW-w64
MinGW-w64 は以下のサイトで配布されている。
インストール方法はいくつかあるようだが、ここでは配布アーカイブファイルからインストールする。
先ず、サイトを開く。
左メニューにある “Download” リンクを開く。
MinGW-w64-builds のリンクを左クリックすると、同じページの該当部分に飛ぶ。
“Mingw-builds” の項目に ”Installation: GitHub”の項目がある。この “GitHub” の部分がリンクになっているので左クリックするとダウンロードページに飛ぶ。
ダウンロードページは例えば以下のようになっていて、色々な種類の 7-zip アーカイブファイルをダウンロードすることができる。
選択肢として以下がある。
i686-13.2.0-release-posix-dwarf-msvcrt-rt_v11-rev0.7z i686-13.2.0-release-posix-dwarf-ucrt-rt_v11-rev0.7z i686-13.2.0-release-win32-dwarf-msvcrt-rt_v11-rev0.7z i686-13.2.0-release-win32-dwarf-ucrt-rt_v11-rev0.7z x86_64-13.2.0-release-posix-seh-msvcrt-rt_v11-rev0.7z x86_64-13.2.0-release-posix-seh-ucrt-rt_v11-rev0.7z x86_64-13.2.0-release-win32-seh-msvcrt-rt_v11-rev0.7z x86_64-13.2.0-release-win32-seh-ucrt-rt_v11-rev0.7z
“i686” がつくものは（分かりにくいが）32bit ターゲット用で、32bit コードを出力する。MinGW-w64 は mingw の64bit 環境用のビルドチェーンであるが、32bit コードを出力するビルドチェーンも用意されている。Godot は Windows の 32bit コードターゲットもサポートしていて、32bit コード用を生成する場合は “i686” がつくものを選ぶことになる。
より多くのユーザーに自作のゲームを楽しんでもらいたいと考えた場合、32bit ターゲット用も必要かもしれない。しかし Windows11 には 32bit 版は存在せず、Windows10 の 32bit 版は今となってはむしろ希少な存在。このような昨今のPC事情を鑑みれば、32bit ターゲットを考える必要性は低いだろう。
64bit ターゲット用は “x86_64” が付く。
“posix” と “win32” とがつくものがあるが、これはスレッドモデルの違いを意味する。Godot のマニュアルには “posix thred model” を使用する旨の指示がある。
“dwarf” と “seh” は例外モデルの違いであるが、”i686″ は “dwarf”、”x86_64” は “seh” の組み合わせしかない。
“msvcrt” と “ucrt” とがつくものがあるが、これはリンクする CRT（C標準のランタイムライブラリ） の実装の違いで、”msvcrt” の方が古く、”ucrt” の方が新しい。どちらを選んでも大差ないが、依存するダイナミックリンクライブラリ (.dll) ファイルが変わる。”ucrt” で Godot エンジンと GDEXTENSION を再コンパイルしても特に違和感なく使えているので、”ucrt” を選んでも良いと思われる。しかしデフォルトの Godot エンジンは “msvcrt” をリンクしている。
余談だが、ある実行ファイル（もしくはダイナミックリンクライブラリ）が必要とするダイナミックライブラリは MinGw-64 同梱の objdump を用いて、以下のようにして調べることができる。
objdump -p hoge.exe | findstr /i "\.dll" objdump -p huga.dll | findstr /i "\.dll"
例えば、Godot_v4.2.1-stable_win64.exe を調べたたければ以下となる。
c:\dev>SET PATH=C:\dev\tools\mingw64\bin;%PATH%
c:\dev>objdump -p c:\godot\Godot_v4.2.1-stable_win64.exe\Godot_v4.2.1-stable_win64.exe | findstr /i "\.dll"
DLL Name: ADVAPI32.dll
DLL Name: AVRT.dll
DLL Name: bcrypt.dll
DLL Name: CRYPT32.dll
DLL Name: dbghelp.dll
DLL Name: DINPUT8.dll
DLL Name: dwmapi.dll
DLL Name: DWrite.dll
DLL Name: dxgi.dll
DLL Name: GDI32.dll
DLL Name: IMM32.dll
DLL Name: IPHLPAPI.DLL
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll <- msvcrt が使われている
DLL Name: ntdll.dll
DLL Name: ole32.dll
DLL Name: OLEAUT32.dll
DLL Name: SHELL32.dll
DLL Name: SHLWAPI.dll
DLL Name: USER32.dll
DLL Name: WINMM.dll
DLL Name: WS2_32.dll
DLL Name: WSOCK32.dll
c:\dev>
あえて Godot エンジンのデフォルト選択から変える理由もないので “msvcrt” を選択するので良いだろう。
尚、GODOT エンジンで用いられている CRT が未来永劫 “msvcrt” であるかは分からない。もし将来、自作の GDEXTENSION プラグインを配布するならば、ターゲットバージョンの GODOT エンジンエディターがリンクする CRT を調べて、使われている方に合わせた方がよいだろう。上記のように objdump を用いれば簡単に依存しているダイナミックリンクライブラリを調査することができるので、都度調査しても然程の手間ではない。
以上を踏まえて 64bit ターゲットの場合は以下を選択する。
x86_64-13.2.0-release-posix-seh-msvcrt-rt_v11-rev0.7z
試したことは無いが、32bit ターゲットの場合は以下を選択することになろうかと思われる。
i686-13.2.0-release-posix-dwarf-msvcrt-rt_v11-rev0.7z
注意：
Norton などのセキュリティソフトの一部は、MinGW-w64 のツールチェーン実行バイナリファイルをウイルスとして隔離してしまうことが確認されている。インストール作業を行っても bin ディレクトリに実行バイナリファイルが無くなってしまっている場合はこれを疑うと良い。MinGW-w64 が実際にウイルスであるか否かは各々のが判断すべきではあるが、もし誤動作であると判断するならば、MinGW-w64 のインストールディレクトリをセキュリティソフトによる隔離対象から外す設定を行うと良いかもしれない。
インストールはコマンドプロンプトを使って行う場合、例えば以下のようにする。
c:\dev\tools>curl -L -O https://github.com/niXman/mingw-builds-binaries/releases/download/13.2.0-rt_v11-rev0/x86_64-13.2.0-release-posix-seh-msvcrt-rt_v11-rev0.7z c:\dev\tools>"C:\Program Files\7-Zip\7z.exe" x x86_64-13.2.0-release-posix-seh-msvcrt-rt_v11-rev0.7z c:\dev\tools>del x86_64-13.2.0-release-posix-seh-msvcrt-rt_v11-rev0.7z c:\dev\tools>rename mingw64 mingw64-13.2.0-posix-seh-msvcrt-rt_v11-rev0
ここではインストールディレクトリは以下としている。
c:\dev\tools\mingw64
使用する際は以下のようにして PATH を通しておく。
SET PATH=C:\dev\tools\mingw64\bin;%PATH%
以下のようにコマンドプロンプトで g++ が実行できればインストール成功。
c:\dev\tools>g++ --version g++ (x86_64-posix-seh-rev0, Built by MinGW-Builds project) 13.2.0 Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. c:\dev\tools>
pkg-config
pkg-config はライブラリパッケージをビルドする際に用いるビルドオプションを生成するためのツール。
大規模ライブラリの場合、依存関係が複雑すぎて手入力でビルドオプションを指定することが現実的ではない。よってライブラリ作成者はライブラリを用いる際に必要となるビルドオプションを提供する手段を用意してくれている場合が多い。pkg-config はそれらに用いられる手段の一つ。
pkg-configのインストールは例えば以下のようにする。
c:\dev\tools>mkdir pkg-config c:\dev\tools>cd pkg-config c:\dev\tools\pkg-config>curl -L -O https://download.gnome.org/binaries/win64/glib/2.26/glib_2.26.1-1_win64.zip c:\dev\tools\pkg-config>curl -L -O https://download.gnome.org/binaries/win64/dependencies/gettext-runtime_0.18.1.1-2_win64.zip c:\dev\tools\pkg-config>curl -L -O https://download.gnome.org/binaries/win64/dependencies/pkg-config_0.23-2_win64.zip c:\dev\tools\pkg-config>"C:\Program Files\7-Zip\7z.exe" x glib_2.26.1-1_win64.zip c:\dev\tools\pkg-config>del gettext-runtime_0.18.1.1-2_win64.zip c:\dev\tools\pkg-config>"C:\Program Files\7-Zip\7z.exe" x gettext-runtime_0.18.1.1-2_win64.zip c:\dev\tools\pkg-config>del gettext-runtime_0.18.1.1-2_win64.zip c:\dev\tools\pkg-config>"C:\Program Files\7-Zip\7z.exe" x pkg-config_0.23-2_win64.zip c:\dev\tools\pkg-config>del glib_2.26.1-1_win64.zip C:\dev>
以上の手順で “C:\dev\tools\pkg-config\bin” に pkg-config の実行ファイルが格納される。使用するためには PATH を通さなければならない。
C:\dev>SET PATH=%PATH%;C:\dev\tools\pkg-config\bin C:\dev>pkg-config --version 0.23 C:\dev>
ただし、後述するが pkg-config は scons から使用し、 scons では PATH は別途指定する。よって、コマンドプロンプトで pkg-config コマンドを手打ちすることはあまりないので、DOS窓用に pkg-config の PATH を通す必要性は少ない。
LLVM
pcl などの一部のライブラリパッケージには Clang Format を必要とする。Clang Format を windows環境で最も簡便に導入する方法は LLVM をインストールすること。
LLVM は、仮想機械向けコードを出力するコンパイラ基盤であり、Clang などは LLVM の出力コードを現実の PC/OS アーキテクチャ向けに変換をかけることにより、各種の言語コンパイラ／ビルドチェーンとして機能する。
LLVM の配布サイトは以下。
このサイトから Windows installer (64-bit) を入手し LLVM をインストールする。普通にインストール手順を進めると LLVM は C:/Program Files/LLVM/ にインストールされ、以下のファイルが格納される。
C:/Program Files/LLVM/bin/clang-format.exe
“C:/Program Files/LLVM/bin” のディレクトリにパスが通っている必要がある。
MinGW-w64 を用いた Windows アプリケーションのビルドだけを考えた場合、LLVM 全体は冗長であるので、たとえば C:/Program Files/LLVM/bin/clang-format.exe だけをc:\dev\tools 配下の適当なディレクトリにコピーしてLLVMそのものはアンインストールしても良いかもしれない。
しかし、LLVM は WEB ターゲットでのビルドを考えた場合、Emscripten が用いるので、WEB ターゲットに興味があるならばアンインストールせずに残しておいても良い。
ライブラリ管理
C++ ライブラリをビルドした際の格納先
ビルド済み C++ ライブラリはビルドに用いたビルドツールチェーンに紐づく。特に GDEXTENSION の場合、mingw64, mingw32, android, web といったクロス開発環境での開発になることが予想されるので、ビルド済みライブラリの格納先を決める必要がある。
ここではビルドツールのインストールルートディレクトリ直下に local というディレクトリを作成し、その中に opencv-4.8 などのディレクトリを作成し、ビルド済みライブラリを格納することを提案する。
c:\dev\tools\mingw64>mkdir local
以下のように Cmake 用の環境変数 CMAKE_PREFIX_PATH を通しておけば、ビルド済のライブラリを Cmake で find_package を行う際の検索対象にするので、find_package ライブラリが見つけやすくなる効果が期待できる。
SET CMAKE_PREFIX_PATH=C:\dev\tools\mingw64\local
PATH 設定用 バッチファイルの設置
コマンドプロンプトを起動した際のディレクトリである %HOMEPATH% のディレクトリに以下のバッチファイルを設置しておく。（このファイルは記事が進むにつれて成長してゆく。）
%HOMEPATH%\mingw64.bat
SET PATH=%PATH%;"C:\Program Files\7-Zip"
SET PATH=%PATH%;C:\dev\tools\pkg-config\bin
SET PATH=C:\dev\tools\Python\Python312\Scripts;C:\dev\tools\Python\Python312;%PATH%
SET PATH=C:\dev\tools\mingw64\bin;%PATH%
SET CMAKE_PREFIX_PATH=C:\dev\tools\mingw64\local
SET PATH=%PATH%;C:\dev\tools\mingw64\local
cd c:\dev
そしてコマンドプロンプトを起動したタイミングで以下を実行すれば、MinGW-w64 を用いた開発環境のパスを通すことができる。
Microsoft Windows [Version 10.0.22631.2792] (c) Microsoft Corporation. All rights reserved. C:\Users\kano>.\mingw64 C:\dev>
逆に他の用途でコマンドプロンプトを開いた場合、mingw64.bat を実行しなければ余計な PATH が通っていない状態を維持できる。
本稿の振り返りと次稿について
ということで、いまだ Godot の影も現れないまま（その１）は終わる。本稿ではGDEXTENSION 開発の全体方針とディレクトリ構造を決め、必要なツール類の準備を行った。scons を用いた C++ ライブラリ利用として pkg-config が非常に重要な役割を持つ。
（その２）では Godot エンジンエディッタのビルドと、Microsoft Visual Code を用いたデバッグ環境の設定を整える。
ということで（その２）に続く。
コメント