Up to date

This page is up to date for Godot 4.2. If you still find outdated information, please open an issue.

ビルドシステムの説明

Godot is a primarily C++ project and it uses the SCons build system. We love SCons for how maintainable and easy to set up it makes our buildsystem. And thanks to that compiling Godot from source can be as simple as running:

scons

This produces an export template for your current platform, operating system, and architecture. An export template is a build of the engine that is used for running exported projects. To build the editor instead you can run the following command:

scons target=editor

If you plan to debug or develop the engine, then you might want to add another option to the command:

scons dev_build=yes
scons target=editor dev_build=yes

Following sections in the article will explain these and other universal options in more detail. But before you can compile Godot, you need to install a few prerequisites. Please refer to the platform documentation to learn more:

• Android用のコンパイル

• iOS用のコンパイル

• Compiling for Linux, *BSD

• macOS へのコンパイル

• Web用のコンパイル

• Windows用のコンパイル

These articles cover in great detail both how to setup your environment to compile Godot on a specific platform, and how to compile for that platform. Please feel free to go back and forth between them and this article to reference platform-specific and universal configuration options.

Using multi-threading

The build process may take a while, depending on how powerful your system is. By default, Godot's SCons setup is configured to use all CPU threads but one (to keep the system responsive during compilation). If you want to adjust how many CPU threads SCons will use, use the -j <threads> parameter to specify how many threads will be used for the build.

Example for using 4 threads:

scons -j4

プラットフォームの選択

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

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

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

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

    android
    javascript
    linuxbsd
    server
    windows

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

To build for a platform (for example, linuxbsd), run with the platform= (or p= to make it short) argument:

scons platform=linuxbsd

結果のバイナリ

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

godot.<platform>.<target>[.dev][.double].<arch>[.<extra_suffix>][.<ext>]

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

ls bin
bin/godot.linuxbsd.editor.x86_64

This means that the binary is for Linux or *BSD (not both), is not optimized, has the whole editor compiled in, and is meant for 64 bits.

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

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

Copy that binary to any location you like, as it contains the Project Manager, editor and all means to execute the game. However, it lacks the data to export it to the different platforms. For that the export templates are needed (which can be either downloaded from godotengine.org, or you can build them yourself).

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

ターゲット

Target controls if the editor is contained and debug flags are used. All builds are optimized. Each mode means:

• target=editor: Build with editor, optimized, with debugging code (defines: TOOLS_ENABLED, DEBUG_ENABLED, -O2//O2)

• target=template_debug: Build with C++ debugging symbols (defines: DEBUG_ENABLED, -O2//O2)

• target=template_release: Build without symbols (defines: -O3//O2)

The editor is enabled by default in all PC targets (Linux, Windows, macOS), disabled for everything else. Disabling the editor produces a binary that can run projects but does not include the editor or the Project Manager.

scons platform=<platform> target=editor/template_debug/template_release

Development and production aliases

When creating builds for development (running debugging/profiling tools), you often have different goals compared to production builds (making binaries as fast and small as possible).

Godot provides two aliases for this purpose:

• dev_mode=yes is an alias for verbose=yes warnings=extra werror=yes tests=yes. This enables warnings-as-errors behavior (similar to Godot's continuous integration setup) and also builds unit tests so you can run them locally.

• production=yes is an alias for use_static_cpp=yes debug_symbols=no lto=auto. Statically linking libstdc++ allows for better binary portability when compiling for Linux. This alias also enables link-time optimization when compiling for Linux, Web and Windows with MinGW, but keeps LTO disabled when compiling for macOS, iOS or Windows with MSVC. This is because LTO on those platforms is very slow to link or has issues with the generated code.

You can manually override options from those aliases by specifying them on the same command line with different values. For example, you can use scons production=yes debug_symbols=yes to create production-optimized binaries with debugging symbols included.

Dev build

注釈

dev_build should not be confused with dev_mode, which is an alias for several development-related options (see above).

When doing engine development the dev_build option can be used together with target to enable dev-specific code. dev_build defines DEV_ENABLED, disables optimization (-O0//0d), enables generating debug symbols, and does not define NDEBUG (so assert() works in thirdparty libraries).

scons platform=<platform> dev_build=yes

This flag appends the .dev suffix (for development) to the generated binary name.

参考

There are additional SCons options to enable sanitizers, which are tools you can enable at compile-time to better debug certain engine issues. See Using sanitizers for more information.

Debugging symbols

By default, debug_symbols=no is used, which means no debugging symbols are included in compiled binaries. Use debug_symbols=yes to include debug symbols within compiled binaries, which allows debuggers and profilers to work correctly. Debugging symbols are also required for Godot's crash stacktraces to display with references to source code files and lines.

The downside is that debugging symbols are large files (significantly larger than the binaries themselves). As a result, official binaries currently do not include debugging symbols. This means you need to compile Godot yourself to have access to debugging symbols.

When using debug_symbols=yes, you can also use separate_debug_symbols=yes to put debug information in a separate file with a .debug suffix. This allows distributing both files independently. Note that on Windows, when compiling with MSVC, debugging information is always written to a separate .pdb file regardless of separate_debug_symbols.

ちなみに

Use the strip <path/to/binary> command to remove debugging symbols from a binary you've already compiled.

Optimization level

Several compiler optimization levels can be chosen from:

• optimize=speed_trace (default when targeting non-Web platforms): Favors execution speed at the cost of larger binary size. Optimizations may sometimes negatively impact debugger usage (stack traces may be less accurate. If this occurs to you, use optimize=debug instead.

• optimize=speed: Favors even more execution speed, at the cost of even larger binary size compared to optimize=speed_trace. Even less friendly to debugging compared to optimize=debug, as this uses the most aggressive optimizations available.

• optimize=size (default when targeting the Web platform): Favors small binaries at the cost of slower execution speed.

• optimize=debug: Only enables optimizations that do not impact debugging in any way. This results in faster binaries than optimize=none, but slower binaries than optimize=speed_trace.

• optimize=none: Do not perform any optimization. This provides the fastest build times, but the slowest execution times.

• optimize=custom (advanced users only): Do not pass optimization arguments to the C/C++ compilers. You will have to pass arguments manually using the CFLAGS, CCFLAGS and CXXFLAGS SCons options.

Architecture

The arch option is meant to control the CPU or OS version intended to run the binaries. It is focused mostly on desktop platforms and ignored everywhere else.

Supported values for the arch option are auto, x86_32, x86_64, arm32, arm64, rv64, ppc32, ppc64 and wasm32.

scons platform=<platform> arch={auto|x86_32|x86_64|arm32|arm64|rv64|ppc32|ppc64|wasm32}

This flag appends the value of arch to resulting binaries when relevant. The default value arch=auto detects the architecture that matches the host platform.

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 force a number of CPU threads with the aforementioned -j option for all future builds:

Linux/macOSWindows (cmd)Windows (PowerShell)

export SCONSFLAGS="-j4"

SCU (single compilation unit) build

Regular builds tend to be bottlenecked by including large numbers of headers in each compilation translation unit. Primarily to speed up development (rather than for production builds), Godot offers a "single compilation unit" build (aka "Unity / Jumbo" build).

For the folders accelerated by this option, multiple .cpp files are compiled in each translation unit, so headers can be shared between multiple files, which can dramatically decrease build times.

To make a SCU build, use the scu_build=yes SCons option.

注釈

When developing a Pull Request using SCU builds, be sure to make a regular build prior to submitting the PR. This is because SCU builds by nature include headers from earlier .cpp files in the translation unit, therefore won't catch all the includes you will need in a regular build. The CI will catch these errors but it will usually be faster to catch them on a local build on your machine.

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

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

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

android_debug.apk
android_release.apk
web_debug.zip
web_release.zip
linux_server_32
linux_server_64
linux_x11_32_debug
linux_x11_32_release
linux_x11_64_debug
linux_x11_64_release
macos.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ラインです。

If you are developing for multiple platforms, macOS is definitely the most convenient host platform for cross-compilation, since you can cross-compile for every target. Linux and Windows come in second place, but Linux has the advantage of being the easier platform to set this up.