Étude Comparative : Technologies de Build pour R-Type #

Projet : R-Type (Epitech 2024-2025)
Date : Octobre 2025
Auteurs : Équipe R-Type 2BDI: Bérenger, Bryann, Diren, Daniel, Iyad Version : 1.0

1. Contexte #

1.1 Problématique #

Le projet R-Type est un jeu multijoueur développé en C++ qui nécessite :

• La compilation de plusieurs modules (GameEngine, Networking, Client, Server)
• La gestion de dépendances externes (Boost, SFML, LZ4, zlib)
• La génération de plugins dynamiques (.so)
• La compatibilité multi-plateforme (Linux Fedora/Ubuntu au minimum)
• Un système de build reproductible pour toute l'équipe

Le choix du système de build est crucial car il impacte :

• La vitesse de développement (temps de compilation)
• La maintenabilité du projet
• La portabilité du code
• La facilité de setup pour de nouveaux développeurs

1.2 Objectifs de l'étude #

Comparer les principales technologies de build C++ pour déterminer la solution optimale pour :

• Gérer un projet multi-modules complexe
• Intégrer un gestionnaire de dépendances
• Assurer la reproductibilité du build
• Minimiser la courbe d'apprentissage de l'équipe

2. Solutions étudiées #

2.1 GNU Make (Makefile traditionnel) #

Description : Système de build historique Unix, basé sur des règles de dépendances.

Utilisation actuelle : Remplacé par CMake dans notre projet.

2.2 CMake #

Description : Meta-build system qui génère des fichiers de build natifs (Makefiles, Ninja, MSBuild).

Exemple de syntaxe :

Utilisation actuelle : Solution adoptée pour R-Type.

2.3 Meson #

Description : Build system moderne écrit en Python, conçu pour être rapide et simple.

Exemple de syntaxe :

Utilisation actuelle : Non utilisé, étudié pour comparaison.

2.4 Bazel #

Description : Build system de Google, optimisé pour les très gros projets et les mono-repos.

Exemple de syntaxe :

Utilisation actuelle : Non utilisé, trop complexe pour notre échelle.

3. Critères de comparaison #

3.1 Critères techniques #

1. Facilité d'utilisation - Courbe d'apprentissage, syntaxe, documentation
2. Gestion des dépendances - Intégration avec gestionnaires de packages
3. Multi-plateforme - Support Linux, Windows, macOS
4. Modularité - Gestion de sous-projets et plugins

3.2 Critères projet #

5. Communauté - Popularité, ressources, support
6. Maintenabilité - Évolutivité, clarté du code de build
7. Reproductibilité - Garantie de builds identiques

4. Analyse détaillée #

4.1 Facilité d'utilisation #

Make présente un setup trivial mais une syntaxe archaïque qui devient rapidement problématique sur des projets complexes. Les wildcards sont dangereux et la gestion des dépendances inexistante. La documentation est abondante mais obsolète.

CMake offre un compromis raisonnable avec un setup modéré et une syntaxe acceptable. La courbe d'apprentissage est moyenne, la syntaxe peut paraître cryptique au début mais devient cohérente une fois maîtrisée. La documentation est excellente et à jour.

Meson se distingue par sa syntaxe moderne et lisible, inspirée de Python. Le setup est simple et intuitif. La documentation est de bonne qualité même si moins exhaustive que CMake.

Bazel requiert une compréhension profonde des concepts de targets, workspaces et rules. Le setup est complexe et la syntaxe verbeuse. La documentation est dense mais orientée pour des projets d'envergure industrielle. Clairement inadapté pour R-Type.

Verdict : Meson > CMake > Make > Bazel

4.2 Gestion des dépendances #

Notre projet nécessite Boost 1.84.0, SFML 2.6.1, LZ4 1.9.4 et zlib 1.3.1.

Make ne propose aucun mécanisme natif de gestion de dépendances. L'installation manuelle via apt ou dnf est sujette aux variations entre distributions et versions. Aucun contrôle des versions installées.

CMake via find_package() nécessite que les bibliothèques soient installées sur le système. L'intégration avec Conan 2.0 ou vcpkg résout complètement ce problème en automatisant l'installation et en garantissant les versions exactes. Nous avons choisi Conan pour sa flexibilité et sa meilleure intégration multi-générateurs.

Meson propose dependency() qui fonctionne de manière similaire à find_package(). WrapDB offre un système de packages mais moins fourni que Conan.

Bazel nécessite la configuration manuelle de rules externes, complexe à mettre en place mais puissant une fois configuré.

Tests réels avec Conan et CMake montrent que toutes les dépendances s'installent automatiquement, les versions sont contrôlées précisément via conanfile.txt, le build est reproductible sur n'importe quelle machine sans nécessiter sudo ou installation système.

Notre choix de Conan plutôt que vcpkg s'explique par une meilleure flexibilité et intégration multi-générateurs.

Verdict : CMake+Conan > Meson+WrapDB > Bazel > Make

4.3 Multi-plateforme #

Make fonctionne nativement sur Linux et macOS mais pose problème sur Windows où MinGW est requis. La cross-compilation est difficile et nécessite de réécrire les Makefiles.

CMake génère des fichiers de build natifs pour toutes les plateformes. Support natif de MSVC et MinGW sur Windows. La cross-compilation est facilitée via des fichiers toolchain.

Meson offre un support similaire à CMake avec des cross-files pour la cross-compilation. Support natif de toutes les plateformes principales.

Bazel supporte également toutes les plateformes de manière native avec un système de toolchains sophistiqué.

Verdict : CMake = Bazel > Meson > Make

4.4 Modularité #

Notre architecture R-Type comprend plusieurs modules : GameEngine (bibliothèque statique), RType-Game (bibliothèque statique), Networking (deux exécutables client et server), LibEngine (cinq plugins .so) et Client (exécutable standalone).

Make nécessite des Makefiles récursifs avec gestion manuelle des dépendances inter-modules. L'ordre de compilation doit être spécifié explicitement. La génération de plugins .so requiert des règles custom.

CMake gère automatiquement les sous-projets via add_subdirectory(). Les dépendances inter-modules sont résolues automatiquement. Les plugins sont créés avec le type MODULE library. L'ordre de compilation est déterminé automatiquement.

Meson propose subdir() avec les mêmes avantages que CMake. Les plugins utilisent shared_module().

Bazel organise les projets en packages avec une gestion automatique des dépendances via cc_library.

Dans notre cas, CMake a permis d'ajouter facilement de nouveaux modules sans modifier la structure globale. La gestion automatique des dépendances évite les erreurs de linking.

Verdict : CMake = Meson > Bazel > Make

4.5 Communauté et ressources #

Make bénéficie d'une communauté historique avec environ 15000 questions sur Stack Overflow et une documentation abondante mais souvent obsolète. Les tutoriels pour C++ game dev sont nombreux mais anciens.

CMake domine avec plus de 35000 questions sur Stack Overflow, 20000+ stars GitHub et une adoption de 90% dans l'industrie. La documentation officielle est excellente et maintenue. Les exemples pour SFML avec Conan sont facilement trouvables. Notre test pratique montre qu'il faut environ 10 minutes pour résoudre un problème de linking SFML avec Conan.

Meson est plus récent avec environ 800 questions sur Stack Overflow et 5500 stars GitHub. Adoption limitée à environ 10% des projets. La documentation est bonne mais les ressources spécifiques au C++ game dev sont rares. Temps de résolution d'un problème similaire : environ 1 heure.

Bazel a une communauté active portée par Google (21000 stars GitHub, 3000+ questions Stack Overflow) mais orientée vers les très gros projets. Peu de ressources pour le game dev. Temps de résolution : environ 3 heures à cause de la complexité des rules.

Pour Epitech et R-Type, la richesse de la communauté CMake est un atout majeur qui a facilité la résolution de nombreux problèmes pendant le développement.

Verdict : CMake > Make > Bazel > Meson

4.6 Maintenabilité #

Avec Make, ajouter un fichier source nécessite de modifier la variable SRC (2-3 lignes). Ajouter une dépendance implique de modifier les flags et les libs (5-10 lignes). Créer un nouveau module demande un nouveau Makefile complet (20-30 lignes). La clarté du code est limitée avec des wildcards shell, des substitutions de variables et des conditions ifeq difficiles à suivre.

CMake utilise file(GLOB) pour ajouter automatiquement les fichiers sources (0 modification). Ajouter une dépendance se fait en deux lignes (find_package et target_link_libraries). Créer un module nécessite 3-5 lignes avec add_subdirectory. Le code de build est plus clair avec une syntaxe cohérente et lisible.

Meson offre des avantages similaires à CMake avec une syntaxe encore plus épurée.

Bazel nécessite plus de boilerplate mais maintient une structure claire pour les très gros projets.

Dans notre expérience, l'ajout du module LibEngine pour les plugins a pris environ 15 minutes avec CMake contre plusieurs heures estimées avec Make.

Verdict : CMake = Meson > Bazel > Make

4.7 Reproductibilité #

La reproductibilité est critique pour assurer que tous les membres de l'équipe compilent exactement le même binaire.

Make dépend des versions de bibliothèques installées sur le système. Tests sur trois machines montrent Boost 1.80 sur une machine Fedora 40, Boost 1.83 sur Ubuntu 24.04, et SFML complètement absent sur le dump. Les checksums MD5 des binaires sont différents.

CMake avec Conan garantit les versions exactes via conanfile.txt. Boost 1.84.0, SFML 2.6.1, LZ4 1.9.4 et zlib 1.3.1 sont installés de manière identique sur toutes les machines. Les checksums MD5 des binaires sont identiques. Même ABI, même compilation, pas de "works on my machine".

Meson avec dependency() souffre des mêmes problèmes que Make, dépendant des versions système. WrapDB améliore la situation mais reste moins robuste que Conan.

Bazel avec son système de rules externes peut également garantir la reproductibilité mais au prix d'une complexité de configuration importante.

Verdict : CMake+Conan = Bazel > Meson > Make

5. Tests et Benchmarks #

5.1 Test de build automatisé #

Le protocole de test consiste à cloner le repository sur une machine vierge (Fedora 40 VM), lancer la compilation et mesurer le temps total incluant dépendances et compilation.

Make échoue immédiatement car SFML n'est pas installé sur le système.

CMake avec Conan réussit en 4 minutes 32 secondes via la commande ./build.sh. Le détail montre 45 secondes pour installer Conan, 1 minute 10 secondes pour les dépendances système, 2 minutes 15 secondes pour télécharger et compiler Boost et SFML, et 22 secondes pour compiler R-Type. Un setup complet from scratch fonctionne donc sans intervention manuelle.

Meson échoue car le tool n'est pas préinstallé sur Fedora 40.

Bazel échoue également car non disponible par défaut.

5.2 Benchmark de compilation incrémentale #

Scénario testé : modification d'un seul fichier Player.cpp.

Make recompile en 3.2 secondes. CMake avec Make backend prend 3.5 secondes. CMake avec Ninja prend 2.1 secondes. Meson avec Ninja prend 1.9 secondes. Bazel avec son cache avancé prend 0.8 secondes.

La différence entre CMake et Meson est négligeable pour le développement quotidien (moins de 2 secondes). Bazel excelle mais au prix d'une complexité excessive.

5.3 Test de portabilité #

Tests sur cinq environnements différents : Fedora 40, Ubuntu 24.04, Ubuntu 22.04, Arch Linux et Debian 12.

Avec Make, chaque distribution nécessite l'édition du Makefile pour ajuster les chemins, flags et noms de packages. Score de portabilité : 2 sur 5.

Avec CMake et Conan, la commande ./build.sh fonctionne sans modification sur toutes les distributions. Score de portabilité : 5 sur 5.

6. Conclusion #

6.1 Tableau récapitulatif #

Le scoring pondéré basé sur l'importance des critères pour le projet R-Type donne les résultats suivants.

Facilité d'utilisation (poids 1) : Make 3/5, CMake 4/5, Meson 5/5, Bazel 2/5. Gestion des dépendances (poids 2) : Make 1/5, CMake 5/5, Meson 4/5, Bazel 3/5. Multi-plateforme (poids 2) : Make 2/5, CMake 5/5, Meson 4/5, Bazel 5/5. Modularité (poids 1) : Make 2/5, CMake 5/5, Meson 5/5, Bazel 4/5. Communauté (poids 1) : Make 3/5, CMake 5/5, Meson 2/5, Bazel 4/5. Maintenabilité (poids 2) : Make 2/5, CMake 5/5, Meson 5/5, Bazel 4/5. Reproductibilité (poids 2) : Make 1/5, CMake 5/5, Meson 3/5, Bazel 5/5.

Score total sur 55 points : Make 21/55, CMake 49/55, Meson 41/55, Bazel 40/55.

6.2 Décision finale #

Solution retenue : CMake avec Conan 2.0.

Justifications principales :

Meilleur score global avec 49 sur 55 points. Excellence sur tous les critères importants.

Gestion automatique des dépendances grâce à Conan qui résout tous les problèmes de portabilité entre distributions. Versions exactes garanties.

Standard de l'industrie adopté par plus de 90% des projets C++. Compétence valorisée professionnellement et académiquement.

Support IDE parfait notamment avec VSCode CMake Tools qui maximise la productivité de l'équipe. Configuration automatique, build en un raccourci, debugging intégré.

Communauté massive avec plus de 35000 questions Stack Overflow. Résolution rapide des problèmes rencontrés pendant le développement.

Reproductibilité garantie sur toutes les machines grâce à Conan. Elimination complète du syndrome "works on my machine".

Évolutivité prouvée. Ajout facile de nouveaux modules et dépendances tout au long du projet.

6.3 Alternatives écartées #

Meson obtient 41 sur 55 points. La syntaxe est excellente et la performance légèrement meilleure. Cependant la communauté est plus petite avec moins de ressources disponibles pour le C++ game development. WrapDB propose moins de packages que Conan. Bon choix technique mais CMake reste plus sûr pour un contexte Epitech.

Make score 21 sur 55 points. La simplicité initiale est trompeuse car le système devient rapidement ingérable sur des projets multi-modules. Absence totale de gestion de dépendances. Difficultés importantes de portabilité entre distributions. Inadapté pour R-Type.

Bazel atteint 40 sur 55 points. La performance est exceptionnelle notamment grâce au cache sophistiqué. Néanmoins la complexité est excessive pour l'équipe et le cadre Epitech. Configuration verbale et concepts avancés requis. Overkill pour un projet de cette taille. Réservé aux mono-repos géants type Google ou Uber.

6.4 Implémentation choisie #

L'architecture finale s'organise avec CMakeLists.txt à la racine pour l'orchestration, conanfile.txt pour les dépendances, build.sh comme script d'automation, et un CMakeLists.txt par module (GameEngine, RType-Game, Networking, LibEngine, Client).

Le workflow de build se déroule ainsi : ./build.sh pour le setup et la compilation initiale, cmake --build build -j$(nproc) pour la compilation rapide en développement, et ./build.sh clean pour le nettoyage.

Les dépendances gérées par Conan incluent Boost 1.84.0 (system, thread), SFML 2.6.1 (graphics, window, system, audio), LZ4 1.9.4 pour la compression réseau et zlib 1.3.1.

Les avantages concrets constatés pendant le développement : setup d'un nouveau développeur en moins de 5 minutes, compilation incrémentale en moins de 10 secondes, aucun problème de portabilité entre Fedora et Ubuntu, intégration VSCode parfaite, et déploiement sur dump Epitech sans modification.

7. Annexes #

7.1 Commandes de référence #

Build complet : ./build.sh

Build manuel détaillé :

conan install . -of=build --build=missing cmake -S . -B build -DCMAKE_TOOLCHAIN_FILE=build/build/Release/generators/conan_toolchain.cmake cmake --build build -j$(nproc)

Nettoyage : ./build.sh clean

7.2 Ressources #

Documentation CMake officielle Documentation Conan 2.0 Tutoriels SFML avec CMake Repository Conan pour Boost

Document approuvé par l'équipe R-Type 2BDI - Octobre 2025