Zeph Le 04/10/2015 à 18:31 Ah non, il n'y a pas de magie, Make n'a aucune idée du fait que tu utilises Constants.h dans main.c. En revanche, GCC le sait et il peut te générer les dépendances au format Makefile grâce aux switchs -M & co (il y en a plusieurs). Du coup l'idée c'est de générer ces dépendances dans un fichier à côté et de l'inclure dans ton Makefile principal.

All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez
par ici :)
Ok merci. Ca ne m'empêche pas de (tenter de) définir les règles qui me feront ça automatiquement, si ?
Zeph Le 04/10/2015 à 20:30 Du tout non. Pour info je crois que j'avais posé une question similaire sur yAronet mais comme je ne suis pas 0² je ne sais plus où il est, alors voilà en résumé quel était mon problème :
Une des façons de procéder pour cette histoire de dépendance est de générer, pour chaque fichier source (.c / .cpp), un fichier qui contienne les dépendances de ce fichier. Pour info ça n'est pas la seule façon de faire, on pourrait aussi tout centraliser dans un gros fichier "dépendances", mais je préférais faire comme ça. Mon souci était que je ne voulais pas avoir un fichier de dépendance qui soit créé à côté de chaque fichier source (par exemple toto.d pour toto.c), donc je voulais les mettre dans un sous-dossier à part. Ça impliquait de créer ce sous-dossier et d'y recréer toute la hiérarchie de mes .c / .cpp, ce qui est facile à faire sous Unix avec "mkdir -p" mais moins sous Windows qui ne propose pas de commande équivalente, du coup il faut ajouter un peu de code. Bref, passons cette dernière contrainte, voilà où j'en étais arrivé à part cette dernière étape qui rend les choses plus compliquées et dont tu n'as peut-être pas besoin. J'ai viré toutes les règles inutiles ici et ajouté quelques commentaires, en espérant que ce soit compréhensible :# Une dépendance existe pour chaque fichier source, et se trouve dans un sous-dossier
#obj/ (variable $(OBJ)) par rapport à mes sources qui sont dans src/ (variable $(SRC))
DEPENDENCIES = $(addprefix $(OBJ)/,$(patsubst %.c,%.d,$(SOURCES)))
# Idem pour les fichiers objet
OBJECTS = $(addprefix $(OBJ)/,$(patsubst %.c,%.o,$(SOURCES)))
# Construire l'exécutable à partir des fichiers objet
$(TARGET): $(OBJECTS)
$(LD) -o "$@" $(OBJECTS) $(LDFLAGS)
# On importe toutes les règles de dépendance générées, ce qui permet de provoquer la
# recompilation d'un .c en .o dès que l'une de ses dépendances a été touchée
-include $(DEPENDENCIES)
# Pour générer un fichier de dépendance à partir d'un fichier source, on crée son dossier
# parent puis on utilise GCC
$(OBJ)/%.d: $(SRC)/%.c
mkdir -p "${@D}"
$(CC) $(CFLAGS) -MM -MP -MF "$@" -MT "$(@:.d=.o)" "$<"
# Ensuite, pour générer un fichier objet à partir d'un fichier source et de ses
# dépendances, re-GCC (cette fois le dossier existe déjà)
$(OBJ)/%.o: $(SRC)/%.c $(OBJ)/%.d
$(CC) $(CFLAGS) -c "$<" -o "$@"
Note : j'utilise quelques transformations qui n'existent peut-être que dans gnumake mais pas dans make, à vérifier.

All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez
par ici :)
Non, cf. l'explication dans l'autre topic, le wrapper tigcc n'est pas au courant de ces flags et donc ne fait pas la bonne chose. Ce n'est pas vraiment conseillé, mais si tu invoques le GCC de TIGCC/GCC4TI directement (seulement pour cette étape-là), ça devrait marcher. (Le problème étant que GCC4TI a changé le nom de l'exécutable, donc si tu veux quelque chose qui soit compatible autant avec le vrai TIGCC qu'avec GCC4TI, tu auras un problème. Normalement, c'est $TIGCC/bin/gcc, mais GCC4TI a mis un préfixe (préfixe qui utilise abusivement le nom "tigcc", d'ailleurs; l'excuse de la compatibilité n'est pas valable dans ce cas parce que TIGCC n'utilise pas, n'a jamais utilisé et n'utilisera probablement jamais ce préfixe), totalement inutile parce que le binaire est dans un dossier privé hors PATH.)