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 ?
Après test, cette solution me va très bien. Je vous remercie tous.
F.
Paul Gaborit
À (at) Mon, 15 Oct 2007 13:39:01 +0000 (UTC), Marc Boyer écrivait (wrote):
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...
A priori, dans cette situation, je préfère la solution de Marc : deux arborescences de compilation séparées (utilisant les même sources), l'une pour la version de test et l'autre pour la version de prod.
Mais on peut aussi faire avec une seule. Mais le changement (prod <=> test) nécessite de tout recompiler. Pour garantir cela, il faut utiliser un fichier dont dépendent toutes les compilations et le 'toucher' à chaque fois qu'on change. Je ferai donc deux fichiers d'options (un pour prod et un pour test) :
---- Make-TEST -------------- #+++ Pour version de TEST +++ CFLAGS=-g -DDEBUG -DVERBOSE ...
Toutes les règles de compilation doivent dépendre de Make-${VERS} pour garantir la (re)compilation à chaque fois qu'on change.
Et on appelle soit par :
make VERS='TEST' ou make
soit par :
make VERS='PROD'
Avec un truc comme ça, ça doit marcher...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Mon, 15 Oct 2007 13:39:01 +0000 (UTC),
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> écrivait (wrote):
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...
A priori, dans cette situation, je préfère la solution de Marc : deux
arborescences de compilation séparées (utilisant les même sources),
l'une pour la version de test et l'autre pour la version de prod.
Mais on peut aussi faire avec une seule. Mais le changement (prod <=>
test) nécessite de tout recompiler. Pour garantir cela, il faut
utiliser un fichier dont dépendent toutes les compilations et le
'toucher' à chaque fois qu'on change. Je ferai donc deux fichiers
d'options (un pour prod et un pour test) :
---- Make-TEST --------------
#+++ Pour version de TEST +++
CFLAGS=-g -DDEBUG -DVERBOSE ...
À (at) Mon, 15 Oct 2007 13:39:01 +0000 (UTC), Marc Boyer écrivait (wrote):
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...
A priori, dans cette situation, je préfère la solution de Marc : deux arborescences de compilation séparées (utilisant les même sources), l'une pour la version de test et l'autre pour la version de prod.
Mais on peut aussi faire avec une seule. Mais le changement (prod <=> test) nécessite de tout recompiler. Pour garantir cela, il faut utiliser un fichier dont dépendent toutes les compilations et le 'toucher' à chaque fois qu'on change. Je ferai donc deux fichiers d'options (un pour prod et un pour test) :
---- Make-TEST -------------- #+++ Pour version de TEST +++ CFLAGS=-g -DDEBUG -DVERBOSE ...
Et si ton adresse n'est pas valide, fabrizio, tu devrais la suffixer par le nom de domaine réservé INVALID : fabrizio
Voilà qui est fait.
Merci beaucoup !
Marc Boyer
On 2007-10-15, Paul Gaborit wrote:
A priori, dans cette situation, je préfère la solution de Marc : deux arborescences de compilation séparées (utilisant les même sources), l'une pour la version de test et l'autre pour la version de prod.
Oui, ça me semble même la solution la plus classique.
Mais on peut aussi faire avec une seule. Mais le changement (prod <=> test) nécessite de tout recompiler. Pour garantir cela, il faut utiliser un fichier dont dépendent toutes les compilations et le 'toucher' à chaque fois qu'on change. Je ferai donc deux fichiers d'options (un pour prod et un pour test) :
---- Make-TEST -------------- #+++ Pour version de TEST +++ CFLAGS=-g -DDEBUG -DVERBOSE ...
Make-TEST: Make-PROD touch Make-TEST
Et là, je rajouterais le make -f Make-PROD clean histoire de pas avoir les .o de test et les .o de prod qui se mélangent.
Toutes les règles de compilation doivent dépendre de Make-${VERS} pour garantir la (re)compilation à chaque fois qu'on change.
Je préfère la version avec clean. Non ?
M'enfin bon, c'est beaucoup d'emmerdes pour éviter les deux répertoires...
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, Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
A priori, dans cette situation, je préfère la solution de Marc : deux
arborescences de compilation séparées (utilisant les même sources),
l'une pour la version de test et l'autre pour la version de prod.
Oui, ça me semble même la solution la plus classique.
Mais on peut aussi faire avec une seule. Mais le changement (prod <=>
test) nécessite de tout recompiler. Pour garantir cela, il faut
utiliser un fichier dont dépendent toutes les compilations et le
'toucher' à chaque fois qu'on change. Je ferai donc deux fichiers
d'options (un pour prod et un pour test) :
---- Make-TEST --------------
#+++ Pour version de TEST +++
CFLAGS=-g -DDEBUG -DVERBOSE ...
Make-TEST: Make-PROD
touch Make-TEST
Et là, je rajouterais le
make -f Make-PROD clean
histoire de pas avoir les .o de test et les .o de prod qui
se mélangent.
Toutes les règles de compilation doivent dépendre de Make-${VERS} pour
garantir la (re)compilation à chaque fois qu'on change.
Je préfère la version avec clean. Non ?
M'enfin bon, c'est beaucoup d'emmerdes pour éviter les deux
répertoires...
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
A priori, dans cette situation, je préfère la solution de Marc : deux arborescences de compilation séparées (utilisant les même sources), l'une pour la version de test et l'autre pour la version de prod.
Oui, ça me semble même la solution la plus classique.
Mais on peut aussi faire avec une seule. Mais le changement (prod <=> test) nécessite de tout recompiler. Pour garantir cela, il faut utiliser un fichier dont dépendent toutes les compilations et le 'toucher' à chaque fois qu'on change. Je ferai donc deux fichiers d'options (un pour prod et un pour test) :
---- Make-TEST -------------- #+++ Pour version de TEST +++ CFLAGS=-g -DDEBUG -DVERBOSE ...
Make-TEST: Make-PROD touch Make-TEST
Et là, je rajouterais le make -f Make-PROD clean histoire de pas avoir les .o de test et les .o de prod qui se mélangent.
Toutes les règles de compilation doivent dépendre de Make-${VERS} pour garantir la (re)compilation à chaque fois qu'on change.
Je préfère la version avec clean. Non ?
M'enfin bon, c'est beaucoup d'emmerdes pour éviter les deux répertoires...
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Paul Gaborit
À (at) Tue, 16 Oct 2007 08:29:17 +0000 (UTC), Marc Boyer écrivait (wrote):
On 2007-10-15, Paul Gaborit wrote:
Mais on peut aussi faire avec une seule. Mais le changement (prod <=> test) nécessite de tout recompiler. Pour garantir cela, il faut utiliser un fichier dont dépendent toutes les compilations et le 'toucher' à chaque fois qu'on change. Je ferai donc deux fichiers d'options (un pour prod et un pour test) :
---- Make-TEST -------------- #+++ Pour version de TEST +++ CFLAGS=-g -DDEBUG -DVERBOSE ...
Make-TEST: Make-PROD touch Make-TEST
Et là, je rajouterais le make -f Make-PROD clean histoire de pas avoir les .o de test et les .o de prod qui se mélangent.
Toutes les règles de compilation doivent dépendre de Make-${VERS} pour garantir la (re)compilation à chaque fois qu'on change.
Je préfère la version avec clean. Non ?
L'intérêt de la dépendance supplémentaire est de pouvoir gérer les choses plus finement. On peut imaginer que la production de certains fichiers sont indépendantes de l'aspect TEST/PROD. Et puis, même si on oublie le 'clean', ça marchera.
M'enfin bon, c'est beaucoup d'emmerdes pour éviter les deux répertoires...
Oui... ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Tue, 16 Oct 2007 08:29:17 +0000 (UTC),
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> écrivait (wrote):
On 2007-10-15, Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Mais on peut aussi faire avec une seule. Mais le changement (prod <=>
test) nécessite de tout recompiler. Pour garantir cela, il faut
utiliser un fichier dont dépendent toutes les compilations et le
'toucher' à chaque fois qu'on change. Je ferai donc deux fichiers
d'options (un pour prod et un pour test) :
---- Make-TEST --------------
#+++ Pour version de TEST +++
CFLAGS=-g -DDEBUG -DVERBOSE ...
Make-TEST: Make-PROD
touch Make-TEST
Et là, je rajouterais le
make -f Make-PROD clean
histoire de pas avoir les .o de test et les .o de prod qui
se mélangent.
Toutes les règles de compilation doivent dépendre de Make-${VERS} pour
garantir la (re)compilation à chaque fois qu'on change.
Je préfère la version avec clean. Non ?
L'intérêt de la dépendance supplémentaire est de pouvoir gérer les
choses plus finement. On peut imaginer que la production de certains
fichiers sont indépendantes de l'aspect TEST/PROD. Et puis, même si on
oublie le 'clean', ça marchera.
M'enfin bon, c'est beaucoup d'emmerdes pour éviter les deux
répertoires...
Oui... ;-)
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Tue, 16 Oct 2007 08:29:17 +0000 (UTC), Marc Boyer écrivait (wrote):
On 2007-10-15, Paul Gaborit wrote:
Mais on peut aussi faire avec une seule. Mais le changement (prod <=> test) nécessite de tout recompiler. Pour garantir cela, il faut utiliser un fichier dont dépendent toutes les compilations et le 'toucher' à chaque fois qu'on change. Je ferai donc deux fichiers d'options (un pour prod et un pour test) :
---- Make-TEST -------------- #+++ Pour version de TEST +++ CFLAGS=-g -DDEBUG -DVERBOSE ...
Make-TEST: Make-PROD touch Make-TEST
Et là, je rajouterais le make -f Make-PROD clean histoire de pas avoir les .o de test et les .o de prod qui se mélangent.
Toutes les règles de compilation doivent dépendre de Make-${VERS} pour garantir la (re)compilation à chaque fois qu'on change.
Je préfère la version avec clean. Non ?
L'intérêt de la dépendance supplémentaire est de pouvoir gérer les choses plus finement. On peut imaginer que la production de certains fichiers sont indépendantes de l'aspect TEST/PROD. Et puis, même si on oublie le 'clean', ça marchera.
M'enfin bon, c'est beaucoup d'emmerdes pour éviter les deux répertoires...
Oui... ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Matthieu Moy
Paul Gaborit writes:
L'intérêt de la dépendance supplémentaire est de pouvoir gérer les choses plus finement. On peut imaginer que la production de certains fichiers sont indépendantes de l'aspect TEST/PROD. Et puis, même si on oublie le 'clean', ça marchera.
Au passage, si on en est à ajouter des dépendances, une solution est d'avoir un fichier config.h qui contienne, ou ne contienne pas #define DEBUG, en remplacement du -DDEBUG.
Si le Makefile est bien foutu, il prendra en compte la dépendance, et y'aura qu'à modifier le fichier et à faire "make" pour changer de mode. Bien sûr, ça, c'est si on ne compte pas avoir deux builds séparés en parallèle pour les deux modes (i.e. si on est pret à payer le prix d'une recompilation complete à chaque changement).
-- Matthieu
Paul Gaborit <Paul.Gaborit@invalid.invalid> writes:
L'intérêt de la dépendance supplémentaire est de pouvoir gérer les
choses plus finement. On peut imaginer que la production de certains
fichiers sont indépendantes de l'aspect TEST/PROD. Et puis, même si on
oublie le 'clean', ça marchera.
Au passage, si on en est à ajouter des dépendances, une solution est
d'avoir un fichier config.h qui contienne, ou ne contienne pas
#define DEBUG, en remplacement du -DDEBUG.
Si le Makefile est bien foutu, il prendra en compte la dépendance, et
y'aura qu'à modifier le fichier et à faire "make" pour changer de
mode. Bien sûr, ça, c'est si on ne compte pas avoir deux builds
séparés en parallèle pour les deux modes (i.e. si on est pret à payer
le prix d'une recompilation complete à chaque changement).
L'intérêt de la dépendance supplémentaire est de pouvoir gérer les choses plus finement. On peut imaginer que la production de certains fichiers sont indépendantes de l'aspect TEST/PROD. Et puis, même si on oublie le 'clean', ça marchera.
Au passage, si on en est à ajouter des dépendances, une solution est d'avoir un fichier config.h qui contienne, ou ne contienne pas #define DEBUG, en remplacement du -DDEBUG.
Si le Makefile est bien foutu, il prendra en compte la dépendance, et y'aura qu'à modifier le fichier et à faire "make" pour changer de mode. Bien sûr, ça, c'est si on ne compte pas avoir deux builds séparés en parallèle pour les deux modes (i.e. si on est pret à payer le prix d'une recompilation complete à chaque changement).
-- Matthieu
James Kanze
On Oct 15, 2:33 pm, Marc Boyer wrote:
On 2007-10-15, fabrizio wrote:
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 com pilation : 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
À mon avis, il vaut mieux garder les noms des objets en .o, et maintenir les .o dans des répertoires différents. Avec GNU make, on put bien faire quelque chose comme :
prod/%.o : %.c $(CC) $(CFLAGS_PROD) ...
dev/%.o : %.c $(CC) $(CFLAGS_DEV) ...
Mais c'est une extension de GNU make, je crois. (En revanche, étant donné qu'il n'y a pas de norme pour make, et qu'ils varient de toute façon, autant faire se standardiser sur GNU make. C'est un problème de portabilité en moins.)
-- James Kanze (GABI Software) email: 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
On Oct 15, 2:33 pm, Marc Boyer <Marc.Bo...@enseeiht.yahoo.fr.invalid>
wrote:
On 2007-10-15, fabrizio <watch....@stars.mw> wrote:
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 com pilation :
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
À mon avis, il vaut mieux garder les noms des objets en .o, et
maintenir les .o dans des répertoires différents. Avec GNU make,
on put bien faire quelque chose comme :
prod/%.o : %.c
$(CC) $(CFLAGS_PROD) ...
dev/%.o : %.c
$(CC) $(CFLAGS_DEV) ...
Mais c'est une extension de GNU make, je crois. (En revanche,
étant donné qu'il n'y a pas de norme pour make, et qu'ils
varient de toute façon, autant faire se standardiser sur GNU
make. C'est un problème de portabilité en moins.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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
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 com pilation : 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
À mon avis, il vaut mieux garder les noms des objets en .o, et maintenir les .o dans des répertoires différents. Avec GNU make, on put bien faire quelque chose comme :
prod/%.o : %.c $(CC) $(CFLAGS_PROD) ...
dev/%.o : %.c $(CC) $(CFLAGS_DEV) ...
Mais c'est une extension de GNU make, je crois. (En revanche, étant donné qu'il n'y a pas de norme pour make, et qu'ils varient de toute façon, autant faire se standardiser sur GNU make. C'est un problème de portabilité en moins.)
-- James Kanze (GABI Software) email: 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
