Discussion :

[zephyre]

Bonjour,

A la suite de la lecture sur le cours makefile,
https://gl.developpez.com/tutoriel/outil/makefile/
j'ai plusieurs questions :
La première :
Je ne comprends pas pourquoi dans vos exemples avec vos 2 fichiers sources :
- main.c
- hello.c
Et le fichier d'en tête (header) :
- hello.h

Vous n'incluez pas le fichier header hello.h à la fois dans le main.c et dans hello.c.
Vous ne l'incluez que dans le fichier main.c

Moi j'ai lu dans un livre qu'il fallait impérativement l'inclure dans les 2 fichiers car
le compilateur traite chaque fichier indépendamment les uns des autres.
Et que donc pour faire un contrôle du prototype de la fonction au moment de l'appel dans
main.c. il faut que le fichier header soit doublement inclut (main.c + hello.c)
Sinon ça sert à rien.
Es ce que je raconte des conneries ?

Deuxième question :
Je ne comprends pas cette phrase :

II-B Makefile enrichi
Un tel Makefile ne permet pas de générer plusieurs exécutables distincs.

Mais y a qu’un et un seul exécutable ?
Le reste sont des fichiers objets venant eux mêmes des fichiers sources.
Vu que y a qu'une seule fonction main.

Troisième question :

III-B. Variables internes :
$? <=> la liste des dépendances plus récentes que la cible

Je ne comprends pas cette phrase.
La liste des dépendances est donnés dans le makefile, par exemple :

Code makefile :

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

1
2
3
4
5
===============
hello: main.o afficher.o
	gcc -o hello main.o afficher.o
...
===============

Quatrième question :

III-B. Variables internes :
$* <=> nom du fichier sans suffixe

Mais de quel fichier il s'agit ? Le fichier CIBLE ?

On a la liste des dépendances pour l'exécutable hello et également pour touts les autres
fichiers.o intermédiaire ?
Donc je comprends pas le mot "plus récent"

Cinquième question :

IX. Les Makefiles conditionnels :
compiler notre projet tantôt en mode debug, tantôt en mode release

Es ce que quelqu'un peut m'expliquer la différence entre le mode debug et le mode release ?
Je comprends rien à cette phrase.

Sixième question :

X. sous-makefile :
Le makefile maitre est situé dans le répertoire principale
Le sous-make est situé dans le répertoire hello (qui est un sous répertoire du répertoire principale)

Code Makefile maitre :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
=================
export CC=gcc
export CFLAGS=-W -Wall -ansi -pedantic
export LDFLAGS=
HELLO_DIR=hello
EXEC=$(HELLO_DIR)/hello
 
all: $(EXEC)
 
$(EXEC):
    @(cd $(HELLO_DIR) && $(MAKE))
 
.PHONY: clean mrproper $(EXEC)
 
clean:
    @(cd $(HELLO_DIR) && $(MAKE) $@)
 
mrproper: clean
    @(cd $(HELLO_DIR) && $(MAKE) $@)
=================

Supposons que j'ai un répertoire master que je nomme MASTER.
Dans ce répertoire il y a un makefile master.
Ce makefile master appelle 3 autres sous makefile.
Chacun de ses makefile est dans un sous un répertoire (juste un et un seul niveau en dessous).
Dans ce cas il faudra que je fasse dans le makefile maitre :

Code Makefile maitre :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
=================
export CC=gcc
export CFLAGS=-W -Wall -ansi -pedantic
export LDFLAGS=
 
HELLO_DIR=hello       # Premier   sous répertoire du makefile fils
AUREVOIR_DIR=aurevoir # Deuxieme  sous répertoire du makefile fils
BONJOUR_DIR=bonjour   # Troisième sous répertoire du makefile fils
 
EXEC_HELLO=$(HELLO_DIR)/hello
EXEC_AUREVOIR=$(AUREVOIR_DIR)/aurevoir
EXEC_BONOUR=$(BONJOUR_DIR)/bonjour
 
all: $(EXEC_HELLO) $(EXEC_AUREVOIR) $(EXEC_BONJOUR)
 
$(EXEC_HELLO):
    @(cd $(HELLO_DIR) && $(MAKE))
 
$(EXEC_AUREVOIR):
    @(cd $(AUREVOIR_DIR) && $(MAKE))
 
$(EXEC_BONJOUR):
    @(cd $(BONJOUR_DIR) && $(MAKE))
 
.PHONY: clean mrproper $(EXEC)
 
clean:
    @(cd $(HELLO_DIR) && $(MAKE) $@)
 
mrproper: clean
    @(cd $(HELLO_DIR) && $(MAKE) $@)
=================

Pouvez vous me le confirmer ?

[Sve@r]

Bonjour

Je ne comprends pas pourquoi dans vos exemple avec vos 2 fichiers sources :
- main.c
- hello.c
Et le fichier d'en tête (header) :
- hello.h

Vous n'incluez pas le fichier header hello.h à la fois dans le main.c et dans hello.c.
Vous ne l'incluez que dans le fichier main.c

Le source "hello.c" n'a pas besoin de ce qui se trouve dans "hello.h". Que contient hello.h? Le prototype de la fonction "hello" qui se trouve dans hello.c. Et qui a besoin de ce prototype? Tous ceux qui utiliseront la fonction "hello" mais certainement pas "hello.c" qui définit la fonction "hello" et donc qui la connait fatalement.

Après effectivement on peut avoir des cas où "hello.h" contiendrait un truc (un #define, un #include) qui serait à la fois nécessaire à "hello.c" et à "main.c" et dans ce cas, l'inclure dans les deux sources sera nécessaire. On pourrait même l'inclure maintenant même si c'est inutile, juste "au cas où" mais bon, l'auteur ne l'a pas fait.

Moi j'ai lu dans un livre qu'il fallait impérativement l'inclure dans les 2 fichiers car
le compilateur traite chaque fichier indépendamment les uns des autres.
Et que donc pour faire un contrôle du prototype de la fonction au moment de l'appel dans
main.c. il faut que le fichier header soit doublement inclut (main.c + hello.c)
Sinon ça sert à rien.
Es ce que je raconte des conneries ?

Je ne dirais pas que tu racontes des conneries mais que tu n'as pas bien pigé la chaine de compilation.
Oui le compilateur traite chaque fichier indépendamment. Oui il va compiler "hello.c" de façon indépendante, puis "main.c". Et oui il fait un contrôle au moment de l'appel de la fonction hello() dans main.c donc oui, dans main.c l'include est nécessaire.
Mais en quoi hello.c aurait besoin de hello.h? Même si la fonction hello() s'appelait elle-même (récursivité), le prototype est enregistré lors de la définition de la fonction et donc le contrôle peut quand-même se faire.
Le seul argument pour lequel on peut préconiser l'inclusion de hello.h dans hello.c c'est que cela permettrait au compilateur de vérifier que la fonction est définie correctement, à l'identique de sa déclaration. C'est pas une mauvaise idée, mais ça reste facultatif.

Deuxième question :
Je ne comprends pas cette phrase :
II-B Makefile enrichi
Un tel Makefile ne permet pas de générer plusieurs exécutables distincs.
Mais y a qu’un et un seul exécutable ?

Effectivement l'exemple donné ne le montre pas. Mais il est tout à fait possible de créer des Makefile enrichis (ou génériques) disant "tout .c sera compilé de telle façon pour donner un exécutable associé". Cela se fait via les variables "$<", "$*", "$@" et autres.

Troisième question :
III-B. Variables internes :
$? <=> la liste des dépendances plus récentes que la cible
Je ne comprends pas cette phrase.
La liste des dépendances est donnés dans le makefile, par exemple :
makefile:
===============
hello: main.o afficher.o
gcc -o hello main.o afficher.o
...
===============

Le principe du makefile est de s'appuyer sur les dates de mises à jour entre "cible" et "dépendance". On peut donc avoir des dépendances plus ou moins récentes que la cible.
Dans ton exemple, "hello" dépent de "main.o" et "afficher.o". Imagine que tu modifies juste "main.c" et que tu regénères "main.o" dans la foulée, tu te retrouves alors avec un fichier "main.o" plus récent que l'exécutable "hello".

Quatrième question :
III-B. Variables internes :
$* <=> nom du fichier sans suffixe
Mais de quel fichier il s'agit ? Le fichier CIBLE ?

Non, la dépendance. Si la dépendance c'est "hello.c", le nom sans son suffixe c'est "hello".

On a la liste des dépendances pour l'exécutable hello et également pour touts les autres
fichiers.o intermédiaire ?
Donc je comprends pas le mot "plus récent"

Cela fait référence à la date de création du fichier dans la machine.

Cinquième question :
IX. Les Makefiles conditionnels :
compiler notre projet tantôt en mode debug, tantôt en mode release
Es ce que quelqu'un peut m'expliquer la différence entre le mode debug et le mode release ?

Un mode "debug" serait un mode avec plein de printf() pour afficher tout ce qui se passe. En mode "release" (signifiant "déploiement chez le client") tous les printf() sautent.

Sixième question :
Supposons que j'ai un répertoire master que je nomme MASTER.
Dans ce répertoire il y a un makefile master.
Ce makefile master appelle 3 autres sous makfile.
Chacun de ses makefile est dans un sous un répertoire (juste un et un seul niveau en dessous).
Dans ce cas il faudra que je fasse dans le makefile maitre :

Makefile maitre :
=================
export CC=gcc
export CFLAGS=-W -Wall -ansi -pedantic
export LDFLAGS=

HELLO_DIR=hello # Premier sous répertoire du makefile fils
AUREVOIR_DIR=aurevoir # Deuxieme sous répertoire du makefile fils
BONJOUR_DIR=bonjour # Troisième sous répertoire du makefile fils

EXEC_HELLO=$(HELLO_DIR)/hello
EXEC_AUREVOIR=$(AUREVOIR_DIR)/aurevoir
EXEC_BONOUR=$(BONJOUR_DIR)/bonjour

all: $(EXEC_HELLO) $(EXEC_AUREVOIR) $(EXEC_BONJOUR)

$(EXEC_HELLO):
@(cd $(HELLO_DIR) && $(MAKE))

$(EXEC_AUREVOIR):
@(cd $(AUREVOIR_DIR) && $(MAKE))

$(EXEC_BONJOUR):
@(cd $(BONJOUR_DIR) && $(MAKE))

.PHONY: clean mrproper $(EXEC)

clean:
@(cd $(HELLO_DIR) && $(MAKE) $@)

mrproper: clean
@(cd $(HELLO_DIR) && $(MAKE) $@)
=================

Pouvez vous me le confirmer ?

Non. Dans le cadre d'un projet découpé, tu n'as qu'un seul(*) exécutable. Tu ne peux pas avoir un "exec_bonjour" et un "exec_aurevoir".
Les sous-répertoires sont là pour permettre aux développeurs de se partager les tâches et bien s'y retrouver. Ensuite chaque ".c" de chaque sous-répertoire est compilé en ".o" et tous ces ".o" sont ensuite récupérés dans le seul et unique exécutable du projet.

(*) en fait on peut avoir plusieurs exécutables, style un exécutable pour ouvrir un truc, un autre pour travailler et un troisième pour fermer le truc, mais ces trois exec sont tous au niveau de la racine du projet. Les sous-dossiers, eux, ne contiennent qu'une partie du projet et n'auront pas d'exec, eux.

[Flodelarab]

Bonjour

Moi, il me semble qu'il y a un petit jeu malsain. Généralement, les fichiers d'entêtes *.h définissent des objets. Et les fichiers *.c les implémentent. Ici, le fichier hello.h ne sert strictement à rien. Tellement à rien que le fichier hello.c n'inclut pas hello.h. Donc le makefile n'oblige pas hello.c à dépendre de hello.h. zephyre, ton livre dit qu'il faut inclure les deux car il pré-suppose sûrement que les *.c incluent les *.h. Il faut donc rendre compte de cette dépendance dans le makefile.

[zephyre]

Tout d'abords merci beaucoup pour votre aide.

Ok j'ai tout compris sauf :

- la chaine de compilation n'est pas clair pour moi apparemment, je vais revoir cela.

Le seul argument pour lequel on peut préconiser l'inclusion de hello.h dans hello.c c'est que cela permettrait au compilateur de vérifier que la fonction est définie correctement, à l'identique de sa déclaration. C'est pas une mauvaise idée, mais ça reste facultatif.

C'est justement ce qui est dit dans le livre et c'est vital pour contrôler qu'il n'y a pas d'erreur sur le prototype de la fonction "hello.c".
L'auteur insiste la dessus dans son livre, "Méthodologie de la programmation en langage C".
C'est peu être certes facultatif mais très vivement recommandé, comme les extensions de fichiers sous Linux pour s'y retrouver beaucoup plus facilement.
Dans le cas contraire, c'est à dire, si on ne fait pas la double inclusion du "hello.h" dans le fichier "hello.c" et dans le "main.c", le compilateur est incapable de détecter une erreur
de prototypage au moment de l'appel de la fonction dans le main.

-

Non. Dans le cadre d'un projet découpé, tu n'as qu'un seul(*) exécutable. Tu ne peux pas avoir un "exec_bonjour" et un "exec_aurevoir".
Les sous-répertoires sont là pour permettre aux développeurs de se partager les tâches et bien s'y retrouver. Ensuite chaque ".c" de chaque sous-répertoire est compilé en ".o" et tous ces ".o" sont ensuite récupérés dans le seul et unique exécutable du projet.

Ok donc les sous makefiles (esclaves) ne sert qu'à générer les fichiers .o ?
Dans ce cas comment je fais pour générer le seul exécutable dans mon makefile master, lui même, dans mon répertoire MAITRE, avec les fichiers .o qui sont
dans les sous répertoires ?

[Sve@r]

Ici, le fichier hello.h ne sert strictement à rien.

Ah non il ne sert pas à rien!!! Il sert à déclarer la fonction hello(). Sans lui, en trouvant une fonction hello() non connue, le compilateur mettra un warning à la compilation de main.c (et si on active les options fortes de compilation, il transforme alors le warning en erreur et ça ne compile pas).

Tellement à rien que le fichier hello.c n'inclut pas hello.h.

Ben oui. Comme je l'ai expliqué, dans ce cas précis, ce n'est pas obligatoire. Je ne dis pas que c'est une bonne chose, mais ça reste un fait.

C'est justement ce qui est dit dans le livre et c'est vital pour contrôler qu'il n'y a pas d'erreur sur le prototype de la fonction "hello.c".

C'est effectivement un très bon conseil, presque on peut dire une obligation morale. C'est peut-être l'idée que veut faire ressortir l'auteur.

Ok donc les sous makefiles (esclaves) ne sert qu'à générer les fichiers .o ?

Pas forcément "que" les .o. Tu as par exemple des outils qui peuvent de générer des analyses de code et autres. Rien ne t'interdit d'intégrer ces outils dans les Makefile esclaves. Donc les Makefile esclaves peuvent prendre les .c et selon la demande, peuvent générer des ".o", ".i", ".x", ".y" et autres trucs selon ton bon vouloir. Tout ce que tu as à faire est d'indiquer au Makefile "comment faire un .truc à partir partir d'un .c".
Tu peux aussi regrouper les ".o" des sous-dossiers en librairie (une lib par sous-dossier). Ensuite, à l'édition des liens, au lieu de prendre les ".o" tu prends la librairie.

Dans ce cas comment je fais pour générer le seul exécutable dans mon makefile master, lui même, dans mon répertoire MAITRE, avec les fichiers .o qui sont
dans les sous répertoires ?

Bah ça fait bien longtemps que j'ai pas fait ça mais à vue de nez, en écrivant un truc comme projet: sourceA/xxx.o sourceA/yyy.o sourceB/xxx.o sourceB/yyy.o ça devrait le faire. Rien n'oblige les ".o" à se trouver dans le même dossier que le projet. Donc tu indiques le chemin des ".o".

Tiens, un de mes Makefile pour l'exemple

Code Makefile :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
CC=gcc
CPP=g++
CFLAGS=-Wall -Werror
 
EXEC=score_tennis score_tennis2 score_standard score_standard2
 
all:
	make $(EXEC)
 
clean:
	rm -f $(EXEC) $(EXEC:=.o)
 
.c:
	$(CC) $(CFLAGS) $< -o $@
 
.cpp:
	$(CPP) $(CFLAGS) $< -o $@

Ce que dit ce Makefile

• il y a plusieurs exécutables, listés dans une variable "EXEC"
• la cible "all" demandera la création de tous les exécutables (et comme c'est la première, ce sera celle par défaut)
• la cible "clean" demandera à effacer l'exécutable et les ".o" correspondants
• toute compilation à partir d'un ".c" appelera la commande placée dans la variable "CC"
• toute compilation à partir d'un ".cpp" appelera la commande placée dans la variable "CPP"

Bon c'était pas un gros projet (un seul source par exécutable, certains sources écrits en C et d'autres écrits en C++) mais ça te donne une idée.

[zephyre]

Bonjour Sve@r,

Bah ça fait bien longtemps que j'ai pas fait ça mais à vue de nez, en écrivant un truc comme projet: sourceA/xxx.o sourceA/yyy.o sourceB/xxx.o sourceB/yyy.o ça devrait le faire. Rien n'oblige les ".o" à se trouver dans le même dossier que le projet. Donc tu indiques le chemin des ".o".

Juste une question :
Les chemins en question des .o c'est à partir du répertoire ou il y a le makefile master ?

Ce que dit ce Makefile

il y a plusieurs exécutables, listés dans une variable "EXEC"
la cible "all" demandera la création de tous les exécutables (et comme c'est la première, ce sera celle par défaut)
la cible "clean" demandera à effacer l'exécutable et les ".o" correspondants
toute compilation à partir d'un ".c" appelera la commande placée dans la variable "CC"
toute compilation à partir d'un ".cpp" appelera la commande placée dans la variable "CPP"

Je comprends pas Sve@r.
Dans ton makefile tu as plusieurs EXEC

Et tu m'as dit que au final normalement tu n'as qu'un seul EXEC ici,

Non. Dans le cadre d'un projet découpé, tu n'as qu'un seul(*) exécutable. Tu ne peux pas avoir un "exec_bonjour" et un "exec_aurevoir".
Les sous-répertoires sont là pour permettre aux développeurs de se partager les tâches et bien s'y retrouver. Ensuite chaque ".c" de chaque sous-répertoire est compilé en ".o" et tous ces ".o" sont ensuite récupérés dans le seul et unique exécutable du projet.

Donc y a un et un seul exécutable, ou bien il peut y en avoir plusieurs ?

[Sve@r]

Les chemins en question des .o c'est à partir du répertoire ou il y a le makefile master ?

Oui, puisque tu es présumé te trouver dans ce répertoire quand tu lances make. Le Makefile n'enlève rien aux fondamentaux d'Unix. Quand tu te trouves dans un dossier X et que tu appelles une commande Y, la commande Y part du dossier X pour travailler.

Dans ton makefile tu as plusieurs EXEC

Et tu m'as dit que au final normalement tu n'as qu'un seul EXEC ici,

Donc y a un et un seul exécutable, ou bien il peut y en avoir plusieurs ?

C'est toi qui crée ta structure. Si tu dois travailler sur un gros gros projet, projet qui contient plusieurs sous-dossiers, tu iras naturellement vers un dossier dédié au projet, et dans le dossier tu n'auras qu'un exec.

Mais si tu veux juste t'amuser en C, créer plein de petits programmes divers et indépendants, tu auras alors plein d'exec. Et tu pourras parfaitement créer un Makefile assez universel pour gérer tous ces exec.
Tiens, mon Makefile pour mon dossier de tous mes petits programmes C

Code Makefile :

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

1
2
3
4
5
CC=gcc
CFLAGS=-Wall -Werror
 
.c:
	$(CC) $(CFLAGS) $< -o $@

Ce Makefile signifie "toute demande de création de toto à partir de toto.c se fera via gcc -Wall -Werror toto.c -o toto" (toto étant ici un nom de fichier quelconque).

Tu peux aussi gérer plusieurs projets différents dans un même dossier pourquoi pas, mais là ça devient hard à décrire dans le Makefile. Le fait de dédier un dossier à un projet n'est pas obligatoire mais ça te simplifie grandement la vie. Par exemple avec le Makefile ci-dessus, impossible de créer un programme découpé sur 2 sources. Mais ce dossier dédié aux "petits codes" n'est pas fait pour ça.