ビルドシステムの説明

SCons

Godotはビルドするために SCons を使用しています。私たちはSconsが大好きなので、他のものに変えるつもりはありません。他のビルドシステムがGodotのビルドに適しているかどうかさえ、確信がありません。ビルドシステムをCMakeやVisual Studioに変更してほしいというリクエストをよく受けますが、起こり得ないことです。他のシステムではなくSConsを選ぶのには、多くの理由があります。例えば:

• Godotは十種類以上のプラットフォームを対象にコンパイルできます: すべてのPCプラットフォーム、すべてのモバイルプラットフォーム、多くのコンソール機、およびWebAssembly。

• 開発者は、多くの場合、複数のプラットフォームを同時にコンパイルする必要があります、または同じプラットフォームの異なるターゲットをコンパイルする必要があります。毎回プロジェクトを再構成して再構築する余裕はありません。SConsは、ビルドを壊すことなく、労なくこれを行うことができます。

• 変更、構成、追加、削除などの回数にかかわらず、SConsはビルドを中断することはありません。SConsでクリーニングとリビルドを行うよりも、落雷で死亡する可能性の方が高くなります。

• Godotビルドプロセスは簡単ではありません。いくつかのファイルはコード(バインダー)によって生成され、他のファイルは解析(シェーダー)であり、他のファイルはカスタマイズ(プラグイン)を提供する必要があります。これには、構築のみを意図したマクロベースの言語を使用するのではなく、実際のプログラミング言語(Pythonなど)で記述する方が簡単な複雑なロジックが必要です。

• Godotのビルド処理はクロスコンパイル ツールを多用しています。それぞれのプラットフォームには専用の検査処理があり、またそれらすべてを個別の問題として、専用のコードでもって対処しなければなりません。

ですので、もしGodotを自分でビルドすることを計画している場合は、オープンマインドを持って、SConsに多少は触れてみてください。

セットアップ

以下のドキュメントを参照して下さい: Android用のコンパイル 、 iOS用のコンパイル 、 macOS へのコンパイル、ユニバーサルWindowsプラットフォームのコンパイル、Web用のコンパイル、 Windows用のコンパイル 及び X11のコンパイル (Linux、*BSD)。

Windows/Visual Studio の場合、以下のコマンドを入力するには、標準のWindowsコマンドプロンプトではなく、インストールに応じてx86_x64Cross Tools Command Prompt for VS2017または同様のコマンドプロンプトを使用する必要があります。

プラットフォームの選択

Godot のビルドシステムは、ビルド可能なプラットフォームを検出することによって開始されます。検出されない場合、使用可能なプラットフォームの一覧に表示されません。各プラットフォームのビルド要件については、このチュートリアルの残りの部分で説明します。

SCons はsconsを呼ぶだけで起動します。もしプラットフォームが指定されなければ、SConsはホスト プラットフォームを自動的に検出してターゲット プラットフォームとします。それからすぐにターゲット プラットフォームへのビルドを開始します。

利用可能なターゲット プラットフォームのリストを得るには、scons platform=listを使います:

scons platform=list
scons: Reading SConscript files ...
The following platforms are available:

    android
    javascript
    server
    windows
    x11

Please run SCons again and select a valid platform: platform=<string>

特定のプラットフォーム (たとえばX11) にビルドするには、引数としてplatform= (あるいはその短縮形p=) を付けて実行します:

scons platform=x11

これでビルド プロセスが開始しますが、多少の時間がかかります。Sconsでのビルドを高速化したいなら、-j <コア数>パラメータを使えば、ビルドに使用するコア数を指定できます。もしくは、使うコアを一つだけのままにすれば、その間コンピューターを別のことに使うことができるでしょう :)

4つのコアを使用する例:

scons platform=x11 -j 4

結果のバイナリ

結果のバイナリは副ディレクトリのbin/に、通常は以下の命名規則に沿って保存されます:

godot.<platform>.[opt].[tools/debug].<architecture>[extension]

前記のビルドを試みると、結果は次のようになります:

ls bin
bin/godot.x11.tools.64

これは、バイナリがX11用であり、最適化されておらず、ツール(エディタ全体)が組み込まれており、64ビット用であることを意味します。

A Windows binary with the same configuration will look like this:

C:\godot> dir bin/
godot.windows.tools.64.exe

このバイナリには、プロジェクト マネージャ、エディタ、そしてゲームの実行に必要なものすべてが含まれているので、好きな場所にコピーしてください。しかしこのバイナリには、他のプラットフォームへエクスポートするためのデータは含まれません。それには、エクスポート テンプレートが必要になります (godotengine.org からダウンロードするか、または自身でビルドしてください)。

それとは別に、すべてのビルドターゲットで設定できるいくつかの標準オプションがあり、以下で説明します。

ツール

ツールは、すべてのPCターゲット(Linux、Windows、macOS)でデフォルトで有効になっています。ツールを無効にすると、プロジェクトを実行できるバイナリが生成されますが、編集者やプロジェクト マネージャは含まれません。

scons platform=<platform> tools=yes/no

ターゲット

ターゲットは最適化フラグとデバッグフラグを制御します。各モードの意味は次のとおりです:

• debug: C++デバッグシンボル、ランタイムチェック (チェックを実行してエラーを通知する) を使用して、最適化は最小限でビルドします。

• release_debug: C++デバッグ シンボルは無効になり、最適化してビルドされますが、ランタイム チェック (チェックを実行してエラーを通知する) は行われます。公式エディタ バイナリはこの設定を使用しています。

• release: シンボルは無効になり、最適化された上、ランタイム チェックは最小限でビルドされます。エディタにはいくつかのデバッグ機能とランタイム チェックを必要なので、このターゲットはtool=yesと同時に使うことはできません。

scons platform=<platform> target=debug/release_debug/release

このフラグは、ファイル名に.debug(debug版)、あるいは.tools(tool有効のdebug版) を追加します。最適化が有効なとき (release) は、.optを追加します。

ビット

ビットは、バイナリを実行するCPUまたはOSのバージョンを制御するためのものです。主にデスクトッププラットフォームに焦点が当てられており、それ以外の場所では無視されています。

• 32: 32ビット プラットフォーム用のバイナリをビルド。

• 64: 64ビット プラットフォーム用のバイナルをビルド。

• default: ホスト プラットフォームのアーキテクチャに合わせてビルド。

scons platform=<platform> bits=default/32/64

このフラグは、出力されたバイナリの名前に.32あるいは.64を対象によって加えます。もしbits=defaultの場合には、検出されたアーキテクチャに適したほうを追加します。

Custom modules

It's possible to compile modules residing outside of Godot's directory tree, along with the built-in modules.

A custom_modules build option can be passed to the command line before compiling. The option represents a comma-separated list of directory paths containing a collection of independent C++ modules that can be seen as C++ packages, just like the built-in modules/ directory.

For instance, it's possible to provide both relative, absolute, and user directory paths containing such modules:

scons custom_modules="../modules,/abs/path/to/modules,~/src/godot_modules"

注釈

If there's any custom module with the exact directory name as a built-in module, the engine will only compile the custom one. This logic can be used to override built-in module implementations.

参考

C++のカスタムモジュール

Cleaning generated files

Sometimes, you may encounter an error due to generated files being present. You can remove them by using scons --clean <options>, where <options> is the list of build options you've used to build Godot previously.

Alternatively, you can use git clean -fixd which will clean build artifacts for all platforms and configurations. Beware, as this will remove all untracked and ignored files in the repository. Don't run this command if you have uncommitted work!

その他のビルドオプション

Godotのビルド方法 (コンパイラ、デバッグ オプションなど)と、インクルード/無効化する機能を構成するために使用できるビルドオプションは他にもいくつかあります。

コンパイルするバージョンの各オプションの詳細については、 scons --help の出力を確認してください。

Overriding the build options

Using a file

The default custom.py file can be created at the root of the Godot Engine source to initialize any SCons build options passed via the command line:

# custom.py

optimize = "size"
module_mono_enabled = "yes"
use_llvm = "yes"
extra_suffix = "game_title"

You can also disable some of the builtin modules before compiling, saving some time it takes to build the engine. See ビルドのサイズを最適化する page for more details.

参考

You can use the online Godot build options generator to generate a custom.py file containing SCons options. You can then save this file and place it at the root of your Godot source directory.

Another custom file can be specified explicitly with the profile command line option, both overriding the default build configuration:

scons profile=path/to/custom.py

注釈

Build options set from the file can be overridden by the command line options.

条件に応じてオプションをオーバーライドすることもできます:

# custom.py

import version

# Override options specific for Godot 3.x and 4.x versions.
if version.major == 3:
    pass
elif version.major == 4:
    pass

Using the SCONSFLAGS

SCONSFLAGS is an environment variable which is used by the SCons to set the options automatically without having to supply them via the command line.

For instance, you may want to build Godot in parallel with the aforementioned -j option for all the future builds:

Linux/macOSWindows (cmd)Windows (powershell)

export SCONSFLAGS="-j4"

エクスポートテンプレート

公式エクスポートテンプレートは、Godot Engineサイトからダウンロードできます: godotengine.org。ただし、新しいモジュールが必要な場合、カスタム モジュールを使用している場合、または単に自身の影すらも信用しない主義であるなら、自分でビルドすることもできます。

公式のエクスポート テンプレートのパッケージをダウンロードして解凍すれば、そのほとんどのファイルは、最適化されたバイナリかパッケージであることに気づくでしょう:

android_debug.apk
android_release.apk
webassembly_debug.zip
webassembly_release.zip
linux_server_32
linux_server_64
linux_x11_32_debug
linux_x11_32_release
linux_x11_64_debug
linux_x11_64_release
osx.zip
version.txt
windows_32_debug.exe
windows_32_release.exe
windows_64_debug.exe
windows_64_release.exe

これらを自分で作るには、このチュートリアル セクションにある、それぞれのプラットフォーム用の解説をお読みください。それぞれのプラットフォームにて、エクスポート テンプレートの作成法が書かれています。

version.txt ファイルには、対応する Godot のバージョン識別子を含める必要があります。このファイルは、バージョン専用のディレクトリにエクスポート テンプレートをインストールして、名前の衝突を避けるためにあります。一例として、もし Godot 3.1.1 用のエクスポート テンプレートをビルドするなら、version.txtの最初の行に3.1.1.stableと書きます (それ以外は不要)。このバージョン識別子を構成するのは、メジャー、マイナー、パッチ(ある場合)、そしてGodot の Git レポジトリにある version.pyファイルのstatusラインです。

もし複数のプラットフォームに向けて開発するなら、間違いなく macOS が一番実用的なクロスコンパイルのためのホスト プラットフォームでしょう。ほぼ全てのターゲット (UWPを除く) にクロスコンパイルできます。Linux と Windows がその次に来ますが、しかし、Linux にはセットアップが容易であるという利点があります。