Sous les OS descendant d'Unix tels que Linux, OS X, Solaris, et autres, pour construire un projet, nous utilisons ce que nous appelons des Makefile.

L'idée derrière eux, c'est de faire un livre de cuisine : on décrit comment, à partir d'ingrédients, on arrive à un résultat, pour que lorsque l'utilisateur demande le résultat, l'utilitaire de construction, ici GNU Make, sache ce qu'il doit faire pour parvenir à ce résultat, et de quels ingrédients il a besoin.

Le principe dans un cas préçis : construction d'un add-in

Commençons par décrire le principe dans un cas bien précis, celui qui nous intéresse sur ce site : la construction d'un add-in. L'add-in est au format G1A, un format propriétaire de CASIO, pour le construire, nous allons avoir besoin d'un fichier binaire contenant les données à mettre dans l'add-in, et un utilitaire, g1a-wrapper, que vous avez normalement installé avec le reste.

Sauf que nous avons des fichiers C et des fichiers assembleurs (source). Comment produire ce fichier binaire à partir de fichiers ? Nous savons que nous pouvons compiler les fichiers C et assembleurs (source) en fichiers objets à l'aide du compilateur C (sh3eb-elf-gcc) et de l'assembleur (sh3eb-elf-as). Ces fichiers objets contiennent du binaire avec symboles (au format ELF), et nous voulons les assembler en un fichier binaire pour la mise au format de l'add-in.

Malheureusement, cela ne se fait pas en une passe : il faut d'abord produire un fichier ELF à partir de tous les objets, puis "retirer" les métadonnées dans le fichier ELF (d'où la production d'un fichier intermédiaire "addin.elf").

Nous avons toutes nos règles, et l'enchaînement est bon : nous savons comment faire des fichiers objet à partir des fichiers C et assembleur, le fichier ELF de ces fichiers objet, le fichier binaire de ce fichier ELF, puis l'add-in à partir de ce fichier binaire. Maintenant, il va falloir mettre ça en forme !

Comment on écrit une règle (recette) ?

Chaque règle contient trois éléments : élément à construire, dépendances, commandes liées à la règle. Dans un Makefile, cela se présente de la façon qui suit :



À noter que GNU Make n'aime pas vraiment les fichiers dont le nom contient des espaces, donc je vous conseille vraiment d'éviter ça.

Commençons par l'add-in final : le fichier à produire (résultat), c'est le G1A, ce dont nous avons besoin (ingrédients), c'est le fichier binaire, et le contenu de la recette, c'est l'utilisation de g1a-wrapper ! Voilà ce que ça donne :



Au passage, je vous déconseille fortement d'utiliser les quatre derniers chiffres de la version (ils ont une signification spéciale).

Y a plein de trucs qui se répètent, y a pas moyen de faire des variables ?

Si, il est possible d'utiliser des variables ! Il faut les définir en dehors du contenu des règles. Pour cela, faites simplement :



Ici, des variables utiles à définir pour notre add-in seraient par exemple :



Pour les utiliser, il faudra néanmoins utiliser des parenthèses, par exemple, $(NOM), et pas $NOM.

Au-delà de ces variables définies par l'utilisateur, il y a des variables spéciales définies par GNU Make, dites "automatiques". Elles sont définies pour les instructions dans les règles. Parmi d'autres, nous avons :

- $@ : le nom de la cible (résultat), par exemple addin.g1a ;
- $^ : le nom des dépendances (ingrédients), par exemple addin.bin ;
- $< : le nom de la première dépendance.

Nous pouvons donc améliorer notre règle pour qu'elle devienne :



Ainsi, vous aurez moins d'emplacements à changer à chaque fois.

Et si je veux faire des trucs un peu plus compliqués, y a des fonctions ?

Y en a pas mal avec GNU Make. On citera par exemple $(wildcard pattern), qui permet d'évaluer une wildcard (chemins avec des étoiles '*' et autres métacaractères) pour récupérer plusieurs fichiers. Par exemple, on peut faire $(wildcard source/*.c) pour récupérer tous les fichiers C dans le dossier source/.

Pour le reste, ceci est un tutoriel rapide et n'a pas vocation à devenir une référence complète : vous saurez chercher par vous-mêmes

Y a des trucs cool à faire avec les dépendances ?

L'idée avec les dépendances, c'est que si un fichier n'existe pas dedans, ça va faire une erreur, et si un fichier a été mis à jour depuis la dernière construction, ça va refaire le fichier source, et tout ce qui dépend de ce fichier source (donc seulement les fichiers objets concernés, et l'ELF/binaire/add-in).

Donc il est possible de faire une règle du type truc.o: truc.c machin.h pour que si machin.h est mis à jour, ça considère que ça doive reconstruire truc.o (ce qui est une bonne chose, puisque des structures ou autres choses prototypes ont peut-être été mis à jour !).

Conclusion

L'usage des commandes de compilation, de production des fichiers objet, du fichier binaire, et de l'add-in en lui-même, c'est sur le tutoriel d'installation du cross-compilateur, étapes 7 et 8.

gint requiert des commandes propres, et c'est probablement renseigné sur le topic de celui-ci.

À partir d'ici, vous avez les armes de base pour décider comment vous allez organiser votre projet. Vous devriez avoir ce qu'il faut pour avoir tout dans le même dossier, mais peut-être voudrez-vous avoir un dossier src/ ou source/ pour séparer les sources du reste ? Peut-être avec un dossier obj/ ou objets/ pour séparer les objets des sources, histoire que ça fasse moins cracra ? De là, vous avez le contrôle et la documentation, je vous fais confiance