# Zone où typiquement seront placées des déclarations de variables et de règles # (voir plus tard)

Transcription

1 UNIVERSITÉ DE NICE SOPHIA ANTIPOLIS UFR FACULTÉ DES SCIENCES Parc Valrose BP 71 F NICE Cedex 2 Licence 3 d Informatique Environnement de Programmation Philippe Collet Séance de TP n 02 de la semaine du 3 février 2006 Make et autres outils pour la construction Corrigé Objectifs Comprendre le fonctionnement d un Makefile explicite (cible, dépendance, mise à jour), puis des règles implicites. Créer un Makefile par adaptation. Expérimenter quelques directives. 1. Makefile explicite pour le programme de conversion Nous allons construire et modifier progressivement un Makefile pour automatiser au mieux la construction de l outil de conversion, implémenté en C et vu en cours Première version élémentaire Créez un répertoire TP2 pour ce TP. Créez un répertoire /l3i8/tp2/1.conversion pour cette question. Récupérez l archive conversion.tgz et décompactez la dans ce répertoire. ~> cd ~/l3i8 ; mkdir TP2 TP2/1.conversion ; cd TP2/1.conversion # r é c u p é r a t i o n d e l a r c h i v e a v e c M o z i l l a ~> ls -l total 6 -rw-r--r-- 1 rr profs 261 Feb Makefile.1 -rw-r--r-- 1 rr profs 693 Feb convert2sens.c -rw-r--r-- 1 rr profs 397 Feb convertir.c -rw-r--r-- 1 rr profs 235 Feb convertir.h -rw-r--r-- 1 rr profs 672 Feb outils.c -rw-r--r-- 1 rr profs 234 Feb outils.h Etudiez le fichier Makefile.1 et essayez de construire l application à l aide de make. 1.conversion/Makefile.1 : convert2sens.o : convert2sens.c convertir.o : convertir.c outils.o : outils.c convertir: convertir.o outils.o convert2sens.o -f Makefile.1 convertir

2 Séance de TP n 02 Make et autres outils pour la construction 2 Que faudrait-il faire pour que, par défaut, l application soit construite sans donner son nom de cible. Faites le dans un fichier Makefile.2. Il faut que la cible principale soit la première du Makefile. Cela s obtient, soit en déplaçant la cible principale en première position, soit en mettant en première position une cible bidon (phony) all qui dépend de la cible principale, qui peut alors rester à sa position. C est cette solution que nous retenons, car c est la plus usuelle. De plus, si lors d un appel à make sans préciser de cible explicite, il y a plusieurs cibles à construire, il suffira d ajouter d autre dépendances à la cible all. 1.conversion/Makefile.2 : # Cibles bidon qui ne doivent construire aucun fichier # Zone où typiquement seront placées des déclarations de variables et de règles # (voir plus tard) # Cible principale par défaut all: convertir # compilation séparée convert2sens.o : convert2sens.c convertir.o : convertir.c outils.o : outils.c convertir: convertir.o outils.o convert2sens.o Que faudrait-il faire pour que tout se construise simplement en tapant make et sans renommer ou recopier Makefile.2? Faites le! Il faut que le fichier Makefile.2 s appelle Makefile ou makefile. Il vaut mieux l appeler Makefile, car par ordre alphabétique, il apparaitra avant les fichiers de programmes, dont le nom commence généralement par une minuscule, et il se repérera donc mieux, comme les fichiers README ou ALIRE. Si l on a plusieurs Makefile dans le même répertoire, une solution sans renommer Makefile.2 est d utiliser un lien symbolique : ln s Makefile.2 Makefile. Ajoutez des commentaires au Makefile (vous le ferez systématiquement à partir de maintenant), par exemple pour expliquer les dépendances de compilation séparée et la reliure finale. Voir le fichier Makefile.2 précédent qui a les commentaires demandés Gestion des fichiers d en-têtes Modifiez le fichier convertir.h pour que le taux passe a Relancez make. Que se passe-t-il? Quel devrait être le comportement normal? 1.conversion/convertir.h : // convertir.h // taux de conversion #define TAUX

3 Séance de TP n 02 Make et autres outils pour la construction 3 // type de conversion #define EURO 0 #define FRANC 1 // prototypes des routines de convertir.c void franc_euro(double franc); void euro_franc(double euro) ; make: Nothing to be done for all. Une modification du taux aurait dû entraîner une recompilation des modules qui en dépendent et une reliure des modules pour produire un nouvel exécutable. Pour corriger ce défaut il faut s assurer que la reconstruction se fera bien. cela peut être obtenu en indiquant que tous les modules sources dépendent du fichier convertir.h. Mais dans ce cas, on recompilerait des modules qui ne dépendent pas de ce fichier, ce qui ferait perdre du temps. Pour un petit programme, ce n est pas grave, mais il existe des programmes avec des milliers de modules dont la compilation nécessite des heures, comme la reconstruction d un système Linux, par exemple. Il faut donc limiter les dépendances au strict nécessaire, en examinant le code ou en utilisant un outil comme makedepend. Créez un Makefile.3 qui gère correctement les.h (recherchez les dépendances dans les fichiers sources). Pour tester, votre Makefile, modifiez la date des divers fichiers.h (avec la commande touch ), puis relancez make pour observer si seuls les fichiers dépendants du.h modifié ont été recompilés. Pour déterminer les dépendances de chaque fichier.h, le plus simple, sans utiliser makedepend, est d utiliser une commande grep : ~> for f in.h > do grep $f.c > done convert2sens.c: #include "convertir.h" convertir.c: #include "convertir.h" convert2sens.c: #include "outils.h" outils.c: #include "outils. h" On modifie alors le Makefile en rajoutant ces dépendances. En toute rigueur, il faudrait exprimer que convert2sens.c dépend de convertir.h et de même pour les autres dépendances. Ainsi, chaque fois que convertir.h serait révisé, convert2sens.c le serait aussi. Oui, mais cela nécessiterait un outil pour réactualiser automatiquement le fichier convert2sens.c. En l absence d un tel outil, c est le programmeur et Emacs qui peuvent faire ce travail, et le programmeur n apprécierait pas d être appelé sur son portable par make à l occasion d une reconstruction programmée une nuit de Saint Sylvestre. Donc, on simplifie et on espère qu en recompilant simplement convert2sens.c, cela suffira pour réactualiser le module objet convert2sens.o. Le compilateur pourra détecter d éventuelles incohérences (contrôles statiques de types, etc.) et il serait plus prudent, à l occasion d un changement de convertir.h, de relancer un test de non régression, comme nous le verrons plus tard dans ce cours. En résumé, on remplace la dépendance convert2sens.c -> convertir.h par convert2sens.o -> convertir.h et cette fois on dispose d une règle pour produire le module objet. On procède de même pour les autres dépendances. 1.conversion/Makefile.3 : # Cibles bidon qui de doivent construire aucun fichier # Cible principale par défaut all: convertir # compilation séparée avec gestion des.h

4 Séance de TP n 02 Make et autres outils pour la construction 4 convert2sens.o : convert2sens.c convertir.h outils.h convertir.o : convertir.c convertir.h outils.o : outils.c outils.h convertir: convertir.o outils.o convert2sens.o ~> rm -f Makefile; ln -s Makefile.3 Makefile Effectuez le même genre de tests que précédemment (touch, make ), mais exécutez la commande make avec l option qui permet de visualiser ce qu il ferait, sans le faire! ~> touch outils.h make: Nothing to be done for all > touch convertir.c > makegcc convertir.o outils.o convert2sens.o -o convertir... On constate que les compilations et reliures qui sont faites sont bien strictement nécessaires. Pour faire un test sans faire le travail effectif, il suffit d ajouter l option -n à la commande make. Cela fait gagner du temps, mais il faut alors mettre à jour aussi les dates des cibles pour les réactualiser. L option -t de la commande make le fait automatiquement. -n make: Nothing to be done for all -nt touch convertir.o touch convert2sens.o touch convertir -nt make: Nothing to be done for all Faire le ménage Ajoutez une cible clean qui efface tous les fichiers inutiles /bin/rm.o.bak ~ core. /bin/rm.o core ~.bak Que se passe-t-il si vous lancez deux fois de suite la commande "make clean". Rendez moi cette cible robuste! La deuxième fois, il n y a rien à effacer et la commande rm transmet un code de retour d échec qui est interprété par la commande make et fait stopper make. Il faut donc dire à make d ignorer l échec en mettant le signe - devant la définition de l action. Pour effacer sans demande de confirmation au cas où il y aurait des protections, il faut aussi utiliser l option -f dans la commande rm.

5 Séance de TP n 02 Make et autres outils pour la construction 5 -/bin/rm -f.o core ~.bak Ajoutez à ce Makefile une règle qui, en plus d éliminer les fichiers qui ne vous intéressent pas, élimine aussi l exécutable. Utilisez la règle précédente pour créer cette nouvelle cible veryclean..phony: clean veryclean -/bin/rm -f.o core ~.bak very clean -/bin/rm -f convertir En mettant la dépendance clean à la cible veryclean, tout appel à veryclean sera automatiquement précédé d un appel à clean. La directive.phony permet en plus de préciser que les cibles de nettoyage ne doivent produire aucun fichier du même nom (cibles bidon). 2. Création d un nouveau Makefile Rien ne se perd, tout se transforme... La plupart du temps, on crée un nouveau Makefile en récupérant et en adaptant un précédent. Mais attention, lorsqu on récupère de l existant, il faut rester vigilant et l adapter comme il convient ; et ne jamais récupérer par copie des textes logiquement liés qui doivent évoluer en même temps : le copié-collé c est l enfer de l évolution... [Jérôme Sarvonarole, 1492]. Créez un répertoire 2.pacman pour la suite de ce TP. Récupérez l archive leretourdepacman.tgz et décompactez la. Nous allons maintenant construire, progressivement, le Makefile idéal pour ce programme... Recopiez la meilleure version de votre Makefile pour la conversion et adaptez la pour pacman. 2.pacman/Makefile.1 : all: pacman # compilation séparée avec gestion des.h graphics.o : graphics.c graphics.h gcc -c graphics.c shape.o : shape.c shape.h graphics.h gcc -c shape.c main.o : main.c graphics.h shape.h gcc -c main.c pacman: graphics.o main.o shape.o gcc -L/usr/X11R6/lib -lx11 graphics.o main.o shape.o -o pacman.phony: clean veryclean -/bin/rm -f *.o core *~ *.bak very clean -/bin/rm -f pacman

6 Séance de TP n 02 Make et autres outils pour la construction 6 Si vous ne faites que changer les cibles, les.c et les.h, cela fonctionne-t-il? Pourquoi? Ajoutez les bibliothèques manquantes et retestez. Le compilateur ne trouve pas les fichiers d entête, il faut lui dire où ils se trouvent : /usr/x11r6/include et le relieur ne trouve pas la bibliothèque graphique. Pour ce dernier il faut préciser quelle bibliothèque utiliser (-lx11) et où elle se trouve ( /usr/x11r6/lib ). D un système à l autre ces emplacements peuvent différer. 2.pacman/Makefile.2 : all: pacman pacman: graphics.o main.o shape.o gcc -L/usr/X11R6/lib -lx11 graphics.o main.o shape.o -o pacman # compilation séparée avec gestion des.h graphics.o : graphics.c graphics.h gcc -I/usr/X11R6/ i n c l u d e -c graphics.c shape.o : shape.c shape.h graphics.h gcc -I/usr/X11R6/ i n c l u d e -c shape.c main.o : main.c graphics.h shape.h gcc -I/usr/X11R6/ i n c l u d e -c main.c.phony: clean veryclean -/bin/rm -f *.o core *~ *.bak very clean -/bin/rm -f pacman En fait, pour faire les choses bien, il faudrait aussi référencer les include graphiques dans les cibles gcc c... Pourquoi cela fonctionne-t-il quand même? Rajoutez tout de même le -I qui référence les include. Les fichiers de bibliothèque et d entêtes sont très stables et n évoluent pas, sauf en cas d installation d une nouvelle version du système. Et même dans ce cas, les nouvelles versions de bibliothèque sont normalement compatibles avec les anciennes (compatibilité ascendante). Donc, il est inutile d expliciter dans les Makefiles ces dépendances qui ne serviraient que pour reconstruire le programme en cas de changement des bibliothèques. Testez bien que les dépendances (.c/.h ) sont correctement gérées à coup de "touch". Ajoutez une cible install qui déplace l exécutable créé dans votre répertoire bin. # installation install: pacman -/bin/mv -f pacman $(HOME)/bin Avec l option -f, on force le déplacement, même si le fichier s y trouve déjà. Cela permet de refaire plusieurs installations. C est dangereux si l on ne s est pas assuré au préalable qu il n y avait pas déjà un tel fichier précieux d installé. La notation /bin ne marche pas ou n est pas portable. En effet, les commandes shells exécutées par make le sont normalement pas le shell historique sh qui ne connait pas la notation avec. Au

7 Séance de TP n 02 Make et autres outils pour la construction 7 contraire, la notation $(HOME) utilise une variable d environnement exportée (cf plus loin) qui est standard pour tous les shells. Débrouillez vous pour que, par défaut, le Makefile construise et installe pacman! install all: install # installation install: pacman -/bin/mv pacman $(HOME)/bin 3. Manipulation des variables d environnement Créez un Makefile dont la cible par défaut affiche la valeur des variables SHELL, OSTYPE et USER. Cette cible sera de type PHONY. # affichage de variables.phony: showvar showvar: -@echo "SHELL=<$(SHELL)> OSTYPE=<$(OSTYPE)> USER=<$(USER)>" Regardez l effet produit en fonction du caractère d exportation de ces variables (comparer le résultat de set et export dans votre shell). -f Makefile.var1 SHELL=</bin/sh.exe> OSTYPE=<> USER=<rr> ~> set egrep ^USER= ^OSTYPE= ^SHELL= OSTYPE=cygwin SHELL=bash USER=rr ~> export egrep USER= SHELL= OSTYPE= declare -x SHELL="bash" declare -x USER="rr" On voit donc que ces trois variables sont déclarées dans le shell courant, mais seules les variables USER et SHELL sont exportées. Il n y a donc que ces variables qui sont transmises à la commande make, ce qui explique l affichage partiel des valeurs de ces variables. Modifiez ces valeurs en appelant le Makefile (par exemple make USER=pipo). -f Makefile.var1 USER=pipo SHELL=</bin/sh.exe> OSTYPE=<> USER=<pipo> Regardez l effet produit, à l exécution de make, puis dans le Shell qui a lancé make. ~> echo "SHELL=<$SHELL> OSTYPE=<$OSTYPE> USER=<$USER>" SHELL=<bash> OSTYPE=<cygwin> USER=<rr> Qu en déduisez-vous? On en déduit que la commande make peut affecter les variables d environnement exportées dans la mémoire de son processus, mais pas dans la mémoire du processus appelant, le SHELL courant. Ceci est la conséquence du mécanisme d exportation des variables par les Shells UNIX et n est pas spécifique de la commande make.