Avec le makefile que j'ai récupéré ici, je rencontre un pb. Je voudrais
compiler avec l'option -g pour utiliser le debuggeur gdb sous linux, mais
à cause de la règle SRC= $(wildcard *.cpp), je ne peux pas.
Quelqu'un a une idée?
Voici le makefile complet.
CC=g++
CFLAGS=-Wall -g
LDFLAGS=-Wall
EXEC=noyauSGBD
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
noone
Bonjour,
Avec le makefile que j'ai récupéré ici, je rencontre un pb. Je voudrais compiler avec l'option -g pour utiliser le debuggeur gdb sous linux, mais à cause de la règle SRC= $(wildcard *.cpp), je ne peux pas.
Quelqu'un a une idée? Voici le makefile complet.
je te donne le mien
CXX = LC_ALL=posix g++ # pour avoir les messages de g++ en anglais
ça ne pose pas de pb pour débugguer avec gdb (j'utilise ddd)
Bonjour,
Avec le makefile que j'ai récupéré ici, je rencontre un pb. Je voudrais
compiler avec l'option -g pour utiliser le debuggeur gdb sous linux, mais
à cause de la règle SRC= $(wildcard *.cpp), je ne peux pas.
Quelqu'un a une idée?
Voici le makefile complet.
je te donne le mien
CXX = LC_ALL=posix g++
# pour avoir les messages de g++ en anglais
Avec le makefile que j'ai récupéré ici, je rencontre un pb. Je voudrais compiler avec l'option -g pour utiliser le debuggeur gdb sous linux, mais à cause de la règle SRC= $(wildcard *.cpp), je ne peux pas.
Quelqu'un a une idée? Voici le makefile complet.
je te donne le mien
CXX = LC_ALL=posix g++ # pour avoir les messages de g++ en anglais
ça ne pose pas de pb pour débugguer avec gdb (j'utilise ddd)
espie
In article , Pascal wrote:
Bonjour,
Avec le makefile que j'ai récupéré ici, je rencontre un pb. Je voudrais compiler avec l'option -g pour utiliser le debuggeur gdb sous linux, mais à cause de la règle SRC= $(wildcard *.cpp), je ne peux pas.
Vous etes bien tous au courant que ce machin utilise de l'extension Gnu-Makefile a ne plus savoir quoi en foutre (beurk) ?
Le coup d'avoir systematiquement le *.cpp qui depend du *.h, bof.
Le coup d'utiliser CC et CFLAGS pour du code C++, c'est encore pire! D'ailleurs, il y a clairement quelque chose de pas compris ici, vu la duplication du -Wall -g dans les regles et dans les CFLAGS...
Au cas ou vous ne le sauriez pas encore, on peut tres bien avoir la regle de compilation separee des dependances.
En general, ca ressemble pas mal a:
.cpp.o: $(CXX) -c $(CXXFLAGS) $<
et plus loin:
foo.o: foo.h
(avec eventuellement le .SUFFIXES qui va bien).
Ah, sinon, mettre des -g et consorts directement dans le Makefile, c'est tres tres bof. C'est infiniment mieux d'avoir une variable (CXXFLAGS est a peu pres standard) qu'on assemble bout par bout, style
sachant qu'on n'a pas a modifier le Makefile apres coup, vu qu'on peut changer ces variables depuis la ligne de commande: make foo DEBUG pour mettre DEBUG a rien par exemple.
In article <pan.2005.02.22.19.08.37.736009@B022-05.fr>,
Pascal <teapa5@B022-05.fr> wrote:
Bonjour,
Avec le makefile que j'ai récupéré ici, je rencontre un pb. Je voudrais
compiler avec l'option -g pour utiliser le debuggeur gdb sous linux, mais
à cause de la règle SRC= $(wildcard *.cpp), je ne peux pas.
Vous etes bien tous au courant que ce machin utilise de l'extension
Gnu-Makefile a ne plus savoir quoi en foutre (beurk) ?
Le coup d'avoir systematiquement le *.cpp qui depend du *.h, bof.
Le coup d'utiliser CC et CFLAGS pour du code C++, c'est encore pire!
D'ailleurs, il y a clairement quelque chose de pas compris ici, vu la
duplication du -Wall -g dans les regles et dans les CFLAGS...
Au cas ou vous ne le sauriez pas encore, on peut tres bien avoir la
regle de compilation separee des dependances.
En general, ca ressemble pas mal a:
.cpp.o:
$(CXX) -c $(CXXFLAGS) $<
et plus loin:
foo.o: foo.h
(avec eventuellement le .SUFFIXES qui va bien).
Ah, sinon, mettre des -g et consorts directement dans le Makefile, c'est
tres tres bof. C'est infiniment mieux d'avoir une variable (CXXFLAGS est
a peu pres standard) qu'on assemble bout par bout, style
sachant qu'on n'a pas a modifier le Makefile apres coup, vu qu'on peut
changer ces variables depuis la ligne de commande:
make foo DEBUG pour mettre DEBUG a rien par exemple.
Avec le makefile que j'ai récupéré ici, je rencontre un pb. Je voudrais compiler avec l'option -g pour utiliser le debuggeur gdb sous linux, mais à cause de la règle SRC= $(wildcard *.cpp), je ne peux pas.
Vous etes bien tous au courant que ce machin utilise de l'extension Gnu-Makefile a ne plus savoir quoi en foutre (beurk) ?
Le coup d'avoir systematiquement le *.cpp qui depend du *.h, bof.
Le coup d'utiliser CC et CFLAGS pour du code C++, c'est encore pire! D'ailleurs, il y a clairement quelque chose de pas compris ici, vu la duplication du -Wall -g dans les regles et dans les CFLAGS...
Au cas ou vous ne le sauriez pas encore, on peut tres bien avoir la regle de compilation separee des dependances.
En general, ca ressemble pas mal a:
.cpp.o: $(CXX) -c $(CXXFLAGS) $<
et plus loin:
foo.o: foo.h
(avec eventuellement le .SUFFIXES qui va bien).
Ah, sinon, mettre des -g et consorts directement dans le Makefile, c'est tres tres bof. C'est infiniment mieux d'avoir une variable (CXXFLAGS est a peu pres standard) qu'on assemble bout par bout, style
sachant qu'on n'a pas a modifier le Makefile apres coup, vu qu'on peut changer ces variables depuis la ligne de commande: make foo DEBUG pour mettre DEBUG a rien par exemple.
Pascal
Marc Espie wrote:
Vous etes bien tous au courant que ce machin utilise de l'extension Gnu-Makefile a ne plus savoir quoi en foutre (beurk) ?
Mais cela reste extrèment pratique. En cas d'ajout d'un nouveau fichier/classe, pas besoin de l'ajouter à la liste des sources.
Le coup d'avoir systematiquement le *.cpp qui depend du *.h, bof.
Pourquoi?
Le coup d'utiliser CC et CFLAGS pour du code C++, c'est encore pire! D'ailleurs, il y a clairement quelque chose de pas compris ici, vu la duplication du -Wall -g dans les regles et dans les CFLAGS...
nop, j'ai compris comment marche le makefile. J'ai récupéré un makefile que j'ai modifié. La flemme de le corriger.
Au cas ou vous ne le sauriez pas encore, on peut tres bien avoir la regle de compilation separee des dependances.
Pas pratique du tout.
En general, ca ressemble pas mal a:
.cpp.o: $(CXX) -c $(CXXFLAGS) $<
et plus loin:
foo.o: foo.h
(avec eventuellement le .SUFFIXES qui va bien).
Ah, sinon, mettre des -g et consorts directement dans le Makefile, c'est tres tres bof. C'est infiniment mieux d'avoir une variable (CXXFLAGS est a peu pres standard) qu'on assemble bout par bout, style
C'est bof si on compte fournir le source avec un makefile. La je m'en sers pour finir/debugger mon prog. Taper à chaque compilation make foo DEBUG=, c'est pas super pratique...
sachant qu'on n'a pas a modifier le Makefile apres coup, vu qu'on peut changer ces variables depuis la ligne de commande: make foo DEBUG > pour mettre DEBUG a rien par exemple.
-- Pascal
Marc Espie wrote:
Vous etes bien tous au courant que ce machin utilise de l'extension
Gnu-Makefile a ne plus savoir quoi en foutre (beurk) ?
Mais cela reste extrèment pratique. En cas d'ajout d'un nouveau
fichier/classe, pas besoin de l'ajouter à la liste des sources.
Le coup d'avoir systematiquement le *.cpp qui depend du *.h, bof.
Pourquoi?
Le coup d'utiliser CC et CFLAGS pour du code C++, c'est encore pire!
D'ailleurs, il y a clairement quelque chose de pas compris ici, vu la
duplication du -Wall -g dans les regles et dans les CFLAGS...
nop, j'ai compris comment marche le makefile. J'ai récupéré un makefile
que j'ai modifié. La flemme de le corriger.
Au cas ou vous ne le sauriez pas encore, on peut tres bien avoir la
regle de compilation separee des dependances.
Pas pratique du tout.
En general, ca ressemble pas mal a:
.cpp.o:
$(CXX) -c $(CXXFLAGS) $<
et plus loin:
foo.o: foo.h
(avec eventuellement le .SUFFIXES qui va bien).
Ah, sinon, mettre des -g et consorts directement dans le Makefile, c'est
tres tres bof. C'est infiniment mieux d'avoir une variable (CXXFLAGS est
a peu pres standard) qu'on assemble bout par bout, style
C'est bof si on compte fournir le source avec un makefile. La je m'en
sers pour finir/debugger mon prog. Taper à chaque compilation make foo
DEBUG=, c'est pas super pratique...
sachant qu'on n'a pas a modifier le Makefile apres coup, vu qu'on peut
changer ces variables depuis la ligne de commande:
make foo DEBUG > pour mettre DEBUG a rien par exemple.
Vous etes bien tous au courant que ce machin utilise de l'extension Gnu-Makefile a ne plus savoir quoi en foutre (beurk) ?
Mais cela reste extrèment pratique. En cas d'ajout d'un nouveau fichier/classe, pas besoin de l'ajouter à la liste des sources.
Le coup d'avoir systematiquement le *.cpp qui depend du *.h, bof.
Pourquoi?
Le coup d'utiliser CC et CFLAGS pour du code C++, c'est encore pire! D'ailleurs, il y a clairement quelque chose de pas compris ici, vu la duplication du -Wall -g dans les regles et dans les CFLAGS...
nop, j'ai compris comment marche le makefile. J'ai récupéré un makefile que j'ai modifié. La flemme de le corriger.
Au cas ou vous ne le sauriez pas encore, on peut tres bien avoir la regle de compilation separee des dependances.
Pas pratique du tout.
En general, ca ressemble pas mal a:
.cpp.o: $(CXX) -c $(CXXFLAGS) $<
et plus loin:
foo.o: foo.h
(avec eventuellement le .SUFFIXES qui va bien).
Ah, sinon, mettre des -g et consorts directement dans le Makefile, c'est tres tres bof. C'est infiniment mieux d'avoir une variable (CXXFLAGS est a peu pres standard) qu'on assemble bout par bout, style
C'est bof si on compte fournir le source avec un makefile. La je m'en sers pour finir/debugger mon prog. Taper à chaque compilation make foo DEBUG=, c'est pas super pratique...
sachant qu'on n'a pas a modifier le Makefile apres coup, vu qu'on peut changer ces variables depuis la ligne de commande: make foo DEBUG > pour mettre DEBUG a rien par exemple.
Avec le makefile que j'ai récupéré ici, je rencontre un pb. Je voudrais compiler avec l'option -g pour utiliser le debuggeur gdb sous linux, mais à cause de la règle SRC= $(wildcard *.cpp), je ne peux pas.
Vous etes bien tous au courant que ce machin utilise de l'extension Gnu-Makefile a ne plus savoir quoi en foutre (beurk) ?
Pourquoi beurk ? Ce qu'on peut faire portablement avec make est très, très restreint. Alors, où bien, on a un autre outil, ou bien, on se standardise sur un make un peu puissant, et on se sert de ses extensions. Or, le seul make un peu puissant qu'on risque de pouvoir trouver ou installer à peu près partout, c'est GNU Make.
La seule chose que je préconciserais, c'est que si on fait du GNU Make, qu'on nomme le fichier GNUmakefile, et non makefile ou Makefile. De façon à ce que d'autres make ne le trouve pas.
Mais évidemment, pour des petites choses simples...
Le coup d'avoir systematiquement le *.cpp qui depend du *.h, bof.
En effet. Il existe des façons bien mieux pour gérer les dépendences. Bien plus compliquées, c'est vrai, mais au moins elles marchent correctement. (Je n'ai jamais vu un projet où chaque source dépendait de son propre en-tête, et uniquement de cet en-tête.)
Le coup d'utiliser CC et CFLAGS pour du code C++, c'est encore pire! D'ailleurs, il y a clairement quelque chose de pas compris ici, vu la duplication du -Wall -g dans les regles et dans les CFLAGS...
Au cas ou vous ne le sauriez pas encore, on peut tres bien avoir la regle de compilation separee des dependances.
En fait, c'est plutôt le cas habituel, je crois. Dans tous les projets que j'ai vus, les dépendances étaient générées automatiquement, soit à chaque invocation de make, soit au moyen d'une cible « depends ».
En general, ca ressemble pas mal a:
.cpp.o: $(CXX) -c $(CXXFLAGS) $<
et plus loin:
foo.o: foo.h
(avec eventuellement le .SUFFIXES qui va bien).
Ah, sinon, mettre des -g et consorts directement dans le Makefile, c'est tres tres bof. C'est infiniment mieux d'avoir une variable (CXXFLAGS est a peu pres standard) qu'on assemble bout par bout, style
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Marc Espie wrote:
In article <pan.2005.02.22.19.08.37.736009@B022-05.fr>,
Pascal <teapa5@B022-05.fr> wrote:
Avec le makefile que j'ai récupéré ici, je rencontre un
pb. Je voudrais compiler avec l'option -g pour utiliser le
debuggeur gdb sous linux, mais à cause de la règle SRC=
$(wildcard *.cpp), je ne peux pas.
Vous etes bien tous au courant que ce machin utilise de
l'extension Gnu-Makefile a ne plus savoir quoi en foutre
(beurk) ?
Pourquoi beurk ? Ce qu'on peut faire portablement avec make est
très, très restreint. Alors, où bien, on a un autre outil, ou
bien, on se standardise sur un make un peu puissant, et on se
sert de ses extensions. Or, le seul make un peu puissant qu'on
risque de pouvoir trouver ou installer à peu près partout, c'est
GNU Make.
La seule chose que je préconciserais, c'est que si on fait du
GNU Make, qu'on nomme le fichier GNUmakefile, et non makefile ou
Makefile. De façon à ce que d'autres make ne le trouve pas.
Mais évidemment, pour des petites choses simples...
Le coup d'avoir systematiquement le *.cpp qui depend du *.h,
bof.
En effet. Il existe des façons bien mieux pour gérer les
dépendences. Bien plus compliquées, c'est vrai, mais au moins
elles marchent correctement. (Je n'ai jamais vu un projet où
chaque source dépendait de son propre en-tête, et uniquement de
cet en-tête.)
Le coup d'utiliser CC et CFLAGS pour du code C++, c'est encore
pire! D'ailleurs, il y a clairement quelque chose de pas
compris ici, vu la duplication du -Wall -g dans les regles et
dans les CFLAGS...
Au cas ou vous ne le sauriez pas encore, on peut tres bien
avoir la regle de compilation separee des dependances.
En fait, c'est plutôt le cas habituel, je crois. Dans tous les
projets que j'ai vus, les dépendances étaient générées
automatiquement, soit à chaque invocation de make, soit au moyen
d'une cible « depends ».
En general, ca ressemble pas mal a:
.cpp.o:
$(CXX) -c $(CXXFLAGS) $<
et plus loin:
foo.o: foo.h
(avec eventuellement le .SUFFIXES qui va bien).
Ah, sinon, mettre des -g et consorts directement dans le
Makefile, c'est tres tres bof. C'est infiniment mieux d'avoir
une variable (CXXFLAGS est a peu pres standard) qu'on assemble
bout par bout, style
Avec le makefile que j'ai récupéré ici, je rencontre un pb. Je voudrais compiler avec l'option -g pour utiliser le debuggeur gdb sous linux, mais à cause de la règle SRC= $(wildcard *.cpp), je ne peux pas.
Vous etes bien tous au courant que ce machin utilise de l'extension Gnu-Makefile a ne plus savoir quoi en foutre (beurk) ?
Pourquoi beurk ? Ce qu'on peut faire portablement avec make est très, très restreint. Alors, où bien, on a un autre outil, ou bien, on se standardise sur un make un peu puissant, et on se sert de ses extensions. Or, le seul make un peu puissant qu'on risque de pouvoir trouver ou installer à peu près partout, c'est GNU Make.
La seule chose que je préconciserais, c'est que si on fait du GNU Make, qu'on nomme le fichier GNUmakefile, et non makefile ou Makefile. De façon à ce que d'autres make ne le trouve pas.
Mais évidemment, pour des petites choses simples...
Le coup d'avoir systematiquement le *.cpp qui depend du *.h, bof.
En effet. Il existe des façons bien mieux pour gérer les dépendences. Bien plus compliquées, c'est vrai, mais au moins elles marchent correctement. (Je n'ai jamais vu un projet où chaque source dépendait de son propre en-tête, et uniquement de cet en-tête.)
Le coup d'utiliser CC et CFLAGS pour du code C++, c'est encore pire! D'ailleurs, il y a clairement quelque chose de pas compris ici, vu la duplication du -Wall -g dans les regles et dans les CFLAGS...
Au cas ou vous ne le sauriez pas encore, on peut tres bien avoir la regle de compilation separee des dependances.
En fait, c'est plutôt le cas habituel, je crois. Dans tous les projets que j'ai vus, les dépendances étaient générées automatiquement, soit à chaque invocation de make, soit au moyen d'une cible « depends ».
En general, ca ressemble pas mal a:
.cpp.o: $(CXX) -c $(CXXFLAGS) $<
et plus loin:
foo.o: foo.h
(avec eventuellement le .SUFFIXES qui va bien).
Ah, sinon, mettre des -g et consorts directement dans le Makefile, c'est tres tres bof. C'est infiniment mieux d'avoir une variable (CXXFLAGS est a peu pres standard) qu'on assemble bout par bout, style
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Pascal wrote:
Marc Espie wrote:
Le coup d'avoir systematiquement le *.cpp qui depend du *.h, bof.
Pourquoi?
Parce que c'est faux, à prèsque tous les coups. Tu veux dire que tous tes x.cpp inclut x.h, et seulement x.h.
Au cas ou vous ne le sauriez pas encore, on peut tres bien avoir la regle de compilation separee des dependances.
Pas pratique du tout.
Au contraire, parce qu'en général, on génère les dépendances automatiquement.
En general, ca ressemble pas mal a:
.cpp.o: $(CXX) -c $(CXXFLAGS) $<
et plus loin:
foo.o: foo.h
(avec eventuellement le .SUFFIXES qui va bien).
Ah, sinon, mettre des -g et consorts directement dans le Makefile, c'est tres tres bof. C'est infiniment mieux d'avoir une variable (CXXFLAGS est a peu pres standard) qu'on assemble bout par bout, style
C'est bof si on compte fournir le source avec un makefile. La je m'en sers pour finir/debugger mon prog. Taper à chaque compilation make foo DEBUG=, c'est pas super pratique...
Mais qui tape quoique ce soit ? Tu le tapes une fois, et l'outil d'où tu lances tes make s'en souviens. Si c'est bash, soit des ^P, soit ESC, puis des k, t'amènent aux commandes précédantes. En emacs, ^C-M se rappelle de la dernière commande, et la présente de nouveau pour que tu puisses l'éditer, ou simplement faire return pour l'exécuter. Sous vim, il faut positionner la variable makeprg. Etc. Je vois mal un outil où il faudrait rentrer la commande complète chaque fois.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Pascal wrote:
Marc Espie wrote:
Le coup d'avoir systematiquement le *.cpp qui depend du *.h,
bof.
Pourquoi?
Parce que c'est faux, à prèsque tous les coups. Tu veux dire que
tous tes x.cpp inclut x.h, et seulement x.h.
Au cas ou vous ne le sauriez pas encore, on peut tres bien
avoir la regle de compilation separee des dependances.
Pas pratique du tout.
Au contraire, parce qu'en général, on génère les dépendances
automatiquement.
En general, ca ressemble pas mal a:
.cpp.o:
$(CXX) -c $(CXXFLAGS) $<
et plus loin:
foo.o: foo.h
(avec eventuellement le .SUFFIXES qui va bien).
Ah, sinon, mettre des -g et consorts directement dans le
Makefile, c'est tres tres bof. C'est infiniment mieux
d'avoir une variable (CXXFLAGS est a peu pres standard)
qu'on assemble bout par bout, style
C'est bof si on compte fournir le source avec un makefile. La
je m'en sers pour finir/debugger mon prog. Taper à chaque
compilation make foo DEBUG=, c'est pas super pratique...
Mais qui tape quoique ce soit ? Tu le tapes une fois, et l'outil
d'où tu lances tes make s'en souviens. Si c'est bash, soit des
^P, soit ESC, puis des k, t'amènent aux commandes précédantes.
En emacs, ^C-M se rappelle de la dernière commande, et la
présente de nouveau pour que tu puisses l'éditer, ou simplement
faire return pour l'exécuter. Sous vim, il faut positionner la
variable makeprg. Etc. Je vois mal un outil où il faudrait
rentrer la commande complète chaque fois.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Le coup d'avoir systematiquement le *.cpp qui depend du *.h, bof.
Pourquoi?
Parce que c'est faux, à prèsque tous les coups. Tu veux dire que tous tes x.cpp inclut x.h, et seulement x.h.
Au cas ou vous ne le sauriez pas encore, on peut tres bien avoir la regle de compilation separee des dependances.
Pas pratique du tout.
Au contraire, parce qu'en général, on génère les dépendances automatiquement.
En general, ca ressemble pas mal a:
.cpp.o: $(CXX) -c $(CXXFLAGS) $<
et plus loin:
foo.o: foo.h
(avec eventuellement le .SUFFIXES qui va bien).
Ah, sinon, mettre des -g et consorts directement dans le Makefile, c'est tres tres bof. C'est infiniment mieux d'avoir une variable (CXXFLAGS est a peu pres standard) qu'on assemble bout par bout, style
C'est bof si on compte fournir le source avec un makefile. La je m'en sers pour finir/debugger mon prog. Taper à chaque compilation make foo DEBUG=, c'est pas super pratique...
Mais qui tape quoique ce soit ? Tu le tapes une fois, et l'outil d'où tu lances tes make s'en souviens. Si c'est bash, soit des ^P, soit ESC, puis des k, t'amènent aux commandes précédantes. En emacs, ^C-M se rappelle de la dernière commande, et la présente de nouveau pour que tu puisses l'éditer, ou simplement faire return pour l'exécuter. Sous vim, il faut positionner la variable makeprg. Etc. Je vois mal un outil où il faudrait rentrer la commande complète chaque fois.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
noone
Merci pour ton makefile, il marche nickel.
Oui mais je n'ai pas de mérite... je l'ai juste fait en regardant la doc... $ info make
tu peux rajouter les règles suivantes :
.PHONY: clean $(RM) *.o $(FILENAME)
par contre certains noms de variables ne doivent pas être très standard...
maintenant il faut que j'apprenne un peu comment marche autoconf, automake, et tout le toutim...
$ info autoconf $ info automake ...
Merci pour ton makefile, il marche nickel.
Oui mais je n'ai pas de mérite...
je l'ai juste fait en regardant la doc...
$ info make
tu peux rajouter les règles suivantes :
.PHONY: clean
$(RM) *.o $(FILENAME)
par contre certains noms de variables ne doivent pas être très standard...
maintenant il faut que j'apprenne un peu comment marche autoconf,
automake, et tout le toutim...
