un makefile qui ne fait rien - Page 1

Je ne comprends pas pourquoi mon makefile ne produit rien. Il n'y a que le bloc first: qui est exécuté.
L'erreur est certainement dans les règles, mais où

# file to build our project


ROOT         =  $(shell pwd)
SRC          =  $(ROOT)/src
SRCC         =  $(SRC)/c
SRCH         =  $(SRC)/h
BIN          =  $(ROOT)/bin


OUTPUT_BIN   =  commerce1
OBJS         =  make_town_table.o  main.o  


CFALGS       =  -O3 -mcpu=i686
#CFALGS       =  -g -mcpu=i686
LDFLAGS      =  


CC           = gcc
LD           = gcc
RM           = rm




first:
	cd $(BIN)



$(OUTPUT_BIN) : $(OBJS)
	@echo CECI NE S\'AFFICHE JAMAIS
	$(LD) $(LDFLAGS) -o $(OUTPUT_BIN) $(OBJS)


make_town_table.o : $(SRCC)/make_town_table.c $(SRCH)/towns.h $(SRCH)/base_types.h
	@echo CECI NE S\'AFFICHE JAMAIS
	$(CC) $(CFLAGS) -c $< -o $@


main.o : $(SRCC)/main.c $(SRCH)/towns.h $(SRCH)/base_types.h
	@echo CECI NE S\'AFFICHE JAMAIS
	$(CC) $(CFLAGS) -c $< -o $@


clean:
	$(RM) *.o

heu... tu fais "make" et c'est tout ? parceque vu que ta règle "first" n'a aucune dépendance et qu'elle ne provoque qu'un changement de dossier, ça me semble normal que ton fichier n'ait aucun effet ; il faudrait au moins la faire dépendre de "$(OUTPUT_BIN)"

Merci ! J'ai remplacé first: par first : $(BIN)/$(OUTPUT_BIN) et ça donne ça :

make: *** No rule to make target `/home/moi/Documents/etudes/projetcommerce/bin/commerce1', needed by `first'. Stop.

As tu bien fait la différence entre espaces et tabs? Parce que pour make, ce n'est pas du tout la même chose!

[edit] cross, en effet il faut aussi faire gaffe aux différences tab/espace, j'avais oublié ce détail ^^

Dans un makefile, tout fonctionne par règles et par dépendances. Ta deuxième version de la règle "first" dépend de la règle "$(BIN)/$(OUTPUT_BIN)", ce qui signifie que la règle "first" n'est plus à jour si la règle "$(BIN)/$(OUTPUT_BIN)" a une date de modification supérieure à elle. Le problème c'est que tu n'as pas défini de règle "$(BIN)/$(OUTPUT_BIN)", d'où peut-être le message d'erreur.

Il faut, au choix, soit que tu crées une règle "$(BIN)/$(OUTPUT_BIN)" (dont l'exécution provoque la construction de ce fichier, a priori), soit que tu fasses dépendre ta règle first de la règle "$(OUTPUT_BIN)" (qui elle est définie).

Autre chose à vérifier : ça fait longtemps que je n'ai pas touché à un makefile, mais il me semble que chaque règle est exécutée dans un contexte unique, ce qui signifie que ton "cd $(BIN)" n'aura aucun effet tel qu'il est placé.

OK, c'était bien la dépendance $(OUTPUT_BIN) qui manquait

Quelqu'un sait-il changer le répertoire courant pour la totalité du makefile ?

Tu ne peux pas.

2 solutions: soit tu préfixes tous les chemins par $(BIN), soit tu déplaces ton makefile dans $(BIN) et tu fais un makefile global qui appelle récursivement celui dans $(BIN).

C'est crade de mettre des $(SRC) partout devant tous les noms... Pas terrible ce make...

Bah, utilise CMake si tu ne veux pas écrire un makefile directement. Ça a aussi d'autres avantages: on peut détecter des libs sur le système et d'autres propriétés du système (un peu comme autoconf, mais CMake est beaucoup plus simple à utiliser), on a le pourcentage de progression pendant la compilation etc.

la solution la plus logique me semble être la 1ere proposée par Kevin, à savoir placer un second Makefile dans le dossier où tu veux exécuter tes règles

Vous avez toute ma reconnaissance pour vos conseils

Je ne peux pas prendre cmake pour ce projet, mais je me pencherai dessus à l'occasion.

Voilà le makefile amélioré et corrigé, dans l'éventualité où il aiderait quelqu'un qui débute comme moi dans le domaine :

# file to build our project


ROOT         =  .
SRC          =  $(ROOT)/src
HDR          =  $(SRC)/h
O            =  $(ROOT)/o
BIN          =  $(ROOT)


OUTPUT_BIN   =  $(BIN)/commerce1
OBJS         =  $(O)/make_town_table.o  $(O)/main.o  


CFLAGS       =  -O3 -march=i686 -I $(HDR)
#CFLAGS       =  -g -march=i686 -I $(HDR)
LDFLAGS      =  


CC           = gcc
LD           = gcc
RM           = rm




$(OUTPUT_BIN)  :  $(OBJS)
	$(LD) $(LDFLAGS) -o $@ $(OBJS)


$(O)/make_town_table.o  :  $(SRC)/make_town_table.c $(HDR)/towns.h $(HDR)/base_types.h
	$(CC) $(CFLAGS) -c $< -o $@


$(O)/main.o  :  $(SRC)/main.c $(HDR)/towns.h $(HDR)/base_types.h
	$(CC) $(CFLAGS) -c $< -o $@


clean:
	$(RM) $(O)/*.o
	$(RM) $(OUTPUT_BIN)

t'as vraiment aucune idée pour regrouper le deux compilations? Comment tu ferais si ton projet avait 10 fichiers sources?

Quelques suggestions en vrac pour ton Makefile :

- Il existe une syntaxe pour remplacer une sous-chaine par une autre dans le contenu d'une variable, ce qui te permet de changer les extensions ".c" en ".o" et de ne pas avoir à maintenir à jour deux listes quasiment identiques :

SRC = main.c engine.c custom.c
OBJ = $(SRC:.c=.o)

# ici, $OBJ = main.o engine.o custom.o

- Tu peux faire des règles génériques pour éviter d'écrire explicitement que chaque .c donne le .o corespondant. La syntaxe est totalement illogique avec "make" (gmake propose beaucoup mieux), mais elle existe quand même :

SRC = main.c engine.c custom.c
OBJ = $(SRC:.c=.o)

# la règle ci-dessous signifie "chaque .o dépend du .o de même nom",
# $< fait référence à la source (le .c) et $@ à la cible (le .o).

.c.o:
    gcc -W -Wall -o $@ -c $<

- L'idée de faire dépendre tes .o des .h qui sont utilisés pour leur génération est bonne (voire indispensable), mais c'est pénible à faire à la main et source d'erreur. Une solution plus pratique serait de faire dépendre tes .c de leurs .h respectifs, et ça tombe bien, gcc propose justement une option "-M" qui analyse les fichiers source et affiche en syntaxe "make" les règles de dépendance. Tu n'as plus qu'à rediriger la sortie de cette commande dans un fichier (par exemple "Makefile.depends") et l'inclure dans ton Makefile :

BIN = myprog
SRC = main.c engine.c custom.c
OBJ = $(SRC:.c=.o)

all: $(BIN)

# création du fichier "Makefile.dep" contenant les règles de dépendance.

depends:
    gcc -W -Wall -M $(SRC) > Makefile.dep

$(BIN): $(OBJ)

# grâce à cette inclusion (qui ne plantera pas si le fichier n'existe pas, grâce au
# "-" devant), les dépendances seront gérées automatiquement à condition
# d'avoir appelé la règle "depends" avant pour créer "Makefile.dep".

-include Makefile.dep

.c.o:
    gcc -W -Wall o $@ -c $<

Le .c.o, c'est aussi une extension de GNU make et peut-être certains autres make, ce n'est pas disponible partout.

.o:.c aussi?

C'est sympa pour ton petit guide Zephyr. Le script est puissant... à tel point que ce niveau d'automatisation fait perdre à make toute utilité : avec ces quelques lignes n'importe quel projet est compilable !
Y'avait qu'à créer un make complètement automatique, sans script, qui gère tout tout seul

Ah au fait j'ai découvert une option de GCC : -mtune=native. Apporte-t-elle quelque chose ? Je me demande si GCC ne compile pas déjà en -mtune=core2 sur un Core2, -mtune=pentium4 sur un P4, etc.

Par contre, -march=native c'est génial sous Linux. Les binaires devant êre recompilés pour chaque machine, autant les cibler complètement pour l'architecture processeur

Normalement un binaire GNU/Linux est compilé une fois pour toutes par le packageur pour la distribution ciblée, en général avec -mtune=generic.

Je comptais bien sur toi pour répondre, tu connais pas mal GCC. Mais tu ne réponds pas à ma question en fait. Quand on compile sans option sous Linux, mtune=native n'est pas activé par défaut ?

probablement pas , sinon l'option n'existerait pas, ou s'appellerait -mno-tune-native

Non qualyl, l'option -mtune n'est pas un switch on/off, donc l'inverse de -mtune, c'est -mtune .
Quand à la valeur par défaut je pense que c'est toi (= ou ton système) qui la définit, et pour quand tu n'en spécifies aucune, ce qui semble logique c'est le -mtune=generic dont parlait Kevin plus haut, mais ça semble plus dur à vérifier

Ben j'ai l'impression que c'est bien native qui est activé par défaut. Quand je compile sans options sur mon PC Core2Duo, j'obtiens un binaire 64 bits. Le paramètre generic est sensé produire du 32 bits (i686).

Enfin bon maintenant je mets systématiquement -march=native. A priori, ca produit le meilleur binaire possible pour ton ordi (utilisation des registres et instructions 64 bits).

Ah non mais évidemment, ton système 64 bits est configuré en -march=amd64 (ou truc dans le genre) par défaut hein

Tu devrais te mettre à Gentoo Thibaut.
Bon je dis ça, je me suis vautré lamentablement quand j'ai essayé

Thibaut (./22) :
Ben j'ai l'impression que c'est bien native qui est activé par défaut. Quand je compile sans options sur mon PC Core2Duo, j'obtiens un binaire 64 bits. Le paramètre generic est sensé produire du 32 bits (i686).

Euh non, ça c'est -m32 vs. -m64, c'est totalement séparé.

./24 > Mais comment t'as fait pour te vautrer alors qu'il y a 50000 tuto (howto) dispo et rédigés spécialement pour gentoo ? :x
Sinon oué pour comprendre comment le système fonctionne je pense que tu trouves difficilement mieux, si tu arrives à commencer a une période ou le noyau linux est suffisamment stable (genre pas le 2.6.17~2.6.23 quoi heureusement c le passé...)

J'ai foutu en l'air ma table de partoche puis j'ai arrêté "par précaution"