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

Cela permettra de lancer le processus de construction(build), qui prendra un certain temps. Si vous voulez que les SCons se construisent plus rapidement, utilisez le paramètre -j <cores> pour spécifier combien de cœurs seront utilisés pour la construction(build). Ou laissez un seul noyau, afin de pouvoir utiliser votre ordinateur pour autre chose :)

Exemple pour l’utilisation de 4 cœurs :

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.

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"

Note

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.

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.

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.

Par exemple, vous pouvez vouloir compiler Godot en parallèle avec l’option -j susmentionnée pour toutes les compilations futures :

export SCONSFLAGS="-j4"
set SCONSFLAGS=-j4
$env: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
javascript_debug.zip
javascript_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 <https://github.com/godotengine/godot/blob/master/version.py>`__.

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.