make -p et LevelEditor.elf

Bon, moins drôle. En voulant tester une variante de LevelEditor qui ne conserverait que les personnages effectivement sur la map, je me rends compte que LEDS ne compile plus. En fait, SEDS et AnimEDS non plus: j'ai oublié de vérifier que mes modifications du game engine ne "cassait" pas les éditeurs ^^". Heureusement qu'au boulot, j'ai des "buildbots" pour m'éviter ce genre de mésaventures.

Allow me to be much more technical, please. I have some build system issues with the editors. Somehow, I forgot to maintain them as I was upgrading the core library for the game engine library, and some parts of the engine are shared with the editors. Although I don't have build bots setup for this project, I can use some makefile-debugging techniques I developed working on buildroot-based project. The #1 trick being the existence of '-p' flag for GNU make, that let you review every single variable and rule instantiation and understand what goes wrong much faster than by adding echo commands here and there.

Heureusement aussi, j'ai découvert l'année dernière l'existence du flag "-p" pour GNU make, qui nous fait un dump de l'ensemble des variables internes du makefile, avec en prime la ligne de makefile qui a défini cette variable. De quoi retrouver sans trop de difficulté que les options pour générer la "map" au moment du link sont erronées, et de rajouter un "--cref" histoire d'en apprendre un peu plus.

The core issue I'm facing is that LEDS is now trying to include the core part of the game engine, that parses scripts and does game object updates frame by frame. Clearly, it's not required for the editors. And the editors are not ready to include it, because they don't provide details on the kind of game they are. As soon as 'make -p' allowed me to locate where to define additional flags for the linker and what the current flags are, I can enable the creation of a linking map, that will indicate which symbol triggered inclusion of GameScript.o and in which source file of the level editor it was invoked.

Oui, parce que le problème que je rencontre ici, c'est que tout d'un coup l'éditeur de niveau s'est mis à avoir besoin de la quasi-totalité du moteur de jeu. Qui en retour a besoin qu'on lui indique comment marche le jeu.

Reste à découvrir pourquoi "level.o" s'est mis à faire référence à ce AllocContext::active qui a "attiré" le parseur de GameScript à l'intérieur de l'éditeur de niveau ... ça, c'est un job pour GCC avec son flag -E (pour "fais juste le pre-processing et arrête-toi"). Pour ça, j'ai ré-injecter dans ds_rules du "devkitarm" une technique découverte ce matin dans buildroot: plutôt que d'utiliser directement '@' (oui, oui, comme dans les autoexec.bat ;) pour masquer l'appel d'une commande pour ne pas surcharger la console du développeur, on utilise '$Q ' avec 'Q ?= @'. Il suffit alors d'appeler 'make Q= ' pour avoir l'information complète, voire de ne définir la valeur par défaut de Q que si V n'a pas encore de valeur, ce qui permet un 'make V=1' pour '--verbose' bien plus facile à mémoriser. Je peux alors voir la commande exacte de compilation du fichier "level.cpp" et en introduire une variante avec mon fameux flag -E.

The last step is to understand why this "AllocContext" variable (it turned out not to be a function) is used. My best move for that is to capture the exact command that compile level.cpp and replay it with the '-E' flag that only goes through pre-processing and dump the result. I can then see the same thing as the compiler sees, search through it in a single pass. Once it's done and understood, it's merely a matter of moving those static variables into their own compilation unit, so that the linker can pick AllocContextDefault.o to satisfy level.o's needs without pulling the whole game engine along.

Et voici le chaînon manquant: un script est devenu un contexte d'allocation, et la définition du contexte d'allocation se trouve dans GameScript. Un petit déplacement de la variable "active", et ce sera réglé.