Introduction au buildsystem


Godot uses SCons to build. We love it, we are not changing it for anything else. We are not even sure other build systems are up to the task of building Godot. We constantly get requests to move the build system to CMake, or Visual Studio, but this is not going to happen. There are many reasons why we have chosen SCons over other alternatives, for example:

  • Godot peut être compilé pour une douzaine de plates-formes différentes : toutes les plates-formes PC, toutes les plates-formes mobiles, de nombreuses consoles, et WebAssembly.
  • Developers often need to compile for several of the platforms at the same time, or even different targets of the same platform. They can’t afford reconfiguring and rebuilding the project each time. SCons can do this with no sweat, without breaking the builds.
  • SCons will never break a build no matter how many changes, configurations, additions, removals etc. You have more chances to die struck by lightning than needing to clean and rebuild in SCons.
  • Godot build process is not simple. Several files are generated by code (binders), others are parsed (shaders), and others need to offer customization (plugins). This requires complex logic which is easier to write in an actual programming language (like Python) rather than using a mostly macro-based language only meant for building.
  • Le processus de construction Godot fait un usage intensif des outils de compilation croisée. Chaque plate-forme dispose d’un processus de détection spécifique, et tous ces éléments doivent être traités comme des cas spécifiques avec un code spécial écrit pour chacun.

Donc, s’il vous plaît essayer de garder un esprit ouvert et soyez au moins un peu familier avec si vous envisagez de builder Godot vous-même.


Please refer to the documentation for Compiling for Android, Compiling for iOS, Compiler pour macOS, Compiling for Universal Windows Platform, Compiling for the Web, Compiling for Windows and Compiling for X11 (Linux, *BSD).

Note that for Windows/Visual Studio, you need to use x86_x64 Cross Tools Command Prompt for VS 2017 or similar, depending on your install, instead of the standard Windows command prompt to enter the commands below.

Choix de la plate-forme

Godot’s build system will begin by detecting the platforms it can build for. If not detected, the platform will simply not appear on the list of available platforms. The build requirements for each platform are described in the rest of this tutorial section.

SCons is invoked by just calling scons. If no platform is specified, SCons will detect the target platform automatically based on the host platform. It will then start building for the target platform right away.

Pour lister les plates-formes cibles disponibles, utilisez scons platform=list :

[email protected]:~/godot$ scons platform=list
scons: Reading SConscript files ...
The following platforms are available:


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

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

[email protected]:~/godot$ scons platform=x11

This will start the build process, which will take a while. If you want SCons to build faster, use the -j <cores> parameter to specify how many cores will be used for the build. Or leave it using one core, so you can use your computer for something else :)

Exemple pour l’utilisation de 4 cœurs :

[email protected]:~/godot$ scons platform=x11 -j 4

Binaire résultant

The resulting binaries will be placed in the bin/ subdirectory, generally with this naming convention:


Pour la précédente tentative de compilation, le résultat serait le suivant :

[email protected]:~/godot$ ls bin

This means that the binary is for X11, is not optimized, has tools (the whole editor) compiled in, and is meant for 64 bits.

Un binaire Windows avec la même configuration ressemblera à ceci :

C:\godot> dir bin/

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, or you can build them yourself).

En dehors de cela, il y a quelques options standard qui peuvent être définies dans toutes les cibles de build, et qui seront expliquées ci-dessous.


Les outils sont activés par défaut dans toutes les cibles PC (Linux, Windows, macOS), désactivés pour tout le reste. Désactiver les outils produit un binaire qui peut exécuter des projets, mais qui n’inclut pas l’éditeur ou le gestionnaire de projet.

scons platform=<platform> tools=yes/no


La cible contrôle l’optimisation et débogue les drapeaux. Chaque mode signifie :

  • debug: Build with C++ debugging symbols, runtime checks (performs checks and reports error) and none to little optimization.
  • release_debug: Build without C++ debugging symbols and optimization, but keep the runtime checks (performs checks and reports errors). Official editor binaries use this configuration.
  • release: Build without symbols, with optimization and with little to no runtime checks. This target can’t be used together with tools=yes, as the editor requires some debug functionality and run-time checks to run.
scons platform=<platform> target=debug/release_debug/release

This flag appends the .debug suffix (for debug), or .tools (for debug with tools enabled). When optimization is enabled (release), it appends the .opt suffix.


Bits 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.

  • 32: Build binaries for 32-bit platforms.
  • 64: Build binaries for 64-bit platforms.
  • default: Build for the architecture that matches the host platform.
scons platform=<platform> bits=default/32/64

This flag appends .32 or .64 suffixes to resulting binaries when relevant. If bits=default is used, the suffix will match the detected architecture.

Other build options

There are several other build options that you can use to configure the way Godot should be built (compiler, debug options, etc.) as well as the features to include/disable.

Check the output of scons --help for details about each option for the version you are willing to compile.

Exporter des modèles

Official export templates are downloaded from the Godot Engine site: However, you might want to build them yourself (in case you want newer ones, you are using custom modules, or simply don’t trust your own shadow).

If you download the official export templates package and unzip it, you will notice that most files are optimized binaries or packages for each platform:


To create those yourself, follow the instructions detailed for each platform in this same tutorial section. Each platform explains how to create its own template.

The version.txt file should contain the corresponding Godot version identifier. This file is used to install export templates in a version-specific directory to avoid conflicts. For instance, if you are building export templates for Godot 3.1.1, version.txt should contain 3.1.1.stable on the first line (and nothing else). This version identifier is based on the major, minor, patch (if present) and status lines of the file in the Godot Git repository.

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