Compilation séparée et make

Cette partie rappelle les motivations et les principes de la compilation séparée et de l'outil make. Vous connaissez sans doute déjà les notions qu'elle présente et vous pouvez probablement l'ignorer. Toutefois, n'hésitez pas à vous y référer si certains points du TP ne vous semblent pas clairs.

Programmer de facon modulaire

Idéalement, un programme qui utilise une bibliothèque de fonctions doit être indépendant de la facon dont est écrite cette bibliothèque. Autrement dit on doit pouvoir changer l'implémentation de la bibliothèque sans pour autant changer le code qui utilise cette bibliothèque. Prenons pour exemple une bibliothèque permettant de manipuler des nombres complexes. Nous pouvons penser à au moins deux representations possibles :

• un tableau de deux doubles
• une structure de deux doubles

Un autre exemple interessant est celui des vecteurs ou des matrices que vous avez vu au précédent TP. De facon générale, il n'est pas envisageable que les programmes utilisant une bibliothèque d'objets (nombres complexes, vecteurs, matrices, ...) soient obligés de déclarer explicitement la structure de ces objets (structure, tableau, liste, ...). La solution est d'utiliser un nouveau type pour les objets complexes manipulés par la bibliotheque, on parle alors de type abstrait (car il abstrait les détails d'implémentation) ou de handle (dans certaines documentations en anglais). Dans le cas de nos complexes cela peut être :

typedef struct { double r,i; } complexe;

Il faut alors définir les fonctions qui vont avec, que nous pouvons regrouper en deux catégories :

• des fonctions de construction et d'accès au nouveau type abstrait. Elles servent à manipuler le type abstrait sans connaître le détail de sa réalisation :

  complexe construire_complexe(double, double);
  double partie_reelle(complexe);
  double partie_imaginaire(complexe);
  

• des opérateurs entre objets de notre nouveau type abstrait :

  complexe addition(complexe, complexe);
  complexe soustraction(complexe, complexe);
  complexe multiplication(complexe, complexe);
  complexe division(complexe, complexe);
  

Pour utiliser notre bibliothèque, on va alors se demander comment regrouper l'implémentation de cette bibliothèque (écrite dans un fichier indépendant, par exemple complexe.c) et un autre programme. La manière la plus simple de tout regrouper consiste à tout compiler ensemble :

gcc -Wall -Werror -o programme programme.c complexe.c

Retour sur la compilation d'un programme en C

Lorsque nous compilons un programme C avec gcc, la ligne de compilation habituelle est la suivante : gcc -Wall -Werror -o programme programme.c

Cette commande compile notre programme en enchaînant deux étapes principales :

• la traduction du langage C contenu dans programme.c dans le langage de la machine (binaire) afin de produire un fichier appelé fichier objet relogeable (extension .o par convention). Ce fichier contient éventuellement des parties incomplètes (appels de fonctions ou utilisation de variables contenues dans d'autres fichiers ou bibliothèques). gcc nous permet d'effectuer cette étape seule à l'aide de l'option -c :

      gcc -Wall -Werror -c programme.c
  	

  un fichier programme.o est produit
• le regroupement des variables et fonctions du programme avec des fonctions fournies par des bibliotheques du systeme ou faites par l'utilisateur. Cette étape est appelée edition de liens. Lorsque nous fournissons un ensemble de fichiers objet à gcc, il n'effectue que l'édition de liens :

      gcc -o programme programme.o
  	

  un fichier executable programme est produit

A ce stade, nous pouvons classer les erreurs de compilation en deux catégories :

• les erreurs de syntaxe produites lors de la première phase lorsque le code n'est pas écrit en C correct
• les erreurs de résolution des symboles produites lors de la deuxième phase lorsque des variables ou fonctions utilisées ne sont définies nulle part ou sont définies plusieurs fois. Ces erreurs sont signalées par la commande ld qui est l'éditeur de liens invoqué par gcc lors de la deuxième étape de compilation

Decouper en plusieurs fichiers, prototypes, variables externes

La première étape de la compilation fonctionne du moment que le fichier fournit contient une suite syntaxiquement correcte de déclarations. Il est donc possible de produire un fichier .o contenant des déclaration de fonctions et variables sans que le fichier .c correspondant ne contienne de main.

La deuxième étape regroupe un ou plusieurs .o avec des fonctions de bibliothèques pour produire un exécutable. Dans cas, un des fichier doit contenir le main. On peut donc découper un programme en plusieurs fichiers regroupant ainsi les différentes parties par thème ou fonctionalité. Sur notre exemple des nombres complexes, cela pourrait donner :

• production de deux fichiers objet :

  gcc -Wall -Werror -c complexe.c
  gcc -Wall -Werror -c programme.c
  

• production de l'exécutable :

  gcc -o programme complexe.o programme.o
  

Il reste tout de même un problème : dans les fichiers objet, pour que le compilateur puisse générer le code correspondant à l'appel d'une fonction contenue dans un fichier different, il faut savoir comment l'appeler. Le même problème se pose pour les variables globales. Pour résoudre ce problème, le langage C nous fournit les prototypes de fonctions et les déclarations externes.

Un prototype ressemble a une declaration de fonction dans laquelle on aurait supprime le corps, par exemple :

int additionne(int x, int y);

extern int additionne(int x, int y);

A titre d'exemple, un programme complet constitué de deux fichiers, correspondant à notre exemple sur les complexes, pourrait être :

• fichier complexe.c :

  typedef struct { double r,i; } complexe;
  
  complexe construire(double r, double im)
  {
    complexe resultat;
  
    resultat.r = r;
    resultat.i = im;
  
    return resultat;
  }
  
  double partie_reelle(complexe c)
  {
    return c.r;
  }
  ...
  

• fichier programme.c :

  typedef struct { double r,i; } complexe;
  
  complexe construire(double r, double im);
  double partie_reelle(complexe c);
  ...
  
  int main()
  {
    complexe c;
  
    c=construire(5.2,6);
    ...
  

Fichiers d'entête (ou encore headers, fichiers .h)

Afin d'eviter de redeclarer plusieurs fois les memes prototypes et les meme typesdef dans plusieurs fichiers sources, on regroupe generalement toutes les informations associee a un fichier .c dans un fichier .h (declarations de types, prototypes, etc.). Il suffit alors d'inclure le fichier .h dans toutes les sources utilisant les fonctions du .c associe. En reprenant l'exemple précédent, nous obtenons :

• fichier complexe.h :

  typedef struct { double r,i; } complexe;
  
  complexe construire(double r, double im);
  double partie_reelle(complexe c);
  ...
  

• fichier complexe.c :

  #include "complexe.h"
  
  complexe construire(double r, double im)
  {
    complexe resultat;
  
    resultat.r = r;
    resultat.i = im;
  
    return resultat;
  }
  
  double partie_reelle(complexe c)
  {
    return c.r;
  }
  ...
  

• fichier programme.c :

  #include "complexe.h"
  
  int main()
  {
    complexe c;
  
    c=construire(5.2,6);
    ...
  

Ainsi tout programme ayant besoin des nombres complexes a juste besoin d'inclure complexe.h. C'est aussi comme ca que sont gérées les fonctions fournies par le systeme en standard (ex: malloc/free dans stdlib.h). En plus d'éviter de dupliquer du code dans toutes les sources ceci permet de changer simplement l'implémentation d'une partie du code en ne changeant que le .h et le .c concernés. De manière générale, on prend soin de mettre dans le .h le minimum d'inclusions d'autres .h necessaires à sa compilation (première étape). On mettra dans le .c associe toutes les autres inclusions dont cette partie du code a besoin.

Il reste juste un dernier problème : il ne faut pas inclure plusieurs fois le même contenu dans un code (typedef, prototypes, ...) sous peine d'obtenir une erreur (légitime) lors de la compilation. Or, après quelques inclusions en cascade il devient impossible de savoir quel fichier est inclus a quel endroit. C'est là que le préprocesseur vient nous aider.

Notions de base sur le préprocesseur

Lors de la compilation, la première chose effectuée par le compilateur est de passer le texte source du programme à travers un zinzin nommé préprocesseur. Le travail du préprocesseur consiste à éliminer les commentaires et tenir compte des directives qui lui sont addressées. Il est possible d'afficher un programme aprés le passage du préprocesseur avec la commande :

gcc -E programme.c

Les principales directives servent a :

• inclure des informations nécessaires à la compilation en provenance du systeme et/ou de l'utilisateur (la différence vient de l'endroit ou le fichier est recherché) :

  • #include 
    

    inclus un fichier d'en-tete du systeme, par exemple :

    #include 
    

  • #include "fichier utilisateur"
    

    inclus un fichier fourni par l'utilisateur, par exemple :

    #include "complexe.h"
    

• définir des constantes littérales propres au système ou au programme :

  #define MAX_INT 32768
  

  Pour ce genre de définitions, faire très attention au parenthesage, par exemple :

  #define TREIZE 8+5
    
  #include 
  int main() {
      /* Mon programme a moi */
      printf("Treize : %d\n", TREIZE);
      printf("Treize fois quatre : %d\n", TREIZE*4);
      return 0;
  }
  

  Apres gcc -E on obtient (outre le contenu de stdio.h) :

  int main() {
      printf("Treize : %d\n", 8+5);
      printf("Treize fois quatre : %d\n", 8+5*4);
      return 0;
  }
  

  ... qui n'affiche pas forcément ce qu'on pouvait imaginer.
• définir des macros, par exemple :

  #define carre(x) x*x
  

  Là encore, attention au parenthesage :

  int main () {
      printf("Voici le carre de %d : %d\n", 5+3, carre(5+3));
      return 0;
  }
  

  n'affiche pas 64. Un version correcte serait :

  #define carre(x) ((x)*(x))
  

  La leçon à retenir est que les macros sont dangereuses car remplacées textuellement (pas d'inférence de type, risques de conversion implicite, précédence des opérateurs peu visible, lecture difficile). Il vaut donc mieux éviter de les utiliser excepté dans des cas particuliers (instrumentation de code sans modification, débuggage, cela fera l'objet de futurs TPs).
• éliminer des morceaux de code source, ne compiler qu'une partie du code, suivant la configuration actuelle (variantes #if, #ifdef ou #ifndef avec dans tous les cas un #else possible), quelques exemples concrets :
  • - fichiers d'en-tete :

    /* verifie si mon en-tete a deja ete lu */
    #ifndef __MON_ENTETE__
    /* si non, on le lit apres avoir marque le fait qu'on va le lire */
    #define __MON_ENTETE__
    
    prototypes divers et varies, declarations de variables externes ou de
    types,...
    
    #endif
    

  • code temporaire ou qu'il est possible de supprimer facilement lors de la compilation :

    #define COMPILE_WITH_DEBUG
    
    ...
    #ifdef COMPILE_WITH_DEBUG
        printf("Debugging information : ... \n");
    #endif
    

  • éliminer un morceau de code :

    #if 0
        printf("Bonjour\n");
        ...
    #endif
    

  les deux dernieres formes sont à utiliser avec prudence puisque le code est complètement élimine lors de la compilation. En général on préfère des tests directement en C pour gérer les options sans recompiler.

  En conclusion generale sur le préprocesseur, on peut dire qu'il sert à écrire des fichiers d'en-tete propres et à définir certaines constantes du système. Tout le reste doit être évité sauf dans le cas d'écriture de code temporaire ou de débuggage. Si vous avez envie d'entrer dans le détail, le compilateur accepte un certain nombre d'options en rapport avec le préprocesseur :

  • -I NOM : ajoute un NOM de repertoire au chemin de recherche de fichiers inclus
  • -D NOM=VALEUR : ajoute un nouveau symbole (comme si #define NOM VALEUR se trouvait au debut du code)
  • -E : produit a l'ecran les code apres le passage du preprocesseur

  Pour revenir a notre exemple sur les complexes, on obtient donc le resultat suivant dans lequel complexe.h peut etre inclus plusieurs fois (seule la premiere inclusion est prise en compte) :

  • fichier complexe.h :

    #ifndef __COMPLEXE__
    #define __COMPLEXE__
    
    typedef struct { double r,i; } complexe;
    
    complexe construire(double r, double im);
    double partie_reelle(complexe c);
    ...
    
    #endif
    

  • fichier complexe.c :

    #include "complexe.h"
    
    complexe construire(double r, double im)
    {
      complexe resultat;
    
      resultat.r = r;
      resultat.i = im;
    
      return resultat;
    }
    
    double partie_reelle(complexe c)
    {
      return c.r;
    }
    ...
    

  • fichier programme.c :

    #include "complexe.h"
    
    int main()
    {
      complexe c;
    
      c=construire(5.2,6);
      ...
    

Dependances

La question qui se pose maintenant est la suivante : quels fichiers sont-ils nécessaires à chaque ligne de compilation et quelles parties du processus de compilation faut-il refaire lorsqu'on modifies seulement l'un des fichiers ?

Il est possible d'étudier le cas de chaque fichier :

• si on change complexe.h, tout le monde s'en sert d'une maniere ou d'une autre, il faut tout refaire : l'obtention de chacun des objets depend du contenu de complexe.h
• si on change complexe.c, ca n'a d'impact que sur une partie des objets, on ne refait que la 1ère et la dernière lignes de compilation : l'obtention de complexe.o dépend du contenu de complexe.c et l'obtention du programme final complexe dépend du contenu de complexe.o
• ...

Pour connaître les dépendences relatives à un fichier source, il est possible :

• d'étudier parfaitement le code source (fastidieux)
• d'utiliser gcc avec l'option -MM, par exemple :

  gcc -MM complexe_io.c
  

  affiche

  complexe_io.o: complexe_io.c complexe_io.h complexe.h
  

  ce qui signifie que la cible complexe_io.o depend de complexe_io.c, complexe_io.h et complexe.h.

make

Un outil merveilleux existe pour automatiser le processus de compilation : make Le principe de make est simple : make connaît un certain nombre de cibles, les dépendences qui vont avec et le moyen de les construire. Il suffit alors de demander à make de construire une cible pour qu'il le fasse en ne reconstruisant que ce qui est nécessaire.

make va chercher ses informations dans un fichier appele Makefile par defaut. Ce fichier contient des règles sous la forme suivante (on remarque que la ligne de dépendances est au format fournit par gcc -MM) :

cible: fichiers dont elle dépend
<TAB> commandes a utiliser pour reconstruire la cible

programme: programme.o complexe.o
	gcc -o programme programme.o complexe.o

programme.o: programme.c complexe.h
	gcc -Wall -Werror -c programme.c

complexe.o: complexe.c complexe.h
	gcc -Wall -Werror -c complexe.c

Il suffit alors d'invoquer 'make programme' pour que la compilation du programme final 'programme' se fasse. On peut aussi se contenter de 'make' car si aucune cible n'est précisée, make reconstruit la première du Makefile. Si on relance plusieurs fois cette commande on obtient le message :

make: « complexe » est à jour.

Si maintenant nous modifions l'un des fichiers :

> touch complexe_io.h
> make
gcc -Wall -Werror -c main.c
gcc -Wall -Werror -c complexe_io.c
gcc -o complexe main.o complexe.o complexe_io.o