Je ne parviens pas à trouver de solution en terme de Makefile pour faire
la chose suivante : dans le code, une certain nombre de conditions de
précompilation permet de gérer des petites différences entre une version
verbeuse de développement et une version de production. Je voudrais au
final obtenir quelque chose du genre :
- make prod : génère la version de production ;
- make verbose : génère la version verbeuse.
Tout cela est conditionné par des define géré à la ligne de compilation :
gcc -DDEVEL -DVERBOSE ...
gcc -DPROD ...
Pour l'instant, au mieux j'utilise une condition dans le Makefile. Ce
qui m'oblige à aller modifier ledit Makefile pour changer de version.
DEBUG=yes
ifeq ($(DEBUG),yes)
CFLAGS=...
else
CFLAGS=...
Impossible de transcrire cette idée (somme toute assez basique) dans un
Makefile. N'auriez-vous pas une idée qui me permette de m'en sortir ?
Je ne parviens pas à trouver de solution en terme de Makefile pour faire la chose suivante : dans le code, une certain nombre de conditions de précompilation permet de gérer des petites différences entre une version verbeuse de développement et une version de production. Je voudrais au final obtenir quelque chose du genre : - make prod : génère la version de production ; - make verbose : génère la version verbeuse.
Tout cela est conditionné par des define géré à la ligne de compilation : gcc -DDEVEL -DVERBOSE ... gcc -DPROD ...
Pour l'instant, au mieux j'utilise une condition dans le Makefile. Ce qui m'oblige à aller modifier ledit Makefile pour changer de version. DEBUG=yes ifeq ($(DEBUG),yes) CFLAGS=... else CFLAGS=...
Impossible de transcrire cette idée (somme toute assez basique) dans un Makefile. N'auriez-vous pas une idée qui me permette de m'en sortir ?
Facile à faire dans deux rep distinct, ou avec des noms différents.
Avec des noms différents: CFLAGS_PROD= -DPROD CFLAGS_DEV= -DDEVEL -DVERBOSE # .od = .o version debug .SUFFIXES: .h .c .o .od
Après, pour les executables, faut se dedoubler tous les noms, et toutes les dépendances.
Dans des rep différents: me semble assez évident.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
On 2007-10-15, fabrizio <watch.the@stars.mw> wrote:
Bonjour,
Je ne parviens pas à trouver de solution en terme de Makefile pour faire
la chose suivante : dans le code, une certain nombre de conditions de
précompilation permet de gérer des petites différences entre une version
verbeuse de développement et une version de production. Je voudrais au
final obtenir quelque chose du genre :
- make prod : génère la version de production ;
- make verbose : génère la version verbeuse.
Tout cela est conditionné par des define géré à la ligne de compilation :
gcc -DDEVEL -DVERBOSE ...
gcc -DPROD ...
Pour l'instant, au mieux j'utilise une condition dans le Makefile. Ce
qui m'oblige à aller modifier ledit Makefile pour changer de version.
DEBUG=yes
ifeq ($(DEBUG),yes)
CFLAGS=...
else
CFLAGS=...
Impossible de transcrire cette idée (somme toute assez basique) dans un
Makefile. N'auriez-vous pas une idée qui me permette de m'en sortir ?
Facile à faire dans deux rep distinct, ou avec des noms différents.
Avec des noms différents:
CFLAGS_PROD= -DPROD
CFLAGS_DEV= -DDEVEL -DVERBOSE
# .od = .o version debug
.SUFFIXES: .h .c .o .od
Je ne parviens pas à trouver de solution en terme de Makefile pour faire la chose suivante : dans le code, une certain nombre de conditions de précompilation permet de gérer des petites différences entre une version verbeuse de développement et une version de production. Je voudrais au final obtenir quelque chose du genre : - make prod : génère la version de production ; - make verbose : génère la version verbeuse.
Tout cela est conditionné par des define géré à la ligne de compilation : gcc -DDEVEL -DVERBOSE ... gcc -DPROD ...
Pour l'instant, au mieux j'utilise une condition dans le Makefile. Ce qui m'oblige à aller modifier ledit Makefile pour changer de version. DEBUG=yes ifeq ($(DEBUG),yes) CFLAGS=... else CFLAGS=...
Impossible de transcrire cette idée (somme toute assez basique) dans un Makefile. N'auriez-vous pas une idée qui me permette de m'en sortir ?
Facile à faire dans deux rep distinct, ou avec des noms différents.
Avec des noms différents: CFLAGS_PROD= -DPROD CFLAGS_DEV= -DDEVEL -DVERBOSE # .od = .o version debug .SUFFIXES: .h .c .o .od
Je vais regarder ça, mais s je comprends bien : je compile tout deux fois, et j'édite les liens en fonction de la "targer" appelé lors de l'invocation de make. J'ai bon ou j'ai rien compris ?
Après, pour les executables, faut se dedoubler tous les noms, et toutes les dépendances.
C'est moyen ça.
Dans des rep différents: me semble assez évident.
Et ça, ça m'arrange moyennement aussi.
Merci pour le coup de main, F.
15/10/2007 14:33 - Marc Boyer :
Avec des noms différents:
CFLAGS_PROD= -DPROD
CFLAGS_DEV= -DDEVEL -DVERBOSE
# .od = .o version debug
.SUFFIXES: .h .c .o .od
Je vais regarder ça, mais s je comprends bien : je compile tout deux
fois, et j'édite les liens en fonction de la "targer" appelé lors de
l'invocation de make. J'ai bon ou j'ai rien compris ?
Après, pour les executables, faut se dedoubler tous les noms, et toutes
les dépendances.
Je vais regarder ça, mais s je comprends bien : je compile tout deux fois, et j'édite les liens en fonction de la "targer" appelé lors de l'invocation de make. J'ai bon ou j'ai rien compris ?
Après, pour les executables, faut se dedoubler tous les noms, et toutes les dépendances.
Je vais regarder ça, mais s je comprends bien : je compile tout deux fois, et j'édite les liens en fonction de la "targer" appelé lors de l'invocation de make. J'ai bon ou j'ai rien compris ?
Make étant même un peu plus intelligent, si tu fait make dev il compile et lie en mode debug, en fonction de ce qu'il faut mettre à jour.
Après, pour les executables, faut se dedoubler tous les noms, et toutes les dépendances.
Je vais regarder ça, mais s je comprends bien : je compile tout deux
fois, et j'édite les liens en fonction de la "targer" appelé lors de
l'invocation de make. J'ai bon ou j'ai rien compris ?
Make étant même un peu plus intelligent, si tu fait
make dev
il compile et lie en mode debug, en fonction de ce qu'il
faut mettre à jour.
Après, pour les executables, faut se dedoubler tous les noms, et toutes
les dépendances.
Je vais regarder ça, mais s je comprends bien : je compile tout deux fois, et j'édite les liens en fonction de la "targer" appelé lors de l'invocation de make. J'ai bon ou j'ai rien compris ?
Make étant même un peu plus intelligent, si tu fait make dev il compile et lie en mode debug, en fonction de ce qu'il faut mettre à jour.
Après, pour les executables, faut se dedoubler tous les noms, et toutes les dépendances.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Alain Ketterlin
fabrizio writes:
Je ne parviens pas à trouver de solution en terme de Makefile pour faire la chose suivante : dans le code, une certain nombre de conditions de précompilation permet de gérer des petites différences entre une version verbeuse de développement et une version de production. Je voudrais au final obtenir quelque chose du genre : - make prod : génère la version de production ; - make verbose : génère la version verbeuse.
Tout cela est conditionné par des define géré à la ligne de compilation : gcc -DDEVEL -DVERBOSE ... gcc -DPROD ...
Tu ajoutes deux règles (prod: et verbose:) qui rappellent le make via $(MAKE) avec des paramètres qui te permettent de positionner les $(CFLAGS) etc. (voire directement avec les valeurs de ces variables). Si c'est GNU make, la doc a une section là-dessus ("Recursive use of make", de mémoire).
-- Alain.
fabrizio <watch.the@stars.mw> writes:
Je ne parviens pas à trouver de solution en terme de Makefile pour faire
la chose suivante : dans le code, une certain nombre de conditions de
précompilation permet de gérer des petites différences entre une version
verbeuse de développement et une version de production. Je voudrais au
final obtenir quelque chose du genre :
- make prod : génère la version de production ;
- make verbose : génère la version verbeuse.
Tout cela est conditionné par des define géré à la ligne de compilation :
gcc -DDEVEL -DVERBOSE ...
gcc -DPROD ...
Tu ajoutes deux règles (prod: et verbose:) qui rappellent le make via
$(MAKE) avec des paramètres qui te permettent de positionner les
$(CFLAGS) etc. (voire directement avec les valeurs de ces variables).
Si c'est GNU make, la doc a une section là-dessus ("Recursive
use of make", de mémoire).
Je ne parviens pas à trouver de solution en terme de Makefile pour faire la chose suivante : dans le code, une certain nombre de conditions de précompilation permet de gérer des petites différences entre une version verbeuse de développement et une version de production. Je voudrais au final obtenir quelque chose du genre : - make prod : génère la version de production ; - make verbose : génère la version verbeuse.
Tout cela est conditionné par des define géré à la ligne de compilation : gcc -DDEVEL -DVERBOSE ... gcc -DPROD ...
Tu ajoutes deux règles (prod: et verbose:) qui rappellent le make via $(MAKE) avec des paramètres qui te permettent de positionner les $(CFLAGS) etc. (voire directement avec les valeurs de ces variables). Si c'est GNU make, la doc a une section là-dessus ("Recursive use of make", de mémoire).
-- Alain.
fabrizio
15/10/2007 15:10 - Marc Boyer :
On 2007-10-15, fabrizio wrote:
.SUFFIXES: .h .c .o .od
.c.od: $(CC) $(CFLAGS_DEV) $*.c -o $*.od .c.o: $(CC) $(CFLAGS_PROD) $*.c -o $*.o Je vais regarder ça, mais s je comprends bien : je compile tout deux
fois, et j'édite les liens en fonction de la "targer" appelé lors de l'invocation de make. J'ai bon ou j'ai rien compris ?
Make étant même un peu plus intelligent, si tu fait make dev il compile et lie en mode debug, en fonction de ce qu'il faut mettre à jour.
Il faut que je regarde en détail, il y a trop de chose que je ne connais pas encore dans ce que vous avez proposer pour que je sache si ça me va ou pas.
Après, pour les executables, faut se dedoubler tous les noms, et toutes les dépendances. C'est moyen ça.
Dans des rep différents: me semble assez évident. Et ça, ça m'arrange moyennement aussi.
Pourquoi donc ?
Si j'ai bien compris l'idée, il y a les sources dans un répertoire, puis on génère les objets dans des répertoires distincts. L'autre solution me plaît mieux, a priori.
F.
15/10/2007 15:10 - Marc Boyer :
On 2007-10-15, fabrizio <watch.the@stars.mw> wrote:
.SUFFIXES: .h .c .o .od
.c.od:
$(CC) $(CFLAGS_DEV) $*.c -o $*.od
.c.o:
$(CC) $(CFLAGS_PROD) $*.c -o $*.o
Je vais regarder ça, mais s je comprends bien : je compile tout deux
fois, et j'édite les liens en fonction de la "targer" appelé lors de
l'invocation de make. J'ai bon ou j'ai rien compris ?
Make étant même un peu plus intelligent, si tu fait
make dev
il compile et lie en mode debug, en fonction de ce qu'il
faut mettre à jour.
Il faut que je regarde en détail, il y a trop de chose que je ne connais
pas encore dans ce que vous avez proposer pour que je sache si ça me va
ou pas.
Après, pour les executables, faut se dedoubler tous les noms, et toutes
les dépendances.
C'est moyen ça.
Dans des rep différents: me semble assez évident.
Et ça, ça m'arrange moyennement aussi.
Pourquoi donc ?
Si j'ai bien compris l'idée, il y a les sources dans un répertoire, puis
on génère les objets dans des répertoires distincts. L'autre solution me
plaît mieux, a priori.
.c.od: $(CC) $(CFLAGS_DEV) $*.c -o $*.od .c.o: $(CC) $(CFLAGS_PROD) $*.c -o $*.o Je vais regarder ça, mais s je comprends bien : je compile tout deux
fois, et j'édite les liens en fonction de la "targer" appelé lors de l'invocation de make. J'ai bon ou j'ai rien compris ?
Make étant même un peu plus intelligent, si tu fait make dev il compile et lie en mode debug, en fonction de ce qu'il faut mettre à jour.
Il faut que je regarde en détail, il y a trop de chose que je ne connais pas encore dans ce que vous avez proposer pour que je sache si ça me va ou pas.
Après, pour les executables, faut se dedoubler tous les noms, et toutes les dépendances. C'est moyen ça.
Dans des rep différents: me semble assez évident. Et ça, ça m'arrange moyennement aussi.
Pourquoi donc ?
Si j'ai bien compris l'idée, il y a les sources dans un répertoire, puis on génère les objets dans des répertoires distincts. L'autre solution me plaît mieux, a priori.
F.
fabrizio
15/10/2007 15:31 - Alain Ketterlin :
fabrizio writes:
Je ne parviens pas à trouver de solution en terme de Makefile pour faire la chose suivante : dans le code, une certain nombre de conditions de précompilation permet de gérer des petites différences entre une version verbeuse de développement et une version de production. Je voudrais au final obtenir quelque chose du genre : - make prod : génère la version de production ; - make verbose : génère la version verbeuse.
Tout cela est conditionné par des define géré à la ligne de compilation : gcc -DDEVEL -DVERBOSE ... gcc -DPROD ...
Tu ajoutes deux règles (prod: et verbose:) qui rappellent le make via $(MAKE) avec des paramètres qui te permettent de positionner les $(CFLAGS) etc. (voire directement avec les valeurs de ces variables). Si c'est GNU make, la doc a une section là-dessus ("Recursive use of make", de mémoire).
Diable ! l'appel récursif. Je n'y avais pas pensé.
Merci.
15/10/2007 15:31 - Alain Ketterlin :
fabrizio <watch.the@stars.mw> writes:
Je ne parviens pas à trouver de solution en terme de Makefile pour faire
la chose suivante : dans le code, une certain nombre de conditions de
précompilation permet de gérer des petites différences entre une version
verbeuse de développement et une version de production. Je voudrais au
final obtenir quelque chose du genre :
- make prod : génère la version de production ;
- make verbose : génère la version verbeuse.
Tout cela est conditionné par des define géré à la ligne de compilation :
gcc -DDEVEL -DVERBOSE ...
gcc -DPROD ...
Tu ajoutes deux règles (prod: et verbose:) qui rappellent le make via
$(MAKE) avec des paramètres qui te permettent de positionner les
$(CFLAGS) etc. (voire directement avec les valeurs de ces variables).
Si c'est GNU make, la doc a une section là-dessus ("Recursive
use of make", de mémoire).
Diable ! l'appel récursif. Je n'y avais pas pensé.
Je ne parviens pas à trouver de solution en terme de Makefile pour faire la chose suivante : dans le code, une certain nombre de conditions de précompilation permet de gérer des petites différences entre une version verbeuse de développement et une version de production. Je voudrais au final obtenir quelque chose du genre : - make prod : génère la version de production ; - make verbose : génère la version verbeuse.
Tout cela est conditionné par des define géré à la ligne de compilation : gcc -DDEVEL -DVERBOSE ... gcc -DPROD ...
Tu ajoutes deux règles (prod: et verbose:) qui rappellent le make via $(MAKE) avec des paramètres qui te permettent de positionner les $(CFLAGS) etc. (voire directement avec les valeurs de ces variables). Si c'est GNU make, la doc a une section là-dessus ("Recursive use of make", de mémoire).
Diable ! l'appel récursif. Je n'y avais pas pensé.
Merci.
Matthieu Moy
fabrizio writes:
Je voudrais au final obtenir quelque chose du genre : - make prod : génère la version de production ; - make verbose : génère la version verbeuse.
Avec autoconf/automake, on peut faire ça en ayant un flag du configure, et on peut faire
mkdir build-prod cd build-prod ../configure && make
mkdir build-verbose cd build-verbose ../configure --enable-verbose && make
Je suppose que les concurrents d'autoconf peuvent faire ça aussi, mais je connais pas.
En « make » pur, cf. la réponse de Marc, ou bien
Pour l'instant, au mieux j'utilise une condition dans le Makefile. Ce qui m'oblige à aller modifier ledit Makefile pour changer de version. DEBUG=yes ifeq ($(DEBUG),yes) CFLAGS=... else CFLAGS=...
make DEBUG=yes all
te permet de lancer « make » en positionnant DEBUG à « yes ». Attention, ça ne recompilera pas ce qui a déjà été compilé sans DEBUG.
On peut aller un cran plus loin en faisant
debug: $(MAKE) DEBUG=yes all
all: ...
-- Matthieu
fabrizio <watch.the@stars.mw> writes:
Je voudrais au final obtenir quelque chose du genre :
- make prod : génère la version de production ;
- make verbose : génère la version verbeuse.
Avec autoconf/automake, on peut faire ça en ayant un flag du
configure, et on peut faire
mkdir build-prod
cd build-prod
../configure && make
mkdir build-verbose
cd build-verbose
../configure --enable-verbose && make
Je suppose que les concurrents d'autoconf peuvent faire ça aussi, mais
je connais pas.
En « make » pur, cf. la réponse de Marc, ou bien
Pour l'instant, au mieux j'utilise une condition dans le Makefile. Ce
qui m'oblige à aller modifier ledit Makefile pour changer de version.
DEBUG=yes
ifeq ($(DEBUG),yes)
CFLAGS=...
else
CFLAGS=...
make DEBUG=yes all
te permet de lancer « make » en positionnant DEBUG à « yes ».
Attention, ça ne recompilera pas ce qui a déjà été compilé sans DEBUG.
Je voudrais au final obtenir quelque chose du genre : - make prod : génère la version de production ; - make verbose : génère la version verbeuse.
Avec autoconf/automake, on peut faire ça en ayant un flag du configure, et on peut faire
mkdir build-prod cd build-prod ../configure && make
mkdir build-verbose cd build-verbose ../configure --enable-verbose && make
Je suppose que les concurrents d'autoconf peuvent faire ça aussi, mais je connais pas.
En « make » pur, cf. la réponse de Marc, ou bien
Pour l'instant, au mieux j'utilise une condition dans le Makefile. Ce qui m'oblige à aller modifier ledit Makefile pour changer de version. DEBUG=yes ifeq ($(DEBUG),yes) CFLAGS=... else CFLAGS=...
make DEBUG=yes all
te permet de lancer « make » en positionnant DEBUG à « yes ». Attention, ça ne recompilera pas ce qui a déjà été compilé sans DEBUG.
On peut aller un cran plus loin en faisant
debug: $(MAKE) DEBUG=yes all
all: ...
-- Matthieu
Marc Boyer
On 2007-10-15, Alain Ketterlin wrote:
fabrizio writes:
Je ne parviens pas à trouver de solution en terme de Makefile pour faire la chose suivante : dans le code, une certain nombre de conditions de précompilation permet de gérer des petites différences entre une version verbeuse de développement et une version de production. Je voudrais au final obtenir quelque chose du genre : - make prod : génère la version de production ; - make verbose : génère la version verbeuse.
Tout cela est conditionné par des define géré à la ligne de compilation : gcc -DDEVEL -DVERBOSE ... gcc -DPROD ...
Tu ajoutes deux règles (prod: et verbose:) qui rappellent le make via $(MAKE) avec des paramètres qui te permettent de positionner les $(CFLAGS) etc. (voire directement avec les valeurs de ces variables). Si c'est GNU make, la doc a une section là-dessus ("Recursive use of make", de mémoire).
Le problème de ça, c'est qu'on risque de lier des .o en version debug avec de .o en version prod. A moins bien sur de faire systématiquement le 'clean' qui va bien entre...
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
On 2007-10-15, Alain Ketterlin <alain@dpt-info.u-strasbg.fr> wrote:
fabrizio <watch.the@stars.mw> writes:
Je ne parviens pas à trouver de solution en terme de Makefile pour faire
la chose suivante : dans le code, une certain nombre de conditions de
précompilation permet de gérer des petites différences entre une version
verbeuse de développement et une version de production. Je voudrais au
final obtenir quelque chose du genre :
- make prod : génère la version de production ;
- make verbose : génère la version verbeuse.
Tout cela est conditionné par des define géré à la ligne de compilation :
gcc -DDEVEL -DVERBOSE ...
gcc -DPROD ...
Tu ajoutes deux règles (prod: et verbose:) qui rappellent le make via
$(MAKE) avec des paramètres qui te permettent de positionner les
$(CFLAGS) etc. (voire directement avec les valeurs de ces variables).
Si c'est GNU make, la doc a une section là-dessus ("Recursive
use of make", de mémoire).
Le problème de ça, c'est qu'on risque de lier des .o en version
debug avec de .o en version prod.
A moins bien sur de faire systématiquement le 'clean' qui va
bien entre...
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Je ne parviens pas à trouver de solution en terme de Makefile pour faire la chose suivante : dans le code, une certain nombre de conditions de précompilation permet de gérer des petites différences entre une version verbeuse de développement et une version de production. Je voudrais au final obtenir quelque chose du genre : - make prod : génère la version de production ; - make verbose : génère la version verbeuse.
Tout cela est conditionné par des define géré à la ligne de compilation : gcc -DDEVEL -DVERBOSE ... gcc -DPROD ...
Tu ajoutes deux règles (prod: et verbose:) qui rappellent le make via $(MAKE) avec des paramètres qui te permettent de positionner les $(CFLAGS) etc. (voire directement avec les valeurs de ces variables). Si c'est GNU make, la doc a une section là-dessus ("Recursive use of make", de mémoire).
Le problème de ça, c'est qu'on risque de lier des .o en version debug avec de .o en version prod. A moins bien sur de faire systématiquement le 'clean' qui va bien entre...
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Marc Boyer
On 2007-10-15, fabrizio wrote:
15/10/2007 15:10 - Marc Boyer :
On 2007-10-15, fabrizio wrote:
.SUFFIXES: .h .c .o .od
.c.od: $(CC) $(CFLAGS_DEV) $*.c -o $*.od .c.o: $(CC) $(CFLAGS_PROD) $*.c -o $*.o Je vais regarder ça, mais s je comprends bien : je compile tout deux
fois, et j'édite les liens en fonction de la "targer" appelé lors de l'invocation de make. J'ai bon ou j'ai rien compris ?
Make étant même un peu plus intelligent, si tu fait make dev il compile et lie en mode debug, en fonction de ce qu'il faut mettre à jour.
Il faut que je regarde en détail, il y a trop de chose que je ne connais pas encore dans ce que vous avez proposer pour que je sache si ça me va ou pas.
Je peux te file la doc Make que je donne à mes étudiants. J'y fait cette manip.
Après, pour les executables, faut se dedoubler tous les noms, et toutes les dépendances. C'est moyen ça.
Dans des rep différents: me semble assez évident. Et ça, ça m'arrange moyennement aussi.
Pourquoi donc ?
Si j'ai bien compris l'idée, il y a les sources dans un répertoire, puis on génère les objets dans des répertoires distincts. L'autre solution me plaît mieux, a priori.
L'avantage d'avoir deux répertoires distincs, c'est que les binaires peuvent avoir les mêmes noms (puisqu'on fait la différence sur l'emplacement). Si on met tout dans le même répertoire, il faut différencier les noms...
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
On 2007-10-15, fabrizio <watch.the@stars.mw> wrote:
15/10/2007 15:10 - Marc Boyer :
On 2007-10-15, fabrizio <watch.the@stars.mw> wrote:
.SUFFIXES: .h .c .o .od
.c.od:
$(CC) $(CFLAGS_DEV) $*.c -o $*.od
.c.o:
$(CC) $(CFLAGS_PROD) $*.c -o $*.o
Je vais regarder ça, mais s je comprends bien : je compile tout deux
fois, et j'édite les liens en fonction de la "targer" appelé lors de
l'invocation de make. J'ai bon ou j'ai rien compris ?
Make étant même un peu plus intelligent, si tu fait
make dev
il compile et lie en mode debug, en fonction de ce qu'il
faut mettre à jour.
Il faut que je regarde en détail, il y a trop de chose que je ne connais
pas encore dans ce que vous avez proposer pour que je sache si ça me va
ou pas.
Je peux te file la doc Make que je donne à mes étudiants. J'y
fait cette manip.
Après, pour les executables, faut se dedoubler tous les noms, et toutes
les dépendances.
C'est moyen ça.
Dans des rep différents: me semble assez évident.
Et ça, ça m'arrange moyennement aussi.
Pourquoi donc ?
Si j'ai bien compris l'idée, il y a les sources dans un répertoire, puis
on génère les objets dans des répertoires distincts. L'autre solution me
plaît mieux, a priori.
L'avantage d'avoir deux répertoires distincs, c'est que les binaires
peuvent avoir les mêmes noms (puisqu'on fait la différence sur
l'emplacement). Si on met tout dans le même répertoire, il faut
différencier les noms...
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
.c.od: $(CC) $(CFLAGS_DEV) $*.c -o $*.od .c.o: $(CC) $(CFLAGS_PROD) $*.c -o $*.o Je vais regarder ça, mais s je comprends bien : je compile tout deux
fois, et j'édite les liens en fonction de la "targer" appelé lors de l'invocation de make. J'ai bon ou j'ai rien compris ?
Make étant même un peu plus intelligent, si tu fait make dev il compile et lie en mode debug, en fonction de ce qu'il faut mettre à jour.
Il faut que je regarde en détail, il y a trop de chose que je ne connais pas encore dans ce que vous avez proposer pour que je sache si ça me va ou pas.
Je peux te file la doc Make que je donne à mes étudiants. J'y fait cette manip.
Après, pour les executables, faut se dedoubler tous les noms, et toutes les dépendances. C'est moyen ça.
Dans des rep différents: me semble assez évident. Et ça, ça m'arrange moyennement aussi.
Pourquoi donc ?
Si j'ai bien compris l'idée, il y a les sources dans un répertoire, puis on génère les objets dans des répertoires distincts. L'autre solution me plaît mieux, a priori.
L'avantage d'avoir deux répertoires distincs, c'est que les binaires peuvent avoir les mêmes noms (puisqu'on fait la différence sur l'emplacement). Si on met tout dans le même répertoire, il faut différencier les noms...
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
fabrizio
15/10/2007 15:41 - Marc Boyer :
Je peux te file la doc Make que je donne à mes étudiants. J'y fait cette manip.
Ça ne peut pas me faire de mal. Je prends et t'en remercie.
15/10/2007 15:41 - Marc Boyer :
Je peux te file la doc Make que je donne à mes étudiants. J'y
fait cette manip.
Ça ne peut pas me faire de mal. Je prends et t'en remercie.
