Discussion :

[vinzzzz]

Hello.
En reprennant le code du tutoriel makefile du site, je souhaiterai avoir quelques précisions.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
 
hello: hello.o main.o
	gcc -o hello hello.o main.o
 
hello.o: hello.c
	gcc -o hello.o -c hello.c -Wall -ansi
 
main.o: main.c hello.h
	gcc -o main.o -c main.c -Wall -ansi

Je souhaiterai avoir des précisions: lorsqu'on défini une règle pour un .o, on lui dit que celui-ci dépend du fichier source correspondant, et également d'autres fichiers.h (ici par exemple main dépent de hello.h)
Mais on n'a crée aucune règle pour les .h, que fait le makefile avec les .h qu'on lui décrit en dépendance? De plus, main.o ne dépent-il pas également de hello.c? Ou alors peut on remplacer la dépendance hello.h par hello.c ?
De plus, lorsqu'on dit que main.c dépent de main.o, ne dépent-il pas aussi de main.h? Idem pour hello.o. Faut-il alors préciser également le header correspondant a chaque fois (ca semble ne pas être tout le temps le cas)?

Merci d'avance de vos précisions.

[gl]

Je souhaiterai avoir des précisions: lorsqu'on défini une règle pour un .o, on lui dit que celui-ci dépend du fichier source correspondant, et également d'autres fichiers.h (ici par exemple main dépent de hello.h)
Mais on n'a crée aucune règle pour les .h, que fait le makefile avec les .h qu'on lui décrit en dépendance?

Les .h, tout comme les .c (qui n'ont pas eux non plus de regles), sont des noms de fichier, il regarde la date de modification de ces fichiers et celui de la cible et, si necessaire, reconstruit la cible.

De plus, main.o ne dépent-il pas également de hello.c?

Non, on peut construire main.o (et donc compiler main.c) sans se soucier de hello.c. La complation n'a besoin que du fichier source correspondant (main.c ici) et des fichiers d'en-tete inclus.
Par contre, les modifications d'un fichiers sources doit provoquer la regeneration de hello (qui est l'executable final), d'ou la dependance de hello a main.o et hello.o (si un des .c est modifie, le .o correspondant est regenere, et donc hello est reconstruit).

Ou alors peut on remplacer la dépendance hello.h par hello.c ?

hello.h etant inclus dans main.c, la dependance est necessaire.
Si le code des fonctions contenus dans hello.c est modifie, ceci n'a pas d'impact sur la compilation de main.c, il n'est donc pas necessaire de reconstruire main.o. Si des donnees utilisees par d'autres modules (prototype des fonctions, formats des structures, define, etc.) changent, hello.h est modifie, main.o est donc reconstruit.

De plus, lorsqu'on dit que main.c dépent de main.o,

main.c ne depend pas de main.o, c'est main.o qui depends de main.c

ne dépent-il pas aussi de main.h?

eventuellement, ca depend de leur contenu.

Idem pour hello.o. Faut-il alors préciser également le header correspondant a chaque fois (ca semble ne pas être tout le temps le cas)?

Dans l'exemple fournit dans le tutoriel, hello.h ne contient que le prototype de Hello, ainsi une modification de hello.h est forcement effectue en meme temps qu'une modification que hello.c, ce n'est donc pas genant.
Par contre si le .h contient des formats de structures, des define ou d'autres choses pouvant entrainer la modification du .h sans modifier le .c il devient necessaire de rajouter le .h dans les dependances.
Toutefois, meme dans le cas ou ce n'est pas necessaire (cas de l'exemple), il est possible de le mettre et ca ne peut que simplifier les evolutions et corrections futures.

[vinzzzz]

Tout d'abord merci beaucoup de ta réponse complète.

Les .h, tout comme les .c (qui n'ont pas eux non plus de regles), sont des noms de fichier, il regarde la date de modification de ces fichiers et celui de la cible et, si necessaire, reconstruit la cible.

Ca veu dire que lorsque le .h à été modifié récement, il va aller reconstruire le .o correspondant au .h pour pouvoir ensuite reconstruire la cible? (d'ou la necessité, si ce n'est de la logique, d'avoir les .h ayant le mm nom que les .c?) On ne pourrait donc pa remplacer un .h en dépendance par un .o du même nom ca n'a pas de sens? (j'avais cru voir ce genre de chose dans certains exemple sur le net...)

Donc en résumé, dans une dépendance il est necessaire de mettre le .c correspondant au .o, et éventuellement le .h mais il est possible de l'omettre.
De plus lorsqu'un .o dépend d'autres modules, on utilise le .h comme ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
main.o: main.c hello.h
    gcc -o main.o -c main.c -Wall -ansi

Là lorsque make voit la dépendance a hello.h, il va vérifier les date de dernière modif de celui-ci et si necessaire va reconstruire hello.o et hello, mais pas main.o.
Corrigez moi si je me trompe svp. Sinon merci beaucoup a gl .

[gl]

Ca veu dire que lorsque le .h à été modifié récement, il va aller reconstruire le .o correspondant au .h pour pouvoir ensuite reconstruire la cible?

Non, si seul le .h a ete modifie depuis la derniere generation, le programme va reconstruire les .o dont les dependances contient ce .h, puis tout ce qui depends des .o nouvellement generes et ainsi de suite.

(d'ou la necessité, si ce n'est de la logique, d'avoir les .h ayant le mm nom que les .c?)

Non il n'y a aucune necessite de le faire. Il est possible de mettre le prototype d'une fonction dans toto.h et son implementation dans titi.c, tout comme il est tout a fait possible (c'est d'ailleurs tres frequemment le cas, notament sur les interfaces publiques de modules) de regrouper dans un seul .h les prototypes de plusieurs fonctions implemente dans plusieurs .c differents.

On ne pourrait donc pa remplacer un .h en dépendance par un .o du même nom ca n'a pas de sens? (j'avais cru voir ce genre de chose dans certains exemple sur le net...)

Je ne comprends pas vraiment ce que tu veux dire, peux-tu detailler un peu ?

Donc en résumé, dans une dépendance il est necessaire de mettre le .c correspondant au .o, et éventuellement le .h mais il est possible de l'omettre.

Dans les dependances d'un .o il faut mettre tout les fichiers dont une modification necessite une regeneration, c'est a dire le fichier .c correspondant et generalement les fichiers .h inclus.
Le fait d'omettre un .h ou non, ne vient pas du nom du .h ou du fait que ce .h contient des prototypes de fonctions implementees dans le .c mais de l'incidence de ce .h sur la compilation. Si une modification d'un .h peut entrainer un fichier objet different sans que le .c correspondant ne soit modifie, il faut mettre ce .h, sinon il est possible de l'omettre. Mais dans le doute, et pour simplifier les evolutions, autant mettre dans les dependances tout les .h du projet inclus dans ce fichier.

De plus lorsqu'un .o dépend d'autres modules, on utilise le .h comme ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
main.o: main.c hello.h
    gcc -o main.o -c main.c -Wall -ansi

Là lorsque make voit la dépendance a hello.h, il va vérifier les date de dernière modif de celui-ci et si necessaire va reconstruire hello.o et hello, mais pas main.o.

Non, il va reconstruire main.o (puisque hello.h est une dependance de main.o) et hello (puisque main.o est une dependance de hello) mais pas hello.o si seulement hello.h a ete modifie (car hello.h n'est pas une dependance de hello.o.

Je te conseille, si tu veux voir comment s'enchaine les passages dans les regles pour comprendre le fonctionnement de make, de regarder l'enchainement des appels (les lignes de commandes execute par le Makefile apparaissent dans ta console) en "modifiant" un des fichiers et en relancant make

[vinzzzz]

Ok merci encore de ton aide c'est déja bien plus clair dans ma tête, les dépendances qui st modifié récement vont impliquier la régénération des .o dépendant de ces fichers et ainsi de suite...
Je vais suivre ton conseil et regarder l'enchainement de tout ca histoire d'être bien convaincu.

vinzzzz a écrit :
On ne pourrait donc pa remplacer un .h en dépendance par un .o du même nom ca n'a pas de sens? (j'avais cru voir ce genre de chose dans certains exemple sur le net...)

Je ne comprends pas vraiment ce que tu veux dire, peux-tu detailler un peu ?

J'avais vu ce genre de chose:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
main.o: main.c hello.o a.o b.o etc...

Ce qui n'est pas correct il me semble. Je pense que c'est ma mémoire qui doit être défaillante...

Non il n'y a aucune necessite de le faire. Il est possible de mettre le prototype d'une fonction dans toto.h et son implementation dans titi.c, tout comme il est tout a fait possible (c'est d'ailleurs tres frequemment le cas, notament sur les interfaces publiques de modules) de regrouper dans un seul .h les prototypes de plusieurs fonctions implemente dans plusieurs .c differents.

C'est bon a savoir... mais c'est pas un truc que je ferais intuitivement .

[gl]

J'avais vu ce genre de chose:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
main.o: main.c hello.o a.o b.o etc...

Ce qui n'est pas correct il me semble. Je pense que c'est ma mémoire qui doit être défaillante...

Dire que ce n'est pas correct, c'est un peu exagere, c'est licite bien que surprennant. Ca permet de reforcer la generation de main.o si un autre des .o a ete modifie (et donc regenrer). Ca n'est generalement pas utile. Maintenant il faut voir dans le contexte, il y a peut etre une raison particuliere pour effectuer ce genre de manipulation.

[vinzzzz]

Ok merci a toi pour toutes ces précisions!