Introduction au buildsystem

SCons

Godot utilise SCons pour la construction(build). Nous l'aimons, nous ne le changerions pour rien d'autre. Nous ne sommes même pas sûrs que d'autres systèmes de construction soient à la hauteur de la tâche pour construire Godot. Nous recevons constamment des demandes pour déplacer le système de compilation vers CMake, ou Visual Studio, mais cela n'arrivera pas. Il y a de nombreuses raisons pour lesquelles nous avons choisi SCons plutôt que d'autres alternatives, par exemple :

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

• Les développeurs ont souvent besoin de compiler pour plusieurs des plateformes en même temps, ou même différentes cibles de la même plateforme. Ils ne peuvent pas se permettre de reconfigurer et de reconstruire le projet à chaque fois. SCons peut le faire sans problème, sans casser les constructions(builds).

• SCons ne brisera jamais une construction(build), quel que soit le nombre de modifications, de configurations, d'ajouts, de suppressions, etc. Vous avez plus de chances de mourir frappé par la foudre que de devoir nettoyer(clean) et reconstruire(rebuild) avec SCons.

• Le processus de construction(build) de Godot n'est pas simple. Plusieurs fichiers sont générés par du code (binders), d'autres sont analysés (shaders), et d'autres encore doivent offrir de la personnalisation (plugins). Cela nécessite une logique complexe qui est plus facile à écrire dans un langage de programmation réel (comme Python) plutôt que d'utiliser un langage principalement basé sur des macros et uniquement destiné à la construction(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.

Configuration

Veuillez vous référer à la documentation pour Compilation pour Android, Compiler pour iOS, Compiler pour macOS, Compilation pour l'Universal Windows Platform, Compilation pour le Web, Compilation pour Windows et Compilation pour X11 (Linux, *BSD).

Notez que pour Windows/Visual Studio, vous devez utiliser x86_x64 Cross Tools Command Prompt for VS 2017 ou similaire, en fonction de votre installation, au lieu de l'invite de commande standard de Windows pour entrer les commandes ci-dessous.

Choix de la plate-forme

Le système de construction(build) de Godot commencera par détecter les plateformes pour lesquelles il peut construire(build). Si elle n'est pas détectée, la plate-forme n'apparaîtra tout simplement pas dans la liste des plates-formes disponibles. Les exigences de construction(build) pour chaque plateforme sont décrites dans la suite de ce tutoriel.

SCons est invoqué en appelant simplement scons. Si aucune plate-forme n'est spécifiée, SCons détectera automatiquement la plate-forme cible en fonction de la plate-forme hôte. Il commencera alors immédiatement à construire pour la plate-forme cible.

Pour lister les plates-formes cibles disponibles, utilisez 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>

Pour construire pour une plate-forme (par exemple, x11), utilisez l'argument platform= (ou p= pour faire court) :

scons platform=x11

This will start the build process, which will take a while. 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 platform=x11 -j 4

Binaire résultant

Les binaires résultants seront placés dans le sous-répertoire bin/, généralement avec cette convention de nommage :

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

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

ls bin
bin/godot.x11.tools.64

Cela signifie que le binaire est pour X11, n'est pas optimisé, a des outils (l'éditeur entier) compilés dedans, et est prévu pour 64 bits.

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

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

Copiez ce binaire à l'endroit de votre choix, car il contient le gestionnaire de projet, l'éditeur et tous les moyens pour exécuter le jeu. Cependant, il manque les données pour exporter vers les différentes plateformes. Pour cela, les modèles d'exportation sont nécessaires (qui peuvent être téléchargés sur godotengine.org, ou vous pouvez les construire(build) vous-même).

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.

Outils

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

Cible

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

• debug : Construit(build) avec les symboles de débogage C++, les contrôles d'exécution (effectue des contrôles et signale les erreurs) et une optimisation nulle ou faible.

• release_debug : Construire(build) sans symboles de débogage C++ ni optimisation, mais conserve les contrôles d'exécution (effectue les contrôles et signale les erreurs). Les binaires officiels de l'éditeur utilisent cette configuration.

• release : Construire(build) sans symboles, avec optimisation et avec peu ou pas de contrôles d'exécution. Cette cible ne peut pas être utilisée avec tools=yes, car l'éditeur nécessite certaine fonctionnalité de débogage et des vérifications d'exécution pour fonctionner.

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

Ce drapeau ajoute le suffixe .debug (pour débogage), ou .tools (pour débogage avec les outils activés). Lorsque l'optimisation est activée (release), il ajoute le suffixe .opt.

Bits

Bits est destiné à contrôler la version du CPU ou de l'OS destinée à exécuter les binaires. Il est principalement axé sur les plates-formes de bureau et ignoré partout ailleurs.

• 32 : Construire(build) des binaires pour les plates-formes 32 bits.

• 64 : Construire(build) des binaires pour les plates-formes 64 bits.

• par défaut : Construire(build) pour l'architecture qui correspond à la plate-forme hôte.

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

Ce signal concatène les suffixes .32 ou .64 au binaires obtenus si nécessaire. Si bits=default est utilisé, le suffixe correspondra à l'architecture détectée.

Modules personnalisées

Il est possible de compiler des modules résidant à l’extérieur de l’arbre de répertoire de Godot, en même temps que les modules intégrés.

Une option de compilation custom_modules peut être passée à la ligne de commande avant la compilation. L'option représente une liste de chemins de répertoire séparés par des virgules contenant une collection de modules C++ indépendants qui peuvent être considérés comme des paquets C++, tout comme le répertoire intégré modules/.

Par exemple, il est possible de fournir à la fois des chemins d'accès relatifs, absolus et des répertoires utilisateurs contenant de tels modules :

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

Note

S'il existe un module personnalisé avec le nom exact du répertoire comme module intégré, le moteur ne compilera que le module personnalisé. Cette logique peut être utilisée pour passer outre les implémentations de modules intégrés.

Voir aussi

Modules personnalisées en C++

Nettoyage des fichiers générés

Parfois, vous pouvez rencontrer une erreur due à la présence de fichiers générés. Vous pouvez les supprimer en utilisant scons --clean <options>, où <options> est la liste des options de compilation que vous avez utilisées pour compiler Godot précédemment.

Vous pouvez aussi utiliser git clean -fixd qui nettoiera les artefacts de compilation pour toutes les plateformes et configurations. Attention, car cela supprimera tous les fichiers non suivis et ignorés dans le répertoire. Ne lancez pas cette commande si vous avez un travail non commité !

Autres options de compilation

Il y a plusieurs autres options de compilation que vous pouvez utiliser pour configurer la façon dont Godot devrait être compilé (compilateur, options de débogage, etc.) ainsi que les fonctionnalités à activer/désactiver.

Vérifiez le résultat de scons --help pour obtenir des détails à propos de chaque option de la version que vous souhaitez compiler.

Remplacement des options de compilation

Utilisation d'un fichier

Le fichier custom.py par défaut peut être créé à la racine du moteur Godot pour initialiser toutes les options de compilation de SCons passées par la ligne de commande :

# custom.py

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

Vous pouvez également désactiver certains des modules intégrés avant la compilation, ce qui permet d'économiser le temps nécessaire à la compilation du moteur, voir la page Optimiser une compilation pour sa taille pour plus de détails.

Voir aussi

Vous pouvez utiliser le générateur d'options de compilation de Godot en ligne pour générer un fichier custom.py contenant les options SCons. Vous pouvez ensuite enregistrer ce fichier et le placer à la racine de votre répertoire source Godot.

Un autre fichier personnalisé peut être spécifié explicitement avec l'option de ligne de commande profile, tous deux remplaçant la configuration de construction par défaut :

scons profile=path/to/custom.py

Note

Les options de compilation définies à partir du fichier peuvent être remplacées par les options de la ligne de commande.

Il est également possible de remplacer les options de manière conditionnelle :

# 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

Utilisation de SCONSFLAGS

SCONSFLAGS est une variable d'environnement qui est utilisée par SCons pour définir les options automatiquement sans avoir à les fournir via la ligne de commande.

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"

Exporter des modèles

Les modèles d'exportation officiels sont téléchargés à partir du site Godot Engine : godotengine.org. Cependant, vous voudrez peut-être les construire vous-même (au cas où vous en voudriez de plus récents, que vous utilisez des modules personnalisés, ou tout simplement que vous ne faites pas confiance à votre propre ombre).

Si vous téléchargez le paquet officiel de modèles d'exportation et que vous le décompressez, vous remarquerez que la plupart des fichiers sont des binaires ou des paquets optimisés pour chaque plate-forme :

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

Pour les créer vous-même, suivez les instructions détaillées pour chaque plate-forme dans cette même section de tutoriel. Chaque plateforme explique comment créer son propre modèle.

Le fichier version.txt doit contenir l'identifiant de version Godot correspondant. Ce fichier est utilisé pour installer les modèles d'exportation dans un répertoire spécifique à la version afin d'éviter les conflits. Par exemple, si vous créez des modèles d'exportation pour Godot 3.1.1, le fichier version.txt doit contenir 3.1.1.stable sur la première ligne (et rien d'autre). Cet identifiant de version est basé sur les lignes major, minor, patch (si présent) et status du fichier version.py dans le dépôt Git Godot.

Si vous développez pour plusieurs plateformes, macOS est certainement la plateforme hôte la plus pratique pour la compilation croisée, puisque vous pouvez effectuer une compilation croisée pour presque toutes les cibles (sauf pour UWP). Linux et Windows viennent en deuxième position, mais Linux a l'avantage d'être la plate-forme la plus facile à mettre en place.