ENIB LANG-C 01_Build - Organisation et fabrication d'un programme

{} Pourquoi le langage C ?

Le langage C est apparu au début des années 1970.
À l'époque, le développement sur les (rares) machines informatiques nécessitait l'emploi du langage d'assemblage✍ spécifique à chacune d'elles.
Le portage d'un programme, voire d'un système d'exploitation, depuis un modèle de machine vers un autre nécessitait alors une réécriture totale.
En autorisant l'expression des constructions algorithmiques usuelles (variables, boucles, fonctions...) dans un langage de plus haut niveau (plus facile à lire pour un être humain) qui pouvait être traduit (compilé) dans le langage spécifique à la machine sous-jacente, tout en autorisant l'accès aux ressources de bas niveau de cette machine (les périphériques et la mémoire notamment), le langage C pouvait être considéré comme un langage d'assemblage portable.
Il s'est imposé comme le langage de choix pour la réalisation du premier système d'exploitation portable largement déployé : le système UNIX.

Au fil de l'histoire, la norme décrivant ce langage a subi plusieurs évolutions.
Même si aujourd'hui nous en sommes à la version C17 (introduite en 2018), la version du langage C qui est encore à l'heure actuelle la plus largement disponible et utilisée repose sur la norme C99 (introduite en 1999).
C'est sur celle-ci que nous nous appuierons dans le cadre de l'apprentissage de ce langage✍.

Pendant très longtemps le langage C est resté le langage industriel prédominant pour tout développement conséquent.
Seulement, à partir du milieu des années 1990 le foisonnement de nouvelles technologies et de langages associés offrait aux programmeurs un large éventail d'outils pour accomplir plus confortablement les tâches de chaque domaine applicatif spécifique.
Pour accentuer ce phénomène, jusqu'au début des années 2000 la montée en fréquence de chaque nouvelle génération de processeurs était telle qu'il était plus rentable économiquement de miser sur l'achat de machines modernes et puissantes, que de payer des spécialistes pour optimiser l'efficacité des programmes.
Cela a conduit à un moindre besoin en programmeurs maîtrisant le fonctionnement de bas niveau des machines informatiques, au profit d'une forte demande en développeurs capable de produire rapidement du code moins efficace avec des outils de haut niveau.
C'est là toute l'ironie du sort : le langage C, qui à l'origine était vu comme un langage de haut-niveau, était devenu un langage de bas niveau !

Toutefois, la donne a une nouvelle fois changé après le début des années 2000.
La prétendue inexorable montée en fréquence des nouveaux processeurs a finalement atteint une limite unanimement considérée comme infranchissable✍.
La montée en puissance repose désormais en grande partie sur la multiplication des unités de calcul (processeurs multi-cœurs et machines multi-processeurs), et surtout la prédictibilité des traitements et de l'accès aux données, ce qui nécessite à nouveau un contrôle fin des détails d'exécution des programmes pour en tirer pleinement parti ; le langage C représente l'outil de prédilection pour offrir une telle maîtrise.
À cette nouvelle tendance s'ajoute le fait que la problématique de la consommation d'énergie, dans une spectre allant des centres de calcul✍ au domaine de l'informatique mobile et embarquée✍, encourage à exploiter au mieux les capacités de calcul des processeurs.
Il n'est désormais plus envisageable d'utiliser un processeur démesurément puissant, et donc énergivore, là où un processeur plus économe en énergie ferait l'affaire à condition d'optimiser les traitements qu'on lui confie.
Tout gain en efficacité de calcul se traduit par une économie d'énergie, donc un gain en autonomie ; de manière complémentaire, dans une enveloppe énergétique et thermique donnée les traitements fournissent au bout du compte plus de service si on les optimise.
Une nouvelle fois, le langage C s'avère parfaitement adapté à ces enjeux✍.
Pour le constater, voici des sites qui comparent l'efficacité de langages de programmation courants :

Malgré son age avancé, le langage C reste alors toujours un outil incontournable pour les ingénieurs.
Même si à l'heure actuelle il est assez rare de l'utiliser pour développer une application complète, il est très fréquent d'y avoir recours pour réaliser des bibliothèques de fonctionnalités qui sont invoquées depuis des langages de plus haut niveau lorsque ceux-ci souffrent de limitations en performances.
C'est justement une compétence importante de l'ingénieur que de savoir déterminer et isoler les parties d'une application qui bénéficieraient d'une telle reformulation en langage C.
Voici quelques cas d'utilisation typiques :

besoin d'accéder à des ressources de bas niveau, la programmation de pilotes de périphériques (drivers) par exemple✍
L'enseignement autour des microprocesseurs à l'ENIB (matières S4-CEL, S5-MIP et S6-MIP) s'appuie en grande partie sur le langage C.
,
ressources matérielles limitées en calcul et/ou en mémoire (domaine de l'informatique mobile et embarquée✍
L'enseignement autour des microprocesseurs à l'ENIB (matières S4-CEL, S5-MIP et S6-MIP) s'appuie en grande partie sur le langage C.
) ; d'où l'intérêt d'un langage qui ne gaspille pas de ressources,
applications dans des langages de plus haut niveau contenant néanmoins des traitements très calculatoires qui peuvent être longs ; il est alors nécessaire d'isoler ces traitements pour les réécrire avec un langage plus efficace et rendre l'application plus réactive et confortable,
très longs calculs, simulations biologiques ou physiques pouvant durer plusieurs jours par exemple, sur du matériel non limité en ressources ; la moindre optimisation peut faire gagner un temps et donc une énergie considérables.

Pour terminer cette introduction, soulignons le fait que la syntaxe du langage C (que nous nous proposons de découvrir dans ce chapitre) a été reprise dans une multitude d'autres langages, même de haut niveau.
En particulier, le langage C++ (à plus forte raison dans sa version moderne) conserve au premier plan le soucis de la maîtrise de l'optimisation et des détails d'exécution des programmes et reste en grande partie compatible avec le langage C dont il est directement issu.

{} Un premier programme en langage C

Ouvrez un terminal et, grâce à la ligne de commande du shell, placez-vous dans le répertoire de travail choisi pour ce sujet.
Saisissez par exemple✍ : $ mkdir LANG_C_01_Build ↵ $ cd LANG_C_01_Build ↵

{} Rédaction du code source

Ouvrez votre éditeur de texte préféré pour rédiger le contenu d'un nouveau fichier nommé prog01.c, par exemple : $ gedit prog01.c & ↵ Dans celui-ci saisissez (par copier/coller) le texte suivant :

int                            // cette fonction doit renvoyer un entier
main(void)                     // définition d'une fonction main() sans paramètre
{
  printf("entering main()\n"); // appel d'une fonction printf() avec une chaîne littérale
  printf("leaving main()\n");  // un second appel
  return 0;                    // voici l'entier que cette fonction doit renvoyer
}

Sauvegardez alors le contenu de l'éditeur ; le fichier source prog01.c contient désormais le texte saisi.
Commençons par en donner une description succincte.
Les portions de lignes qui contiennent le symbole // (double-slash) sont des commentaires qui permettent d'ignorer le texte qui s'étend de ce symbole jusqu'à la fin de la ligne (similaire à # que vous connaissez déjà en langage Python).
De la même façon, les lignes vides n'ont aucun effet sur le langage ; elle ne sont là que pour la lisibilité.
N'oubliez pas : vous ne programmez pas que pour la machine !
Vous programmez surtout à l'intention d'êtres humains (dont vous-même) qui vont réutiliser, maintenir et étendre votre code ; la lisibilité, l'indentation et les commentaires facilitent ces opérations.

La construction de la forme int main(void) désigne une fonction nommée main qui n'attend aucun paramètre (signifié par le mot-clef void, contrairement à Python ou C++ où des parenthèses vides suffisent), et qui renvoie comme résultat un entier (mot-clef int, étudié ultérieurement).
Cette écriture qui consiste à indiquer le type de la valeur renvoyée, le nom et les paramètres d'une fonction est désignée par le terme prototype ; le prototype d'une fonction est une information fondamentale sur laquelle nous aurons l'occasion de revenir d'ici peu.

Au delà du prototype de cette fonction, nous trouvons une paire de symboles

{ }

(accolades).
Un tel bloc contient une séquence d'instructions, chacune d'elles étant terminée par le symbole ; (point-virgule) qui est obligatoire.
Ce bloc d'instructions qui est joint au prototype matérialise le corps de la fonction c'est-à-dire l'algorithme que doit exécuter cette fonction lorsqu'elle est appelée.
Contrairement à Python, ce n'est aucunement l'indentation qui marque les blocs d'instructions mais une telle paire d'accolades ; nous pourrions avoir le loisir de disposer les instructions de manière fantaisiste mais il ne faut absolument pas le faire car cela nuirait à la lisibilité.
Remarquez ici la disposition des accolades et l'alignement des instructions ; il s'agit d'un style d'indentation particulier mais il en existe bien d'autres, l'important étant de rester cohérent dans un style une fois qu'on l'a choisi.

Les deux premières instructions du bloc précédent sont des appels à une fonction printf() supposée existante et pouvant recevoir en paramètre une chaîne littérale.
Une telle chaîne littérale se reconnaît aux symboles " (guillemets) qui l'encadrent ; elle existe aussi en Python, vous devez notamment reconnaître le caractère spécial \n (backslash-n) qui matérialise un passage à la ligne.
La dernière instruction utilise le mot-clef return (comme en Python) afin de fournir la valeur de retour attendue par la fonction : ici un entier (type de retour int dans le prototype) valant 0.

Comme le suggère le nom de la fonction main() définie ici, il s'agit de la fonction principale du programme, c'est-à-dire celle qui est automatiquement appelée quand le programme démarre ; lorsque cette fonction se termine, le programme est également terminé.
Notez que nous n'avons pas le choix quant à son prototype (à une variante près qui sera vue dans cette section) ; même si pour l'instant nous ne faisons apparemment aucun usage de l'entier que nous lui faisons renvoyer, celui-ci est obligatoire.
(https://en.cppreference.com/w/c/language/main_function)

{} Compilation du programme

Contrairement à un programme Python, pour lequel il suffit d'invoquer l'interpréteur en lui indiquant le fichier de code source, un programme en langage C ne peut pas être directement exécuté.
Il faut passer par une phase intermédiaire qui traduit ce code source en un format exécutable que le système d'exploitation et la machine informatique comprennent : il s'agit de la compilation.
Voici une commande qui vise à compiler notre programme : $ gcc prog01.c -o prog01 ↵ Le premier mot de cette ligne, gcc, représente le nom du compilateur de langage C installé sur la machine.
Nous reconnaissons à la suite le nom du programme C que nous souhaitons lui faire compiler, prog01.c, et enfin l'option -o accompagnée du nom du programme compilé, prog01, que nous souhaitons obtenir✍.
La commande suivante permet de consulter la documentation en ligne (le manuel) décrivant les multiples options de ce compilateur : $ man gcc ↵ (c'est très long, monter/descendre avec les flèches, quitter avec la touche q)

La compilation de notre programme a produit un message d'avertissement (warning) pour nous signaler une erreur potentielle.
Il est à noter que, pour des raisons historiques, le langage C est très permissif : les compilateurs modernes indiquent par des avertissements des formulations qui en toute rigueur devraient être considérées comme des erreurs empêchant la compilation du programme !
Celles-ci ne sont néanmoins pas bloquantes car elles correspondent à des formulations qui étaient autorisées dans les toutes premières versions du langage ; il s'agit de préserver la compatibilité descendante, c'est-à-dire d'autoriser malgré tout la compilation avec un compilateur moderne d'un code qui avait été rédigé pour un compilateur historique.
Lorsqu'il est question comme ici de rédiger à partir de rien un nouveau code, ce comportement est extrêmement risqué ; ignorer un tel avertissement est une très mauvaise pratique !
Nous devons donc chercher à le faire disparaître.

Analysons alors le message produit.
Il indique que le problème est détecté dans la fonction main() du fichier prog01.c ; et plus précisément à une ligne dont le numéro est fourni (affichez les numéros de lignes dans votre éditeur de texte pour la repérer).
Le message évoque une déclaration implicite de la fonction printf() ; en effet la ligne de code en question contient bien un appel à cette fonction.
Cette maladresse met en évidence un point fondamental du langage C : tout ce que nous utilisons dans une formulation doit avoir été préalablement déclaré (qu'il s'agisse d'une variable, d'une fonction, d'un type...).
Le langage C ne connaît que les mots-clefs et la ponctuation qui interviennent dans sa grammaire, et dans le cas présent, le compilateur ne peut raisonnablement envisager de traduire un appel à la fonction printf() s'il ne sait pas quels sont les paramètres qu'elle attend ni quel est le type du résultat qu'elle doit renvoyer.
La déclaration d'une fonction revient ainsi à écrire son prototype.

Toutefois, nous n'allons pas écrire nous-mêmes la fonction printf() puisqu'elle fait partie de la bibliothèque standard du langage C.
Il s'agit d'un ensemble de fonctionnalités (des fonctions notamment) déjà compilées et livrées telles quelles lors de l'installation du compilateur sur le système d'exploitation.
Lorsque notre compilateur compile notre code source, il complète nos fonctions avec celles de la bibliothèque standard (comme si nous les avions nous-mêmes écrites et déjà compilées).
Notre code source doit donc avoir connaissance du prototype de ces fonctions pour envisager d'y faire appel (transmettre le bon nombre de paramètres du bon type, recevoir un résultat du bon type).
Ajoutez alors la ligne suivant avant la définition de votre fonction main() (c'est-à-dire avant int main(void) { ...) :

#include <stdio.h>

Remarquez que la ligne commence par le symbole # (dièse) ; ceci matérialise l'usage d'une directive du préprocesseur.
Il ne s'agit pas du langage C à proprement parler mais d'un autre langage bien plus rudimentaire dont le propos est de modifier à la volée le code source que le compilateur analysera effectivement.
Lorsque nous invoquons le compilateur (par notre commande gcc par exemple), celui-ci invoque pour nous le préprocesseur et analyse enfin le code en langage C résultant de cette transformation préalable.
(https://en.cppreference.com/w/c/preprocessor)

Dans le cas présent, il s'agit d'inclure le contenu du fichier stdio.h à l'endroit même de cette directive comme si nous l'avions ouvert dans un éditeur de texte, ainsi que tous ceux qu'il inclut lui même, et avions procédé au copier/coller de toutes les lignes vers le code source de notre programme.
Pour nous en rendre compte, utilisons temporairement la commande suivante qui demande au compilateur de n'exécuter que la phase de préprocesseur et d'en afficher le résultat : $ gcc -E prog01.c ↵ Vous devriez voir apparaître dans le terminal d'innombrables lignes de code C (difficilement compréhensibles pour l'instant) et enfin le code source de la fonction main() tel que vous l'aviez préalablement saisi ; c'est au final ce que voit le compilateur du langage C lorsqu'il analyse votre code source dans le but de le transformer en code exécutable.

De la même façon que pour la bibliothèque standard, le fichier stdio.h est installé, ainsi que bien d'autres, dans un emplacement où le compilateur saura le retrouver.
Ces fichiers d'extension .h (on parle de fichier d'en-tête, ou header) servent justement à déclarer les fonctionnalités fournies par la bibliothèque standard (et d'autres).
(https://en.cppreference.com/w/c/io)
Parmi ces lignes se trouve donc la déclaration (le prototype) de la fonction standard printf() qui n'est alors plus inconnue du compilateur, et celui-ci peut enfin s'assurer du fait que l'usage que nous en faisons depuis la fonction main() est correct.
Il faut savoir que le compilateur du langage C analyse le code de haut en bas, ce qui fait qu'à chaque ligne analysée il n'a connaissance que de ce qui précède ; il est donc important que l'inclusion du fichier d'en-tête ait eu lieu avant le code qui utilise les fonctionnalités ainsi déclarées.

Dans ces nouvelles conditions, une nouvelle tentative de compilation doit désormais se solder par une réussite, sans message d'erreur ni avertissement : $ gcc prog01.c -o prog01 ↵ La commande suivante permet de lister le contenu du répertoire de travail courant : $ ls ↵ Vous devez dorénavant y trouver, en plus du fichier de code source, le fichier exécutable qui vient d'être produit.

{} Exécution du programme

Nous pouvons enfin lancer l'exécution du programme que nous avons rédigé et compilé : $ ./prog01 ↵ qui doit provoquer, comme prévu, l'affichage dans le terminal des deux lignes de texte littéral.
Remarquez l'usage du préfixe ./ (point-slash) accolé au nom du programme ; ceci n'a rien à voir avec l'usage du langage C.
Lorsque dans le terminal nous saisissons une commande (le nom d'un programme comme gedit, gcc, man, ls...), le shell qui interprète cette commande sait qu'il peut rechercher un tel programme exécutable dans un ensemble de répertoires prévus à cet effet.
Ici nous venons de produire un nouveau programme exécutable qui n'est pas installé dans un de ces répertoires standards ; il est en effet situé dans notre propre répertoire de travail.
Le préfixe ainsi utilisé indique au shell qu'il trouvera justement ce programme dans le répertoire . (point) qui symbolise le répertoire courant✍.

Puisque nous venons de voir que ce programme peut être lancé par le shell, c'est le bon moment pour revenir sur l'entier renvoyé par la fonction main().
C'est en effet le programme qui a lancé le notre (le shell ici) qui peut récupérer cette information✍.
Si juste après avoir exécuté votre programme, vous saisissez la commande shell : $ echo $? ↵ vous devriez voir apparaître la valeur renvoyée par la fonction main() (0 ici).
Pour vous en convaincre, modifiez cette valeur (entre 0 et 255) dans votre code source, recompilez votre programme, exécutez-le à nouveau et contrôlez la nouvelle valeur obtenue✍.

Nous venons de réaliser, dans sa version minimale, la démarche classique de mise au point d'un programme en langage C :

édition du code source,
compilation,
analyse des messages de compilation,
- retour éventuel vers l'édition du code source,
test du programme exécutable obtenu,
- retour éventuel vers l'édition du code source.

Il faudra désormais toujours procéder de cette façon, même si, comme nous le verrons très prochainement, des détails de réalisation viendront à évoluer.

{} Vers une approche modulaire du développement

Il s'agit maintenant d'organiser le code source et le procédé de compilation pour tendre vers une approche dans laquelle, comme indiqué en introduction de ce sujet, une application sera découpée en de multiples modules consacrés à des aspects distincts du problème globalement abordé.

{} Référence à une fonction définie dans un autre module

Ajoutez, avant chacune des deux instructions de la fonction main() qui appellent la fonction printf(), cette nouvelle instruction :

indent(1);

Vous devez reconnaître un appel à une fonction indent() à laquelle on transmet un paramètre entier valant 1.
Vous savez d'ores et déjà que la compilation va afficher un message d'avertissement : $ gcc prog01.c -o prog01 ↵ En effet, nous sommes dans le même cas de figure que notre première maladresse : nous cherchons à invoquer une fonction dont le compilateur n'a jamais entendu parler.
Seulement, cette fois nous allons réaliser nous-même cette fonction fantaisiste qui ne figure en aucune façon dans la bibliothèque standard.

Cherchons tout d'abord à satisfaire le compilateur en déclarant cette fonction :

void
indent(int depth);

Cette déclaration doit bien entendu figurer avant la définition de la fonction main() qui l'appelle.
Remarquez qu'il s'agit bien d'un prototype avec le type de retour (void pour aucun), le nom de la fonction et un unique paramètre de type int (que nous avons nommé arbitrairement depth✍), ce qui est conforme à l'appel que nous en faisons.
Remarquez également que ce prototype est suivi du symbole ; (point-virgule) et non d'un bloc d'instructions délimité par des accolades ; c'est justement en cela qu'il s'agit d'une déclaration et non d'une définition.
Une déclaration constitue en quelque sorte une promesse qui est faite au compilateur pour lui indiquer que quelque part existe une fonction ayant ce nom et correspondant à ce prototype.
Une fois que cette promesse lui est faite, le compilateur peut légitimement valider et traduire des instructions qui cherchent à appeler cette fonction si elles font un bon usage de ses paramètres et de son résultat.
Une définition, quant à elle, grâce au bloc d'instructions qu'elle apporte entre ses accolades, fournit le code qui sera exécuté lorsque cette fonction sera appelée✍.
L'intérêt d'une telle distinction vient du fait que, dans une application, toute fonction doit être définie une fois et une seule alors qu'elle peut être invoquée à de multiples reprises depuis de multiples modules.
Si nous placions une définition de cette même fonction dans les multiples modules qui ont besoin de l'invoquer, son code compilé figurerait au bout du compte en de multiples exemplaires dans le programme exécutable produit.

Compilons encore notre code source pour observer le comportement du compilateur vis-à-vis de la déclaration que nous venons d'ajouter.
Il signale à nouveau un échec mais celui ci est d'une toute autre nature que le précédent.
Il n'est plus question d'une maladresse concernant une instruction particulière de notre code, mais il nous rappelle que nous n'avons pas tenu la promesse que nous venons de lui faire !
En effet, la fonction indent() que nous avons déclarée n'est définie nulle part alors que la fonction main() y fait référence.
Ce type d'erreur concerne l'édition de liens (link).
De la même façon que nous avions découvert qu'avant la compilation proprement dite intervenait le préprocesseur, nous constatons à la toute fin l'intervention de l'éditeur de liens (linker).
Le rôle de cette phase consiste justement à inspecter tous les modules compilés (il n'y en a qu'un ici pour l'instant) et à s'assurer que toutes les fonctions invoquées ont bien une définition et une seule.
Ces définitions peuvent être retrouvées parmi les modules compilés, dans la bibliothèque standard ou éventuellement dans d'autres bibliothèques fournies à la demande.

{} Ajout d'un module à l'application

Puisque nous travaillons sur l'approche modulaire, nous allons justement réaliser un module supplémentaire qui définit la fonction manquante.
Ouvrez votre éditeur de texte préféré pour rédiger le contenu d'un nouveau fichier nommé module_A.c, par exemple : $ gedit module_A.c & ↵ Dans celui-ci saisissez (par copier/coller) le texte suivant :

#include <stdio.h>

void
indent(int depth)
{
  while(depth!=0)
  {
    printf("| ");
    depth=depth-1;
  }
}

La définition de la fonction indent() n'est guère plus compliquée que celle de la fonction main() que vous avez déjà réalisée.
Nous y retrouvons son prototype déjà décrit lors de sa déclaration ainsi que, parmi ses instructions, un nouvel appel à la fonction standard d'affichage de texte printf() (qui nécessite l'inclusion du fichier d'en-tête standard

<stdio.h>

).
L'instruction while, qui sera présentée dans cette section, a la même signification que ce qui a été vu dans la matière S1-ALR de l'ENIB.
Le bloc d'instructions de cette boucle est donc répété tant que le paramètre entier de la fonction n'est pas nul, et à chaque itération ce dernier est décrémenté ; ceci a globalement pour effet d'afficher depth fois le texte littéral

Puisque nous disposons maintenant de plusieurs fichiers sources, nous allons légèrement modifier le procédé de fabrication du programme exécutable en ayant recours à la compilation séparée.
Comme le nom le suggère, nous commençons par compiler séparément les différents modules avec ces commandes : $ gcc prog01.c -c ↵ $ gcc module_A.c -c ↵ Vous remarquez certainement que l'option -c a été ajoutée et que nous ne fournissons plus le nom du fichier exécutable.
Effectivement, ces commandes ne cherchent pas à générer le programme exécutable ; l'option -c demande au compilateur de s'arrêter à l'étape de la compilation proprement dite sans effectuer l'édition de liens.
Le résultat de chacune de ces commandes est un fichier objet qui contient la traduction, en code exécutable par la machine, des fonctions définies dans chacun des fichiers sources, ainsi que des informations à propos des autres fonctions dont ce fichier a besoin.
La liste du contenu du répertoire courant : $ ls ↵ doit maintenant révéler la présence de ces deux fichiers objets qui utilisent l'extension .o en lieu et place de l'extension .c de chaque fichier de code source.

Il ne reste plus qu'à les rassembler lors de l'édition de liens : $ gcc prog01.o module_A.o -o prog01 ↵ Nous retrouvons enfin le nom du programme exécutable qui doit être généré.
Remarquez toutefois que nous invoquons le compilateur gcc mais que celui-ci ne fait lors de cette dernière commande aucune compilation à proprement parler.
Il n'y a en effet sur sa ligne de commande aucun fichier source en langage C mais uniquement les fichiers objets obtenus précédemment ; il se contente alors de passer directement à la phase d'édition de liens afin de vérifier qu'aucune définition ne manque ni n'est redondante et procéder enfin à la production du programme exécutable✍.
Vous pouvez alors tester ce dernier pour vous assurer qu'il affiche toujours les deux lignes de texte initiales mais dorénavant précédées d'un petit motif textuel matérialisant une indentation de l'affichage (effet de notre fonction indent()).

Bien entendu, le principe du découpage modulaire présenté ici paraît bien compliqué pour si peu de code✍ mais il est à la base de la démarche qui est systématiquement adoptée dans tout projet raisonnable (pensez aux centaines de fichiers sources qui constituent les outils LibreOffice ou Firefox).
Le point essentiel à retenir concerne la distinction entre la définition et la déclaration d'une fonction.
Dans le but d'acquérir à terme un savoir faire exploitable sur des projets de plus grande envergure que ces exercices introductifs, nous nous efforcerons dorénavant d'adopter systématiquement cette démarche même lorsqu'elle semble superflue.

{} Démarche de compilation séparée

Il est maintenant question d'acquérir une démarche systématique pour faciliter la mise en œuvre d'un développement modulaire.
Dans ce but, nous provoquerons volontairement des incohérences afin d'introduire petit à petit les bonnes pratiques qui permettent de s'en prémunir.

{} Modification d'un module

Imaginons que nous souhaitions ajouter une fonctionnalité à notre fonction indent() afin de choisir le motif textuel qu'elle doit répéter.
Il nous faut modifier cette fonction afin qu'elle accepte un nouveau paramètre représentant ce motif et qu'elle s'en serve lors de ses appels à printf().

Modifiez alors le code source du fichier module_A.c afin qu'il contienne ceci :

#include <stdio.h>

typedef const char *Tag; // déclaration du type Tag

void
indent(Tag tag, // un nouveau paramètre de type Tag
       int depth)
{
  while(depth!=0)
  {
    printf("%s", tag); // affichage de ce nouveau paramètre
    depth=depth-1;
  }
}

Vous ne connaissez pas encore suffisamment de détails du langage C pour savoir spécifier précisément le type du nouveau paramètre ; nous le désignons par le type Tag que nous inventons ici pour le propos de l'exercice (ne cherchez donc pas à comprendre les détails de la construction typedef ou de son affichage avec printf()).
Recompilez ensuite l'ensemble de l'application : $ gcc prog01.c -c ↵ $ gcc module_A.c -c ↵ $ gcc prog01.o module_A.o -o prog01 ↵ L'absence de message vous assure que pour le compilateur et l'éditeur de liens l'ensemble du code semble correct.
Testez-le alors en exécutant cette nouvelle version du programme exécutable produit.
Il est très probable que le shell depuis lequel vous le lancez vous indique un plantage causé par une erreur de segmentation (abordée dans cette section).

Complément : analyse d'un plantage au débogueur

Le précédent problème est l'occasion rêvée pour introduire un nouvel outil qui a toute sa place dans le processus de développement d'une application en langage C : le débogueur (debugger).
La commande gdb fait partie des outils livrés dans la chaîne de développement qui accompagne gcc.
C'est un débogueur qui s'utilise en ligne de commande ; même s'il est très puissant et largement utilisé par un grand nombre de développeurs, il n'est pas très confortable pour débuter.
Il existe par ailleurs des interfaces graphiques évoluées qui pilotent cet outil ; elles nécessitent, malgré les apparences, une longue phase d'apprentissage et sont généralement lourdes à utiliser (gros programmes à la réaction lente).
Par chance, l'enseignement autour des microprocesseurs à l'ENIB s'appuie énormément sur l'usage d'un débogueur qui facilite les opérations courantes✍.
Nous nous appuierons donc sur cet outil ici pour en découvrir l'usage minimal ; vous le retrouverez lorsque vous étudierez les microprocesseurs.

Un débogueur permet principalement de suivre dans le code source ce qui se déroule durant l'exécution du programme exécutable.
Seulement, lors de la production des fichiers objets, tout le code source disparaît au profit du code exécutable par la machine.
Si nous envisageons d'utiliser un débogueur, il est alors nécessaire d'indiquer au compilateur qu'il doit conserver dans les fichiers objets, et donc dans le programme exécutable, des informations qui permettent de relier les instructions du code exécutable à celles du code source.
Il suffit d'ajouter l'option -g à chaque commande de compilation : $ gcc prog01.c -c -g ↵ $ gcc module_A.c -c -g ↵ L'édition de liens, quant à elle, doit être réalisée comme précédemment : $ gcc prog01.o module_A.o -o prog01 ↵

Le programme exécutable ainsi généré contient des informations permettant son débogage : $ tdb_prc prog01 ↵ Cet outil ouvre une interface graphique comprenant deux parties principales : en haut la visualisation du code source précédée de boutons de commandes, en bas une zone de messages suivie d'une ligne de saisie de commandes.
Notre programme est initialement en pause ; la toute première ligne de la fonction main() est mise en surbrillance pour indiquer qu'il s'agit de la prochaine ligne de code qui sera exécutée.
Nous procéderons à l'investigation selon les étapes suivantes✍ :

le bouton Continue [F8] (triangle) permet de lancer l'exécution du programme,
- la zone de messages indique que le programme est arrêté car il s'est effectivement planté à cause d'une erreur de segmentation,
le bouton Call Stack (boîtes empilées) affiche dans la zone de messages l'empilement des contextes d'appel depuis la fonction main() jusqu'au point de plantage,
- nous constatons que le plantage s'est révélé dans des fonctions de la bibliothèque standard du langage C invoquées par printf() ; bien entendu nous n'y avons pas accès et nous n'y pouvons rien,
l'usage répété du bouton Frame Up (boîtes et flèche montante) permet d'atteindre le contexte d'un appel de fonction qui nous concerne,
- à chaque appui, un message indique le contexte courant ; nous arrêtons lorsque notre fonction indent() est atteinte,
- à ce moment, la zone de code met en surbrillance la ligne courante dans ce contexte (l'invocation de printf()) et le message indique la valeur des paramètres de la fonction indent(),
  - le paramètre depth a une valeur entière complètement fantaisiste,
  - le paramètre tag désigne une zone mémoire inaccessible, que nous transmettons à printf(), ce qui explique le plantage,
un nouvel appui sur le bouton Frame Up (boîtes et flèche montante) nous fait atteindre le contexte de la fonction main(),
- la zone de code met en surbrillance la ligne courante dans ce contexte,
  - l'invocation de indent() transmet un seul paramètre alors que dans le contexte visité précédemment nous constations que deux étaient attendus ; cela explique la valeur fantaisiste obtenue pour le deuxième paramètre,
  - l'unique paramètre transmis est un entier valant 1 alors que dans le contexte visité précédemment le premier paramètre attendu est une chaîne de caractères (notre type Tag) ; cela explique l'incohérence qui est à l'origine du plantage,
nous quittons la session de débogage en fermant simplement la fenêtre de l'outil.

L'utilisation du débogueur était ici purement illustrative car l'incohérence détectée était facilement prévisible.
Néanmoins, dans le cas de programmes plus élaborés, le parcours et l'inspection de la pile des contextes d'appels des fonctions lors d'un plantage est une démarche très classique pour rechercher la cause d'un dysfonctionnement.

{} Cohérence entre déclaration et définition

Bien que nous ayons fini par montrer que l'appel qui est fait à la fonction indent() ne correspond pas à ce qui est attendu dans sa définition, il est tout de même très regrettable que cette incohérence soit passée inaperçue lors de la fabrication du programme exécutable.
La fonction main() s'appuie en effet sur une déclaration de la fonction indent() qui n'est plus à jour par rapport à sa nouvelle définition (depuis l'ajout d'un paramètre).
Malheureusement, l'édition de liens se contente de vérifier la présence de chaque fonction requise mais n'a aucun moyen de confronter le prototype utilisé lors de l'appel avec celui de sa définition.
De la même façon que nous avions eu recours au fichier d'en-tête standard

<stdio.h>

pour prendre connaissance de la déclaration de la fonction printf(), nous allons fournir un fichier d'en-tête qui déclare les fonctionnalités que le module_A.c définit.

Ouvrez votre éditeur de texte préféré pour rédiger le contenu d'un nouveau fichier nommé module_A.h, par exemple : $ gedit module_A.h & ↵ Dans celui-ci saisissez (par copier/coller) le texte suivant :

typedef const char *Tag;

void
indent(Tag tag,
       int depth);

Il ne s'agit que de la déclaration du type Tag déjà vu précédemment et de la déclaration de la fonction indent() selon son nouveau prototype.

Dans le fichier module_A.c nous devons retirer la construction typedef qui déclare le type Tag et ajouter au début du fichier l'inclusion de notre fichier d'en-tête :

#include "module_A.h"
#include <stdio.h>

void
indent(Tag tag,
       int depth)
{
  while(depth!=0)
  {
    printf("%s", tag);
    depth=depth-1;
  }
}

De la même façon, dans le fichier prog01.c nous devons remplacer la déclaration de la fonction indent() par cette même inclusion :

#include <stdio.h>
#include "module_A.h"

int
main(void)
{
  indent(1); printf("entering main()\n");
  indent(1); printf("leaving main()\n");
  return 0;
}

Remarquez que dans ces deux cas nous encadrons le nom de notre propre fichier d'en-tête par des symboles " (guillemets) alors que pour stdio.h nous utilisons

(chevrons).
Cette distinction repose sur le fait que ces fichiers d'en-tête à inclure sont locaux au projet en cours ou bien sont déjà installés dans les répertoires standards du système d'exploitation✍.
(https://en.cppreference.com/w/c/preprocessor/include)

Sans rien changer d'autre au code source, la compilation du fichier module_A.c doit se produire sans encombre.
En effet, la déclaration découverte dans le fichier d'en-tête est bien strictement conforme au prototype de la définition fournie un peu plus loin dans le fichier source.
En revanche, la compilation du fichier prog01.c doit désormais produire des messages d'erreur puisque cette même déclaration ne correspond plus du tout aux appels qui sont exprimés dans la fonction main().
Remarquez que si nous avions choisi de conserver l'ancien prototype de la fonction indent() pour sa déclaration dans le fichier module_A.h, ce serait alors la compilation de module_A.c qui échouerait (incohérence entre la définition et sa déclaration préalable) et celle de prog01.c qui réussirait.
Dans le but d'éliminer ces erreurs, nous rectifions alors les deux appels à indent() dans la fonction main() de façon à ce qu'ils soient à nouveau conformes au prototype de la déclaration :

indent("* ", 1);

Les deux compilations et l'édition de liens doivent désormais se dérouler sans encombre.
Le programme exécutable obtenu doit maintenant illustrer l'effet de nos modifications en utilisant le nouveau symbole choisi pour l'indentation des deux lignes de texte affichées.

Par l'usage d'un fichier d'en-tête qui déclare les fonctionnalités d'un module, nous venons d'établir un principe qui assure de manière certaine la cohérence entre les déclarations et les définitions.
Il suffit d'inclure systématiquement ce fichier d'en-tête au début du fichier de définition du module qu'il décrit.
Il ne reste alors plus qu'à inclure ce même fichier d'en-tête dans les autres modules qui ont besoin de réaliser des appels au module ainsi déclaré et défini.
À la moindre incohérence, dans un cas ou dans l'autre, le compilateur nous signale une erreur.

Nous n'y avons pas eu recours dans l'exemple simpliste traité ici, mais il serait tout à fait raisonnable d'inclure d'autres fichiers d'en-tête (standards ou propres à l'application) à l'intérieur de celui que nous venons de produire.
En effet, un fichier d'en-tête correctement rédigé doit être autosuffisant, c'est-à-dire qu'on doit pouvoir l'inclure dans n'importe quel module sans qu'il soit nécessaire de faire précéder cette inclusion d'autres déclarations.
Un bon moyen de s'en assurer consiste à placer l'inclusion de notre propre fichier d'en-tête au tout début du code source du module qu'il décrit.
C'est ce que nous avons fait pour module_A.h qui figure bien sur la première ligne de module_A.c.

{} Modules interdépendants

Nous poursuivons notre découverte des situations problématiques en ajoutant à notre programme un nouveau module qui dépend du précédent.

Ouvrez votre éditeur de texte préféré pour rédiger le contenu d'un nouveau fichier nommé module_B.c, par exemple : $ gedit module_B.c & ↵ Dans celui-ci saisissez (par copier/coller) le texte suivant :

// ...c'est à vous de compléter le début de ce fichier...

void
doSomething(Tag tag,
            int depth)
{
  indent(tag, depth); printf("entering doSomething()\n");
  indent(tag, depth); printf("...working hard...\n");
  indent(tag, depth); printf("leaving doSomething()\n");
}

Nous reconnaissons sans difficulté la définition d'une nouvelle fonction doSomething() dont le prototype et le corps ne reposent que sur des éléments déjà décrits.
Vous devez vous empresser d'appliquer immédiatement les recommandations précédentes en incluant au tout début de ce fichier l'en-tête module_B.h (qui n'existe pas encore) associé à ce module.
Pour les appels à indent() et printf(), il nous est à nouveau nécessaire d'inclure module_A.h et stdio.h.

Il nous faut désormais fournir le fichier module_B.h dont le contenu devra déclarer la fonction doSomething() (c'est à vous de le faire en vous inspirant du travail précédent).
Seulement, le prototype de cette fonction fait référence au type Tag (pour transmettre le premier paramètre à indent()) que le compilateur ne connaît pas encore à ce stade.
Ajoutez alors, avant la déclaration de doSomething(), l'inclusion de module_A.h.

Maintenant que notre module est complètement déclaré et défini, nous pouvons en faire usage dans le programme principal :

int
main(void)
{
  indent("* ", 1); printf("entering main()\n");
  doSomething("| ", 2);
  indent("* ", 1); printf("leaving main()\n");
  return 0;
}

Vous n'aurez bien entendu pas oublié d'ajouter à cette occasion l'inclusion de module_B.h dans prog01.c.

La reconstruction complète de votre programme repose désormais sur ces commandes : $ gcc prog01.c -c -std=c99 -pedantic ↵ $ gcc module_A.c -c -std=c99 -pedantic ↵ $ gcc module_B.c -c -std=c99 -pedantic ↵ $ gcc prog01.o module_A.o module_B.o -o prog01 ↵ Remarquez que nous avons ajouté les options -std=c99 -pedantic aux commandes de compilation afin de demander au compilateur de respecter “très scrupuleusement” la norme C99 du langage✍ ; il s'agit en effet à l'heure actuelle de la version la plus largement utilisée de ce langage.
(https://en.cppreference.com/w/c/language/history)
Malheureusement, les compilations de prog01.c et module_B.c échouent en indiquant que le type Tag est déclaré à de multiples reprises.
En effet, ces deux fichiers incluent à la fois module_A.h et module_B.h, mais le fichier d'en-tête module_B.h inclut lui-même module_A.h, ce qui fait qu'après la phase de préprocesseur, le compilateur voit deux fois les déclarations de module_A.h.
Pour nous en convaincre, visualisons à nouveau le travail du préprocesseur : $ gcc -E prog01.c ↵ $ gcc -E module_B.c ↵ Les déclarations du type Tag et de la fonction indent() apparaissent bien deux fois dans chacun de ces deux cas.

Une solution potentielle pour tenter de remédier à ce problème serait de s'interdire d'inclure module_A.h partout où nous incluons module_B.h (puisqu'il le fait pour nous).
Cependant, si nous avions affaire à des dizaines de modules dont plusieurs d'entre-eux seraient interdépendants comme ici, les intrications seraient telles que cette démarche serait inapplicable !
Il nous faut une nouvelle fois trouver un procédé systématique qui résout ce problème.

Modifiez simplement le fichier d'en-tête module_A.h de la façon suivante :

#ifndef MODULE_A_H
#define MODULE_A_H

// ...ici l'ancien contenu du fichier...

#endif // MODULE_A_H

et relancez le processus de construction du programme exécutable.
Cette fois il doit aboutir avec succès et le programme obtenu doit provoquer l'affichage des lignes de texte attendues.

Les symboles # (dièse) au début de chaque ligne ajoutée indiquent que nous utilisons ici des directives du préprocesseur.
Puisque ce dernier contrôle les lignes de code que le compilateur de langage C voit effectivement, nous lui donnons des consignes pour que le contenu de ce fichier d'en-tête ne soit vu qu'une seule fois par unité de compilation (translation unit).
Ce terme désigne la production d'un unique fichier objet à partir d'un unique module et des multiples fichiers d'en-tête qu'il inclut ; concrètement il s'agit d'une unique invocation du compilateur avec l'option -c.

Comme décrit dans cette section, le langage du préprocesseur permet de définir des macro-instructions (ou macros).
C'est le cas ici avec la directive #define qui définit la macro MODULE_A_H sans contenu spécifique✍.
La directive #ifndef (contraction de if not defined) est appairée avec la directive #endif pour exprimer une compilation conditionnelle.
Dans ces conditions, si la macro MODULE_A_H n'est pas définie, alors nous la définissons et les lignes de code enfermées dans cette construction restent visibles du compilateur.
En revanche, si cette macro est déjà définie, ces mêmes lignes de codes deviennent invisibles.
Lorsque le préprocesseur commence son travail, la macro en question n'est pas encore définie, donc la première fois qu'il cherchera à inclure ce fichier d'en-tête, son contenu sera intégralement pris en compte ce qui aura également pour effet de définir cette macro.
Si en poursuivant son travail, le préprocesseur cherche à inclure à nouveau ce même fichier, alors celui-ci semblera n'avoir cette fois aucun contenu.
Tout ceci fait qu'au bout du compte le compilateur de langage C ne verra qu'une seule fois les lignes de code constitutives d'un même fichier d'en-tête, même si celui-ci est inclus plusieurs fois au sein d'une unité de compilation.

Bien entendu, ceci suppose que chaque fichier d'en-tête soit associé à un nom de macro qui lui est spécifique, sans quoi l'inclusion de l'un d'eux risquerait d'inhiber l'inclusion d'un autre.
Une habitude courante consiste à s'inspirer, comme ici, du nom du fichier pour composer le nom de la macro✍.
Afin de systématiser cette pratique, veuillez faire une intervention similaire sur le fichier module_B.h avec une macro nommée MODULE_B_H.
Relancez enfin tout le processus de construction du programme exécutable pour vous assurer qu'aucune nouvelle erreur ne survient et que le programme reste fonctionnel.

Complément : analyse de l'exécution au débogueur

Maintenant que nous disposons d'un programme reposant sur plusieurs modules interdépendants, nous pouvons revenir à l'usage du débogueur pour inspecter les multiples appels de fonctions dont il est constitué.
Avant ceci, il vous faudra bien sûr compiler l'ensemble du code source avec l'option -g.

Au lancement de l'outil de débogage : $ tdb_prc prog01 ↵ notre programme est initialement en pause ; la toute première ligne de la fonction main() est mise en surbrillance pour indiquer qu'il s'agit de la prochaine ligne de code qui sera exécutée.

Nous procéderons à l'investigation selon les étapes suivantes :

un double-clic dans la zone d'affichage du code source, juste sur la ligne qui provoque l'appel à la fonction doSomething(), place un point d'arrêt
Terme de vocabulaire à connaître : point d'arrêt
Une ligne de code désignée dans un débogueur pour que l'exécution soit suspendue lorsqu'elle est atteinte.
Un point-d'arrêt permet d'atteindre rapidement une zone de code digne d'intérêt lors d'une session de débogage.
(break-point) matérialisé par un changement de couleur,
le bouton Continue [F8] (triangle) permet de lancer l'exécution du programme,
- la première ligne de texte littéral est produite dans la console et la zone de messages indique que le programme est arrêté sur le point-d'arrêt,
le bouton Step [F5] (entrée dans les accolades) permet d'atteindre la prochaine ligne de code dans le programme,
- nous sommes désormais sur la première ligne de la fonction doSomething() et la zone de messages nous indique la valeur de ses paramètres,
de nouveaux appuis sur ce même bouton nous font progresser pas-à-pas
Terme de vocabulaire à connaître : pas-à-pas
La démarche qui consiste à suspendre l'exécution du programme après chaque ligne de code lors d'une session de débogage.
Cela permet d'investiguer les conditions de réalisation et les effets de chacune d'elles lors de la recherche d'une erreur d'exécution.
(step-by-step) dans l'exécution,
- utilisez le bouton Call Stack pour visualiser la pile des appels de fonctions et leurs paramètres dans la zone de messages,
  - vous pouvez même utiliser les boutons Frame Up et Frame Down pour inspecter la pile d'appels alors que l'exécution reste arrêtée au même point,
- après l'exécution de indent() vous serez revenu à une nouvelle ligne de la fonction doSomething() et la deuxième ligne de texte littéral de votre programme aura été produite dans la console,
le bouton Next [F6] (saut au dessus des accolades) permet d'atteindre la prochaine ligne de code sans s'arrêter dans une fonction appelée,
- la troisième ligne de texte littéral est produite dans la console et nous sommes juste avant le troisième appel à indent() dans doSomething(),
le bouton Finish [F7] (sortie des accolades) permet de s'arrêter juste après la sortie de la fonction en cours,
- la quatrième ligne de texte littéral est produite dans la console et nous sommes revenus dans la fonction main(),
le bouton Continue [F8] relance l'exécution,
- la cinquième ligne de texte littéral est produite dans la console et la zone de messages nous indique que la fin du programme est atteinte,
nous quittons la session de débogage en fermant simplement la fenêtre de l'outil.

L'utilisation qui a été faite du débogueur ici visait à illustrer la démarche très classique qui consiste à atteindre quelques points intéressants d'un programme pour poursuivre progressivement son exécution en s'interrogeant à chaque fois sur les fonctions qui sont appelées et les paramètres qui leur sont transmis.
Ceci peut aider à la mise au point d'un programme en recherchant les maladresses qui peuvent être à l'origine d'un fonctionnement inattendu.

Cette manière de rédiger et d'utiliser les fichiers d'en-tête, pour construire un programme par compilation séparée, est un grand classique qu'il faudra dorénavant appliquer de façon systématique dans toutes vos futures réalisations.

{} Automatisation de la construction

Ces expérimentations autour de l'organisation et de la rédaction du code source nous ont conduits à relancer à plusieurs reprises le procédé de construction du programme exécutable.
Il s'agissait à chaque fois d'invoquer les multiples commandes de compilation (en changeant parfois les options, pour le débogage par exemple) ainsi que celle chargée de l'édition de liens.
Ce besoin reste très fréquent lorsque nous développons une application ; en effet il est recommandé de s'assurer régulièrement que les modifications apportées autorisent toujours une construction et une exécution correcte du programme.
Il pourrait sembler confortable d'inscrire une fois pour toutes l'intégralité de cette séquence de commandes dans un fichier script que le shell pourrait exécuter à notre demande.
Nous ferions ainsi l'économie de multiples rappels de commandes ; celle du script shell suffirait à elle seule.
Dans le cas présent, cette solution serait suffisante puisque nous ne manipulons que très peu de fichiers.
En revanche, dans un projet de grande ampleur la compilation de l'ensemble du code demande une durée non négligeable pendant laquelle le développeur est obligé d'attendre.

{} Un fichier makefile très spécifique

Pour répondre au besoin évoqué, il existe un outil qui fait partie intégrante de toute chaîne de développement (avec le compilateur, le débogueur...) : le programme make.
Sans être spécifique au langage C, il permet d'automatiser tout processus qui consiste à générer des fichiers à partir d'autres ; c'est justement le cas de la compilation et de l'édition de liens.
Lorsqu'on invoque ce programme, il analyse le contenu du fichier nommé makefile✍ situé dans le répertoire courant, afin d'y découvrir des relations de dépendance entre des fichiers (le programme exécutable, les fichiers objets, les fichiers sources, les fichiers d'en-tête...) ainsi que les commandes qui permettront de les résoudre (compilation, édition de liens...).

Ouvrez votre éditeur de texte préféré pour rédiger le contenu d'un nouveau fichier nommé makefile, par exemple : $ gedit makefile & ↵ Dans celui-ci, saisissez le texte suivant :

#~~~~ linker command to produce the executable file ~~~~
prog01 : prog01.o module_A.o module_B.o
	gcc prog01.o module_A.o module_B.o -o prog01

#~~~~ compiler commands for every source file ~~~~
prog01.o : prog01.c
	gcc prog01.c -c -std=c99 -pedantic

module_A.o : module_A.c
	gcc module_A.c -c -std=c99 -pedantic

module_B.o : module_B.c
	gcc module_B.c -c -std=c99 -pedantic

#~~~~ remove generated files ~~~~
clean :
	rm -f prog01 *.o

Le symbole # (dièse) représente le début d'un commentaire qui s'étend jusqu'à la fin de la ligne (comme en Python).
La première ligne de chacun des blocs de texte visibles ici est une règle.
Elle s'interprète de la façon suivante : la cible qui est à gauche du symbole : (deux-points) peut être produite à partir des prérequis qui sont à droite de ce même symbole ; nous reconnaissons effectivement ici le programme exécutable qui peut être produit à partir des trois fichiers objets.
La ligne qui suit immédiatement cette relation de dépendance débute par l'usage de la touche de tabulation✍.
Ceci indique qu'il s'agit de la commande qui permet de résoudre la dépendance immédiatement précédente pour fabriquer sa cible✍ ; nous reconnaissons effectivement ici la commande d'édition de liens et les trois commandes de compilation que nous utilisions jusqu'alors.
La dernière règle est quelque peu particulière puisque la cible ne correspond à aucun fichier et qu'il n'y a aucun prérequis.
Sa commande, quant à elle, repose sur la commande rm du shell qui sert à supprimer des fichiers ; ici le programme exécutable et les fichiers objets.
Cette construction est grand un classique du genre✍ ; elle sert à faire du ménage parmi les fichiers en supprimant tous ceux qui peuvent être générés automatiquement.

Désormais, lorsque vous saisissez dans le terminal la commande : $ make clean ↵ ce programme va chercher à fabriquer la cible clean explicitement indiquée.
Comme aucun fichier ayant ce nom n'existe et puisque le fichier makefile indique qu'elle ne dépend d'aucun prérequis, la commande de suppression des fichiers sera exécutée de manière inconditionnelle.
Si maintenant vous saisissez dans le terminal la commande : $ make ↵ ce programme cherchera à fabriquer la première cible✍ rencontrée dans le fichier makefile ; il s'agit ici de prog01.
Les prérequis sont alors analysés mais les fichiers objets en question n'existent pas, ce qui rend impossible l'exécution immédiate de la commande d'édition de liens.
Heureusement, il existe les trois règles concernant ces cibles ; le programme make va donc chercher à les fabriquer.
Chacune d'elles a pour prérequis un fichier de code source qui est bien présent ; la commande de compilation peut donc être exécutée pour chacun d'eux, ce qui produit les trois fichiers objets attendus.
Le programme make peut enfin exécuter la commande d'édition de liens pour produire sa cible principale prog01.

Vous avez dû constater qu'en fin de compte le programme make n'a fait qu'exécuter les commandes que vous saisissiez jusqu'alors dans le terminal.
Cependant, si vous saisissez à nouveau dans le terminal la commande : $ make ↵ cette dernière doit vous dire que votre programme exécutable est à jour et qu'il n'est donc pas nécessaire d'invoquer les commandes permettant de le fabriquer.
Il s'agit là d'un aspect fondamental de cet outil : les commandes ne sont exécutées que si la cible est inexistante ou si ses prérequis sont plus à jour qu'elle-même.
Le programme make compare en effet les dates de modification des fichiers pour prendre ses décisions.
Pour vous en convaincre, modifiez le contenu du fichier prog01.c en y ajoutant une ligne vide ou un commentaire, sauvegardez-le et relancez le programme make.
Vous devriez constater que seul celui-ci est recompilé, puis qu'immédiatement a lieu l'édition de liens, mais que les fichiers module_A.c et module_B.c ne sont pas recompilés.
C'est là que réside l'intérêt principal de cet outil : le programme make ne recompile que le strict nécessaire et non l'intégralité du projet.
Ceci permet de gagner un temps précieux lorsqu'on travaille sur de gros projets (notamment avec le langage C++ dont la durée de compilation est bien plus longue).

Reprenez maintenant la démarche consistant à provoquer une modification mineure du code source, mais cette fois-ci sur un fichier d'en-tête, module_B.h par exemple.
Utilisez à nouveau la commande make et observez son comportement : votre modification n'a provoqué aucune nouvelle compilation ce qui est incorrect puisque, comme vu précédemment, la modification d'une déclaration peut avoir des conséquences sévères sur la cohérence du programme.
En effet, la définition d'une unité de compilation que nous donnions plus haut montre que le contenu des multiples fichiers d'en-tête inclus depuis un fichier d'extension .c fait partie intégrante des lignes de code que le compilateur analyse pour produire un fichier objet ; la modification de la moindre de ces lignes doit donc provoquer la génération d'un nouveau fichier objet.
Il est vrai que, pour l'instant, le fichier makefile ne mentionne aucun fichier d'en-tête ; complétez alors les trois règles qui concernent la phase de compilation afin d'ajouter aux prérequis les fichiers d'en-tête que chaque fichier d'extension .c inclut directement ou indirectement (à l'exception de fichiers d'en-tête standards qui, eux, ne devraient pas avoir à être modifiés).

...

#~~~~ compiler commands for every source file ~~~~
prog01.o : prog01.c module_A.h module_B.h
	gcc prog01.c -c -std=c99 -pedantic

module_A.o : module_A.c module_A.h
	gcc module_A.c -c -std=c99 -pedantic

module_B.o : module_B.c module_B.h module_A.h
	gcc module_B.c -c -std=c99 -pedantic

...

Reprenez l'expérimentation pour constater que, dorénavant, la modification de module_B.h provoque bien une nouvelle compilation de prog01.c et module_B.c, et donc une nouvelle édition de liens.
Remarquez que module_A.o n'a pas besoin d'être reconstruit puisque le fichier d'en-tête modifié ne le concerne pas.

Notre démarche systématique en matière de programmation modulaire et le fichier makefile ainsi rédigé assurent désormais une fabrication correcte de notre application en toutes circonstances, sans pour autant nécessiter une compilation systématique de l'ensemble des fichiers de code source.

{} Généralisation du fichier makefile

Les éléments essentiels à comprendre à propos de l'utilité de l'outil make et de la démarche pour rédiger le fichier makefile ont été pleinement exposés dans le paragraphe précédent ; c'est ce qu'il vous faudra retenir en priorité.
Il ne s'agit maintenant que d'exposer brièvement quelques facilités pour rédiger un fichier makefile de façon à ce qu'il soit facilement modifiable et réutilisable dans des contextes variés.
Les prochaines expérimentations et les prochains exercices s'appuieront en effet sur l'usage d'un fichier makefile générique, tel que celui qui est indiqué à la fin de ce sujet.

Un tout premier moyen de donner de la souplesse dans l'usage d'un fichier makefile consiste à utiliser des variables.
En effet, si nous décidions de changer de version de compilateur, ou bien de changer les options de compilation (ce fut le cas précédemment pour utiliser le débogueur), il nous faudrait, en l'état actuel, intervenir à de multiples reprises.
En revanche, une formulation telle que celle-ci :

#~~~~ settings ~~~~
CC=gcc
CFLAGS=-std=c99 -pedantic -g

...

#~~~~ compiler commands for every source file ~~~~
prog01.o : prog01.c module_A.h module_B.h
	${CC} prog01.c -c ${CFLAGS}

module_A.o : module_A.c module_A.h
	${CC} module_A.c -c ${CFLAGS}

module_B.o : module_B.c module_B.h module_A.h
	${CC} module_B.c -c ${CFLAGS}

...

permet au contraire de modifier l'ensemble des commandes de compilation en intervenant seulement sur la variable CFLAGS.
Remarquez que la valeur d'une telle variable s'obtient avec les symboles $ (dollar) et

{}

(accolades, ou encore (), parenthèses).
Le nom de ces variables est libre mais l'usage courant retient souvent les mêmes noms.
(https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html)

Un autre point qui mérite d'être amélioré concerne le fait que nous devons rappeler à plusieurs reprises les mêmes noms de fichiers dans les règles et les commandes qui les accompagnent, ce qui, au-delà de l'inconfort, est source d'erreurs de saisie.
Il existe toutefois des variables fournies automatiquement par le programme make pour nous éviter les duplications de noms de fichiers.
Voici un nouvel exemple de formulation pour l'édition de liens et la compilation :

...

#~~~~ linker command to produce the executable file ~~~~
prog01 : prog01.o module_A.o module_B.o
	${CC} $^ -o $@

#~~~~ compiler commands for every source file ~~~~
prog01.o : prog01.c module_A.h module_B.h
	${CC} $< -c ${CFLAGS}

module_A.o : module_A.c module_A.h
	${CC} $< -c ${CFLAGS}

module_B.o : module_B.c module_B.h module_A.h
	${CC} $< -c ${CFLAGS}

...

dans lequel les symboles $@ (dollar-arobas), $^ (dollar-accent-circonflexe), et $< (dollar-inférieur) représentent respectivement la cible (prog01), les prérequis (les trois fichiers objets) et le premier des prérequis (prog01.c, module_A.c ou module_B.c selon le cas).
(https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html)

Dans ces conditions, il est même envisageable d'écrire une fois pour toutes des règles génériques précisant les commandes de compilation et d'édition de liens, pour n'avoir qu'à formuler les cibles et les prérequis spécifiques à notre projet (sans répéter la commande) :

...

#~~~~ dependencies ~~~~
prog01 : prog01.o module_A.o module_B.o
prog01.o : prog01.c module_A.h module_B.h
module_A.o : module_A.c module_A.h
module_B.o : module_B.c module_B.h module_A.h

#~~~~ generic linker command to produce an executable file ~~~~
% : %.o
	${CC} $^ -o $@

#~~~~ generic compiler commands for every source file ~~~~
%.o : %.c
	${CC} $< -c ${CFLAGS}

...

Ici la notation % : %.o s'interprète comme : fabriquer une cible à partir d'un fichier objet ayant le même nom à l'extension près ; il s'agit bien de la commande d'édition de liens.
De la même façon, la notation %.o : %.c s'interprète comme : fabriquer un fichier objet à partir du code source ayant le même nom à l'extension près ; il s'agit bien de la commande de compilation.
À l'utilisation de make, les symboles $^, $@ et $< prennent bien les valeurs suggérées par les cibles et les prérequis des règles que nous avons spécifiées juste avant.

Un point important qui mérite d'être discuté ici concerne l'énumération des fichiers d'en-tête à prendre en compte dans les prérequis d'une règle ; il s'agit d'un travail fastidieux et source d'erreurs.
En effet, il faut non seulement considérer les inclusions directes mais également les inclusions induites par les précédentes.
Si nous en oublions, la reconstruction du projet risque d'être incomplète et de donner un programme exécutable incohérent.
Si au contraire nous choisissons d'énumérer tous les fichiers d'en-tête du projet pour chaque règle de compilation, alors la modification d'un seul d'entre-eux provoquera la compilation de l'ensemble du projet.
Le mieux placé pour faire ce travail de recensement est finalement le préprocesseur lui même !
Ajoutez alors l'option -MMD à la variable CFLAGS et faites du nettoyage avec make clean pour que la commande make compile bien tous les fichiers d'extension .c avec cette nouvelle option.
Dans votre répertoire de travail a dû apparaître pour chacun d'eux un nouveau fichier de même nom mais avec l'extension .d.
Visualisez le contenu de ces trois nouveaux fichiers : chacun contient une règle qui a exactement la même cible et les mêmes prérequis que ce que nous avions explicitement renseigné dans le fichier makefile, si ce n'est que ces informations ont été générées automatiquement par le préprocesseur lorsqu'il a analysé les fichiers en question.
Retirez donc ces trois règles du fichier makefile et remplacez-les par une ligne d'inclusion des fichiers d'extension .d (s'ils existent) :

...

#~~~~ dependencies ~~~~
prog01 : prog01.o module_A.o module_B.o
-include *.d

...

Ces fichiers fournissent donc à nouveau, mais de manière automatique, les règles que nous venons de retirer.
Bien entendu, la règle de nettoyage doit maintenant supprimer ces fichiers qui sont eux-aussi générés automatiquement :

...

#~~~~ remove generated files ~~~~
clean :
	rm -f prog01 *.o *.d

Dans ces nouvelles conditions, le programme make doit toujours se comporter comme précédemment, en ne reconstruisant que ce qui est nécessaire mais sans rien oublier.
Nous avons cependant retiré du fichier makefile beaucoup d'informations redondantes ou fastidieuses à déterminer, ce qui limite les oublis ou erreurs potentiels.

Finalement, pour être en accord avec la contrainte que nous nous imposerons dans l'usage d'un fichier makefile générique tel que celui qui est fourni à la fin de ce sujet, il nous reste à décrire les options de compilation suivantes :

CFLAGS=-std=c99 -pedantic -MMD -g \
       -Werror -Wall -Wextra -Wconversion -Wc++-compat \
       -Wwrite-strings -Wold-style-definition -Wvla

Les options de la première ligne✍ ont déjà été présentées ; elles concernent le respect très strict de la norme C99 du langage C, la génération automatique des règles de dépendances et la possibilité d'utiliser un débogueur.
Les options des deux dernières lignes demandent au compilateur d'être le plus sévère possible dans le signalement des avertissements (-W...) ; elles sont très importantes car elles augmentent nos chances de détecter au plus tôt des maladresses ou des ambiguïtés dans la programmation, ce qui améliore la robustesse et la portabilité de notre code source.

Une démarche systématique en matière de programmation modulaire et un fichier makefile correctement rédigé assurent une fabrication correcte de notre application en toutes circonstances, sans pour autant nécessiter une compilation systématique de l'ensemble des fichiers de code source.
Grâce à quelques fonctionnalités génériques, un fichier makefile peut être systématisé au point de ne contenir que très peu d'informations spécifiques aux fichiers de l'application réalisée.
L'important ici n'est pas de savoir rédiger de mémoire un tel fichier mais de comprendre les principes sur lesquels il repose.

Pour nos réalisations futures✍, nous utiliserons désormais le fichier GNUmakefile✍ fournit en fin de chapitre.
Celui-ci a notamment les propriétés suivantes :

il fabrique automatiquement un programme dont le nom commence par prog (ceci est configurable) à partir de chaque fichier de code source (.c) commençant par ce même préfixe (considéré comme le programme principal) et tous les autres fichiers de code source ne commençant pas par ce préfixe (considérés comme des modules de ce programme),
il s'adapte à une grande variété de plateformes (Linux, Windows, MacOSX...),
il utilise par défaut des options facilitant la mise au point et notamment la détection d'incohérences lors de l'exécution (le sanitizer, voir cette section),
il offre la possibilité de compiler le code en replaçant les options de mise au point par d'autres qui favorisent une optimisation très agressive du code exécutable généré (make rebuild opt=1, voir cette section).

Code source de l'expérimentation

Si chaque étape a été respectée scrupuleusement, vous devez obtenir des fichiers de code source et semblables à ceux-ci :

Fichier module_A.h✎

Fichier module_A.c✎

Fichier module_B.h✎

Fichier module_B.c✎

Fichier prog01.c✎

La fabrication pourra utiliser ce fichier GNUmakefile✎

Contenu du fichier GNUmakefile

#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# this GNU-makefile relies on the GCC toolchain
# nb: on Windows, the Mingw-w64 package provides the mingw32-make.exe command
#     ( see https://web.enib.fr/~harrouet/dev_tools/#windows.mingw )

#~~~~ control global settings ~~~~
# make opt=2 --> enable optimisation, then disable debug, but keep symbols
# make opt=1 --> enable optimisation, then disable debug
# make opt=0 --> disable optimisation, then enable debug
opt=0
# make clang=1 --> use clang/clang++, not gcc/g++
# make clang=0 --> use gcc/g++, not clang/clang++
clang=0
# make wasm=1 --> target webassembly rather than the native platform
# make wasm=0 --> target the native platform rather than webassembly
wasm=0

#~~~~ build library or programs ~~~~
# if LIB_TARGET is provided, this library will be built (with its
# platform-specific name), otherwise ${EXE_PREFIX}* programs will be built
LIB_TARGET=
EXE_PREFIX=prog

#~~~~ detect operating system ~~~~
ifneq (${OS},Windows_NT)
  ifneq (,${findstring Ubuntu,${shell lsb_release -i 2>/dev/null}})
    OS:=Ubuntu
  else ifneq (,${findstring Raspbian,${shell lsb_release -i 2>/dev/null}})
    # Standard distribution for Raspberry-Pi
    OS:=Raspbian
  else
    OS:=${strip ${shell uname -s}}
  endif
  ifneq (,${findstring Microsoft,${shell cat /proc/version 2>/dev/null}})
    # Windows-Subsystem-for-Linux
    OS:=${OS}_WSL
  endif
endif

#~~~~ adjust project-specific settings ~~~~
CPPFLAGS=
# CPPFLAGS+=-I header/path
LDFLAGS=
# LDFLAGS+=-L library/path -Wl,-rpath,library/path -l library_name
CFLAGS=
CXXFLAGS=
BINFLAGS=
ifneq (,${findstring Windows_NT,${OS}})
  # nothing special for now
else
  ifneq (,${strip ${LIB_TARGET}})
    BINFLAGS+=-fPIC
  endif
  ifneq (,${findstring Darwin,${OS}})
    # nothing special for now
  else
    ifneq (,${findstring Ubuntu,${OS}})
      # sanitizer sometimes requires gold-linker on Ubuntu
      LDFLAGS+=-fuse-ld=gold
    else ifneq (,${findstring Raspbian,${OS}})
      # some warnings may appear when mixing g++-6 and g++-7 on Raspbian
      CXXFLAGS+=-Wno-psabi
    else
      # nothing special for now
    endif
  endif
endif

#~~~~ adjust platform-specific features (Posix/Windows/Emscripten...) ~~~~
ifneq (,${findstring Windows_NT,${OS}})
  LIB_PREFIX=
  LIB_SUFFIX=.dll
  EXE_SUFFIX=.exe
  SKIP_LINE=echo.
  REMOVE=del /q
else
  LIB_PREFIX=lib
  ifneq (,${findstring Darwin,${OS}})
    LIB_SUFFIX=.dylib
  else
    LIB_SUFFIX=.so
  endif
  EXE_SUFFIX=
  SKIP_LINE=echo
  REMOVE=rm -rf
endif
ifeq (${strip ${wasm}},1)
  LIB_PREFIX:=lib
  LIB_SUFFIX:=.bc
  EXE_SUFFIX:=.html
endif

#~~~~ deduce file names ~~~~
ifneq (,${strip ${LIB_TARGET}})
  LIB_TARGET:=${LIB_PREFIX}${strip ${LIB_TARGET}}${LIB_SUFFIX}
  MAIN_C_FILES=
  MAIN_CXX_FILES=
else
  LIB_TARGET:=
  MAIN_C_FILES=${wildcard ${strip ${EXE_PREFIX}}*.c}
  MAIN_CXX_FILES=${wildcard ${strip ${EXE_PREFIX}}*.cpp}
endif
COMMON_C_FILES=${filter-out ${MAIN_C_FILES},${wildcard *.c}}
COMMON_CXX_FILES=${filter-out ${MAIN_CXX_FILES},${wildcard *.cpp}}
#
MAIN_OBJECT_FILES=${sort ${patsubst %.c,%.o,${MAIN_C_FILES}} \
                         ${patsubst %.cpp,%.o,${MAIN_CXX_FILES}}}
COMMON_OBJECT_FILES=${sort ${patsubst %.c,%.o,${COMMON_C_FILES}} \
                           ${patsubst %.cpp,%.o,${COMMON_CXX_FILES}}}
OBJECT_FILES=${MAIN_OBJECT_FILES} ${COMMON_OBJECT_FILES}
DEPEND_FILES=${patsubst %.o,%.d,${OBJECT_FILES}}
EXE_FILES=${sort ${patsubst %.c,%${EXE_SUFFIX},${MAIN_C_FILES}} \
                 ${patsubst %.cpp,%${EXE_SUFFIX},${MAIN_CXX_FILES}}}
#
GENERATED_FILES=${DEPEND_FILES} ${OBJECT_FILES} ${LIB_TARGET} ${EXE_FILES}
ifneq (,${findstring Darwin,${OS}})
  GENERATED_FILES+=${wildcard *.dSYM}
endif
ifeq (${strip ${wasm}},1)
  GENERATED_FILES+=${patsubst %.html,%.js,${EXE_FILES}}
  GENERATED_FILES+=${patsubst %.html,%.html.mem,${EXE_FILES}}
  GENERATED_FILES+=${patsubst %.html,%.wasm,${EXE_FILES}}
  GENERATED_FILES+=${patsubst %.html,%.wast,${EXE_FILES}}
endif
GENERATED_FILES+=${wildcard output_* *~}

#~~~~ compiler/linker settings ~~~~
CPPFLAGS+=-MMD -pedantic -Wall -Wextra -Wconversion -Wno-sign-conversion
CPPFLAGS+=-Wno-unused -Wno-unused-parameter
CPPFLAGS+=-Werror -Wfatal-errors
CFLAGS+=-std=c99 -Wc++-compat -Wwrite-strings -Wold-style-definition -Wvla
CXXFLAGS+=-std=c++17 -Wno-missing-braces
LDFLAGS+=
BINFLAGS+=
ifeq (${strip ${wasm}},1)
  CC=emcc
  CXX=em++
  CPPFLAGS+=-Wno-dollar-in-identifier-extension
  LDFLAGS+=-s ALLOW_MEMORY_GROWTH=1
else ifeq (${strip ${clang}},1)
  CC=clang
  CXX=clang++
else
  CC=gcc
  CXX=g++
endif
#
ifneq (,${strip ${MAIN_CXX_FILES} ${COMMON_CXX_FILES}})
  # force c++ link if there is at least one c++ source file
  LD:=${CXX}
else
  LD:=${CC}
endif

#~~~~ debug/optimisation settings ~~~~
ifneq (${strip ${opt}},0)
  CPPFLAGS+=-DNDEBUG
  BINFLAGS+=-O3 -ffast-math
  # BINFLAGS+=-fopt-info-vec-optimized
  ifneq (${strip ${wasm}},1)
    BINFLAGS+=-march=native
  endif
  ifeq (${strip ${opt}},2)
    # optimise but keep symbols for profiling
    BINFLAGS+=-g -fno-omit-frame-pointer
  else
    BINFLAGS+=-fomit-frame-pointer
  endif
else
  CPPFLAGS+=-UNDEBUG
  BINFLAGS+=-g -O0
  ifeq (${strip ${wasm}},1)
    # sanitizer is not available yet with Emscripten
  else ifneq (,${findstring Windows_NT,${OS}})
    # sanitizer is not available yet on Windows
  else
    BINFLAGS+=-fsanitize=address,undefined
    ifneq (,${findstring Raspbian,${OS}})
      # dynamic sanitizer libraries may not be found on Raspbian
      BINFLAGS+=-static-libasan -static-libubsan
    endif
  endif
endif

#~~~~ main target ~~~~
all : ${EXE_FILES} ${LIB_TARGET}

rebuild : clean all

.SUFFIXES:
.SECONDARY:
.PHONY: all clean rebuild

#~~~~ linker command to produce the library (if any) ~~~~
${LIB_TARGET} : ${COMMON_OBJECT_FILES}
	@echo ==== linking [opt=${opt}] $@ ====
	${LD} -shared -o $@ $^ ${BINFLAGS} ${LDFLAGS}
	@${SKIP_LINE}

#~~~~ linker command to produce the executable files (if any) ~~~~
%${EXE_SUFFIX} : %.o ${COMMON_OBJECT_FILES}
	@echo ==== linking [opt=${opt}] $@ ====
	${LD} -o $@ $^ ${BINFLAGS} ${LDFLAGS}
	@${SKIP_LINE}

#~~~~ compiler command for every source file ~~~~
%.o : %.c
	@echo ==== compiling [opt=${opt}] $< ====
	${CC} -o $@ $< -c ${BINFLAGS} ${CPPFLAGS} ${CFLAGS}
	@${SKIP_LINE}

%.o : %.cpp
	@echo ==== compiling [opt=${opt}] $< ====
	${CXX} -o $@ $< -c ${BINFLAGS} ${CPPFLAGS} ${CXXFLAGS}
	@${SKIP_LINE}

-include ${DEPEND_FILES}

#~~~~ remove generated files ~~~~
clean :
	@echo ==== cleaning ====
	${REMOVE} ${GENERATED_FILES}
	@${SKIP_LINE}

#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

générique (comme pour toutes nos réalisations futures) que la commande make exploitera par défaut.
Toutefois, ces deux autres variantes des fichiers makefile réalisées et détaillées dans ce chapitre :

Fichier simple.mk✎

Fichier advanced.mk✎

sont également utilisables en spécifiant explicitement leur nom avec l'option -f de la commande make : $ make -f simple.mk ↵ $ make -f simple.mk clean ↵ $ make -f advanced.mk ↵ $ make -f advanced.mk clean ↵