Un IDE C++ sous Linux pour (très) débutant

On Mon, 07 Feb 2005 23:55:25 +0100, bernard tatin
<bernard.tatin@nospam.tele2.fr>:

Je suis de moins en moins convaincu par ce genre de pédagogie. J'ai
tellement été obligé de démerder des gens paumé entre la syntaxe de
make, du préprocesseur, c'est quoi le fichier objet - rien à voir avec
l'instance d'une classe, faut aussi l'expliquer - c'est quoi le
programme...

Je mitoute.
AMHA, il vaut mieux apprendre un truc à la fois. Si tu veux apprendre
l'utilisation d'Emacs, le C++ et la programmation GUI, tu peux, mais
pas en même temps.

--
;-)

xavier wrote:

kanze@gabi-soft.fr a dit le 08/02/2005 11:55:

Fabien LE LEZ wrote:

mal. Y a-t-il encore quelqu'un qui fasse des makefile à la
main ?

Moi ! Typiquement, le projet est assez compliqué, avec des
sources générées (avec des générateurs qu'il faut d'abord
compiler, etc.).

Personnellement, j'utilise des Makefile pour les petits
projets, lorsque les règles par défaut n'ont besoin que d'une
ou deux modifications.

Pour les projets plus importants, j'utilise les autotools
(autoconf, automake, libtool).

Comme j'ai dit, j'ai les makefiles de base (component.mk,
library.mk, etc.). Quand le makefile du projet a plus que deux
ou trois affectations de variable, c'est parce qu'il y a du code
généré automatiquement, au moyen des scripts AWK, etc. Est-ce
que les autotools peuvent traiter ça ?

--
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@gabi-soft.fr writes:

Est-ce que les autotools peuvent traiter ça ?

Ca dépends a quel niveau te te places ...

En gros, tu as autoconf, qui te génère un script qui va faire de la
substitution des formes en @VARIABLES@ dans les fichiers xxx.in (du
répertoire source), et qui crée un fichier xxx (sans le .in, dans le
répertoire de build). En gros, le script généré fait

# calculer la valeur de $VARIABLE
# ...
sed "s/@VARIABLE@/${VARIABLE}/" < xxx.in > xxx

Ça, c'est compatible avec tout, puisque c'est toi qui met ce que tu
veux dedans.

Ensuite, tu as automake, et libtool, qui te génèrent les Makefile.in
qui vont bien. C'est très pratique quand ça s'applique, mais forcément
plus contraignant. Ceci dit, on peut mélanger les macros automake et
les règles de Makefile traditionnelles, donc, ça reste assez flexible.

--
Matthieu

kanze@gabi-soft.fr a dit le 09/02/2005 10:27:

Comme j'ai dit, j'ai les makefiles de base (component.mk,
library.mk, etc.). Quand le makefile du projet a plus que deux
ou trois affectations de variable, c'est parce qu'il y a du code
généré automatiquement, au moyen des scripts AWK, etc. Est-ce
que les autotools peuvent traiter ça ?

J'aurais du exprimer ma position de manière plus claire. Si dans ton
cas, on a un système existant qui fonctionne bien, je ne vois pas de
raison d'en changer. L'intérêt des autotools est, entre autre, qu'il n'y
a pas besoin de créer ce système. La génération des dépendances pour les
fichiers sources, qui est à mon point de vue l'un des points les plus
complexes à gérer, est fait automatiquement par les autotools. L'autre
point fort est bien sûr la portabilité du système de compilation et la
gestion facilitée des tests de portabilité.

Donc, si tu as un système de Makefile qui fonctionne bien, ce n'est sans
doute pas la peine de passer à Automake. Pour ceux qui n'ont rien, il me
semble beaucoup plus facile d'apprendre les bases des autotools que de
se créer à la main un tel système. Lorsque j'ai commencé à écrire des
Makefile, je me souviens avoir passé du temps à tenter de résoudre des
problèmes de dépendances circulaires, et a finalement passer beaucoup
trop de temps dessus.

Pour répondre à ta question, tout ce qui peut être écrit pour des
Makefiles peut être intégré dans les fichiers Makefile.am d'automake. Je
suppose que ta question est sur des cibles du genre :

! something.cpp: something.cpp.in
! $(AWK) -f gen.awk $< > $@

ou

! %.cpp: %.awk
! $(AWK) -f gen.awk $< > $@

Si c'est bien ça, alors la réponse est oui. A priori, ce code peut
apparaître tel quel dans le fichier Makefile.in

Xavier

Matthieu Moy wrote:

kanze@gabi-soft.fr writes:

Est-ce que les autotools peuvent traiter ça ?

Ca dépends a quel niveau te te places ...

En gros, tu as autoconf, qui te génère un script qui va faire
de la substitution des formes en @VARIABLES@ dans les fichiers
xxx.in (du répertoire source), et qui crée un fichier xxx
(sans le .in, dans le répertoire de build). En gros, le script
généré fait

# calculer la valeur de $VARIABLE
# ...
sed "s/@VARIABLE@/${VARIABLE}/" < xxx.in > xxx

Ça, c'est compatible avec tout, puisque c'est toi qui met ce
que tu veux dedans.

C-à-d que ça fait à peu près ce que fait Imake ?

Mais j'imagine que tout l'intérêt, c'est la partie « calculer la
valeur de $VARIABLE », parce que pour me servir de sed, je n'ai
pas besoin d'autre outil.

Dans l'ensemble, je ne suis pas trop convaincu. Grosso modo, ça
t'oblige à lancer tes makes du répertoire où se trouve les
objets, non ? Ou est-ce qu'il génère de façon à ce qu'une simple
option à make (du genre comp=suncc) suffit pour générer
plusieurs variants ? (Le problème de Imake, dans ce que je fais,
c'est qu'il faut régénérer le fichier make chaque fois qu'on
veut une autre configuration. Actuellement, on supporte quatre
compilateurs sous Solaris, deux sous Linux, et un sous Windows.)

--
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

xavier wrote:

kanze@gabi-soft.fr a dit le 09/02/2005 10:27:

Comme j'ai dit, j'ai les makefiles de base (component.mk,
library.mk, etc.). Quand le makefile du projet a plus que
deux ou trois affectations de variable, c'est parce qu'il y
a du code généré automatiquement, au moyen des scripts AWK,
etc. Est-ce que les autotools peuvent traiter ça ?

J'aurais du exprimer ma position de manière plus claire. Si
dans ton cas, on a un système existant qui fonctionne bien, je
ne vois pas de raison d'en changer.

Si la maintenance en serait moins, ça serait une raison. Parce
que quelque soit le système existant, il faut le maintenir. Si
je m'y intéresse un peu, c'est que je suis actuellement en train
de le faire évoluer, de façon à supporter la génération des
plug-ins, et la génération de la documentation au moyen de
Doxygen. Du coup, je me suis rendu compte qu'il avait subit le
« pourrissement des logiciels » classiques ; ce qui était assez
simple et élégant au départ était devenu un monstre des features
et des cas spéciaux.

Alors, l'occation se présente pour le réécrire, en propre. Mais
avant de m'y mettre au sérieux, j'aimerais savoir si ça vaut la
peine. Il y a bien une vingtaine d'homme/heures, peut-être même
plus, et si je peux obtenir ne serait-ce que 95% de sa
fonctionnalité avec un outil existant, qui ne me coûte qu'une
démi-heure d'installation, ça vaut la peine.

L'intérêt des autotools est, entre autre, qu'il n'y a pas
besoin de créer ce système. La génération des dépendances pour
les fichiers sources, qui est à mon point de vue l'un des
points les plus complexes à gérer, est fait automatiquement
par les autotools.

La génération des dépendances des .o/.obj se fait
automatiquement déjà avec make tout seul. Soi systèmatiquement,
à chaque compilation, soi au moyen d'un cible précis,
« depends ». C'est deux lignes dans un des makefile que
j'inclus. Ce n'est donc pas pour ça que je prendrais un outil
externe.

L'autre point fort est bien sûr la portabilité du système de
compilation et la gestion facilitée des tests de portabilité.

J'avais toujours l'impression que les ./configure de GNU (qui se
basent sur des autotools, je crois) soit assez lourd et peu
efficace. Et qu'il ne réglait pas tous les problèmes. (Mais là,
je ne crois pas qu'on puisse lui faire trop de reproches. Je ne
connais pas de système qui s'occuperait automatiquement des
questions de portabilité dans StackTrace, par exemple.)

Donc, si tu as un système de Makefile qui fonctionne bien, ce
n'est sans doute pas la peine de passer à Automake. Pour ceux
qui n'ont rien, il me semble beaucoup plus facile d'apprendre
les bases des autotools que de se créer à la main un tel
système.

Mais alors, la question serait : pourquoi autotools, et non
Imake, ou quelque chose d'autre ? (Je suis bien d'accord qu'un
débuttant ne doit pas avoir à apprendre GNU make au point de
pouvoir écrire des fichiers makes comme je le fais.)

Lorsque j'ai commencé à écrire des Makefile, je me souviens
avoir passé du temps à tenter de résoudre des problèmes de
dépendances circulaires, et a finalement passer beaucoup trop
de temps dessus.

Pour répondre à ta question, tout ce qui peut être écrit pour
des Makefiles peut être intégré dans les fichiers Makefile.am
d'automake. Je suppose que ta question est sur des cibles du
genre :

! something.cpp: something.cpp.in
! $(AWK) -f gen.awk $< > $@

ou

! %.cpp: %.awk
! $(AWK) -f gen.awk $< > $@

Si c'est bien ça, alors la réponse est oui. A priori, ce code
peut apparaître tel quel dans le fichier Makefile.in

C'est à près le premier. Sauf qu'il faut que gen.awk apparaîsse
dans les dépendances -- il est souvent plus volatile que le
fichier qu'il lit.

Mais évidemment, ça ne suffit pas ; il faut que des cibles clean
effacent les fichiers générés, et les cibles export et backup ne
le prenent pas en compte. Pour l'instant, j'ai adopté la
solution facile que tout généré doit se trouver dans un
sous-répertoire dédié, derived, mais j'ai prévu aussi le cas où
on veut ajouter des fichiers à effacer à clean.

--
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@gabi-soft.fr writes:

Mais j'imagine que tout l'intérêt, c'est la partie « calculer la
valeur de $VARIABLE »,

Comment tu as deviné ? ;-)

Ce que tu tappes, c'est un script en /bin/sh, amélioré a coups de
macros m4.

parce que pour me servir de sed, je n'ai pas besoin d'autre outil.

D'ailleurs, autoconf génère un script sed pour la substitution.

Dans l'ensemble, je ne suis pas trop convaincu. Grosso modo, ça
t'oblige à lancer tes makes du répertoire où se trouve les
objets, non ?

Je suis pas sur de comprendre la question, mais la démarche standard,
c'est :

mkdir build-gcc
cd build-gcc
../path/to/sources/configure CC=gcc
make

[...]

mkdir build-suncc
cd build-suncc
../path/to/sources/configure CCÌ --with-mon-option=foobar
make

(Chez moi, /path/to/sources est sur un disque avec quotas et
sauvegardes, et le répertoire de build est sur mon disque local sans
quotas ni sauvegardes.)

Ou est-ce qu'il génère de façon à ce qu'une simple option à make (du
genre comp=suncc) suffit pour générer plusieurs variants ?

Ca me parait bien dangereux : Tu vas te retrouver avec un répertoire
contenant des objets GCC et d'autres en SUN CC. Ou alors, c'est "make
clean && make" à chaque fois ...

Avec automake, je ne crois pas que ça soit faisable, en autoconf,
encore une fois, c'est toi qui écrit le Makefile, tu fais comme tu
veux.

(Le problème de Imake, dans ce que je fais, c'est qu'il faut
régénérer le fichier make chaque fois qu'on veut une autre
configuration. Actuellement, on supporte quatre compilateurs sous
Solaris, deux sous Linux, et un sous Windows.)

La portabilité est l'un des objectifs principaux des autotools, mais
perso, je n'ai pas eu l'occasion de me servir de cet aspect là, donc,
je ne peut pas en dire bcp plus ...

--
Matthieu

kanze@gabi-soft.fr a dit le 09/02/2005 14:56:

J'avais toujours l'impression que les ./configure de GNU (qui se
basent sur des autotools, je crois) soit assez lourd et peu
efficace. Et qu'il ne réglait pas tous les problèmes. (Mais là,
je ne crois pas qu'on puisse lui faire trop de reproches. Je ne
connais pas de système qui s'occuperait automatiquement des
questions de portabilité dans StackTrace, par exemple.)

En fait, le script "configure" est crée par autoconf. Le principe est de
détecter un maximum d'information sur le système en aillant le moins de
dépendance possible.

De ce fait, le système est assez "lourd", dans le sens où il doit
déterminer un grand nombre de paramètres (emplacement et type du
compilateur C, awk, sed, ...). En pratique, pendant le dévelloppement,
il est assez rare de devoir lancer "configure". En fait, ça n'est
nécéssaire que lorsque le fichier configure.in dont il est issu a été
modifié.

Mais alors, la question serait : pourquoi autotools, et non
Imake, ou quelque chose d'autre ? (Je suis bien d'accord qu'un
débuttant ne doit pas avoir à apprendre GNU make au point de
pouvoir écrire des fichiers makes comme je le fais.)

Je ne connait pas suffisament Imake pour te donner de raison précise.
Lorsque j'ai décidé d'abandonner make seul, j'ai commencé par étudier
les autotools et je me suis arreté là. Je n'ais pour le moment pas eu de
besoin de reconsidérer ce choix.

C'est à près le premier. Sauf qu'il faut que gen.awk apparaîsse
dans les dépendances -- il est souvent plus volatile que le
fichier qu'il lit.

Ce qui n'est pas un problème.

Mais évidemment, ça ne suffit pas ; il faut que des cibles clean
effacent les fichiers générés, et les cibles export et backup ne
le prenent pas en compte.

Pour ce genre de choses, tu as des hooks disponibles dans le système
Automake qui sont adaptées.

Dans le langage des autotools, je pense qu'on peut traduire "export" par
"install" et "backup" par "dist". Ces deux types de cibles sont gérées
par automake.

Soit un projet "toto" contenant les fichiers "main.cpp", "functions.in"
et "gen.awk". Si tu écris un Makefile.am de ce type :

! toto_SOURCES = main.cpp
! EXTRA_toto_SOURCES = functions.cpp.in gen.awk
! toto_LDADD = functions.o
! CLEANFILES = functions.cpp
!
! %.cpp: %.cpp.in gen.awk
! $(AWK) -f gen.awk $< $@

Tu devrais obtenir un comportement assez proche de ce que tu décris.

xavier

xavier wrote:

kanze@gabi-soft.fr a dit le 09/02/2005 14:56:

J'avais toujours l'impression que les ./configure de GNU
(qui se basent sur des autotools, je crois) soit assez lourd
et peu efficace. Et qu'il ne réglait pas tous les
problèmes. (Mais là, je ne crois pas qu'on puisse lui faire
trop de reproches. Je ne connais pas de système qui
s'occuperait automatiquement des questions de portabilité
dans StackTrace, par exemple.)

En fait, le script "configure" est crée par autoconf. Le
principe est de détecter un maximum d'information sur le
système en aillant le moins de dépendance possible.

De ce fait, le système est assez "lourd", dans le sens où il
doit déterminer un grand nombre de paramètres (emplacement et
type du compilateur C, awk, sed, ...). En pratique, pendant le
dévelloppement, il est assez rare de devoir lancer
"configure". En fait, ça n'est nécéssaire que lorsque le
fichier configure.in dont il est issu a été modifié.

Tout à fait. En fait, le problème, c'est qu'il y a en fait
plusieurs problèmes distincts qui se résument par le même but :
créer un fichier make. J'avais régardé configure, mais j'ai
trouvé qu'il ne résolvait pas mon problème, où au moins, il ne
résolvait pas ma formulation du problème. Pour les distributions
des logiciels libres typiques, en revanche, c'est difficile à
faire mieux, mais pour l'instant, je suis plus concerné par le
développement de plusieurs versions (compilateur, etc.) en
parallel. Sans doute s'il m'arrive à vouloir faire une vraie
distribution, je le régarderai de nouveau, et de plus près.

Mais alors, la question serait : pourquoi autotools, et non
Imake, ou quelque chose d'autre ? (Je suis bien d'accord
qu'un débuttant ne doit pas avoir à apprendre GNU make au
point de pouvoir écrire des fichiers makes comme je le
fais.)

Je ne connait pas suffisament Imake pour te donner de raison
précise. Lorsque j'ai décidé d'abandonner make seul, j'ai
commencé par étudier les autotools et je me suis arreté là. Je
n'ais pour le moment pas eu de besoin de reconsidérer ce
choix.

Imake, ce n'est pas le Pérou non plus. Aussi, il se peut qu'il
résoud encore un problème différent -- l'idée d'Imake, dans la
base, c'est de créer un fichier make en fusionnant des
informations de deux sources : un fichier Imakefile fourni par
l'auteur du logiciel, qui précise les sources, les dépendences,
etc., et un template, présent sur la machine cible, qui précise
tout ce qui dépend du cible.

On s'en sert ici pour la gestion de plusieurs instantiations des
bibliothèques, mais à mon avis, ce n'est pas l'outil qui
convient (pour ça -- une fois de plus, il fait très bien ce pour
lequel il a été conçu). Dans la pratique, il faut maintenir une
arborescence de source propre à chaque version, ou refaire un
make clean, puis Imake, chaque fois qu'on veut travailler avec
un autre compilateur, etc.

C'est à près le premier. Sauf qu'il faut que gen.awk
apparaîsse dans les dépendances -- il est souvent plus
volatile que le fichier qu'il lit.

Ce qui n'est pas un problème.

Je m'en doutais un peu.

Mais évidemment, ça ne suffit pas ; il faut que des cibles
clean effacent les fichiers générés, et les cibles export et
backup ne le prenent pas en compte.

Pour ce genre de choses, tu as des hooks disponibles dans le
système Automake qui sont adaptées.

Dans le langage des autotools, je pense qu'on peut traduire
"export" par "install" et "backup" par "dist". Ces deux types
de cibles sont gérées par automake.

Pas tout à fait. J'ai bien un cible install, qui correspond à
peu près à l'install des autotools. En fait, export
correspondrait de très près à dist, je crois ; backup en est une
variante à quelques détails près (la destination, mais aussi il
sauve aussi une ou deux choses de la configuration actuelle en
plus).

Soit un projet "toto" contenant les fichiers "main.cpp",
"functions.in" et "gen.awk". Si tu écris un Makefile.am de ce
type :

! toto_SOURCES = main.cpp
! EXTRA_toto_SOURCES = functions.cpp.in gen.awk
! toto_LDADD = functions.o
! CLEANFILES = functions.cpp

! %.cpp: %.cpp.in gen.awk
! $(AWK) -f gen.awk $< $@

Tu devrais obtenir un comportement assez proche de ce que tu décris.

Ça a effectivement l'air intéressant. J'y jetterai un coup
d'oeil à l'occasion. (Une autre chose qui m'est important, c'est
qu'à l'encontre de beaucoup de monde, je n'utilise pas de
#ifdef, mais que je gère les dépendances au moyen des
sous-répertoires. Je doute que ce soit un problème, mais on n'en
sait jamais.)

--
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@gabi-soft.fr wrote:

Tout à fait. En fait, le problème, c'est qu'il y a en fait
plusieurs problèmes distincts qui se résument par le même but :
créer un fichier make. J'avais régardé configure, mais j'ai
trouvé qu'il ne résolvait pas mon problème, où au moins, il ne
résolvait pas ma formulation du problème. Pour les distributions
des logiciels libres typiques, en revanche, c'est difficile à
faire mieux, mais pour l'instant, je suis plus concerné par le
développement de plusieurs versions (compilateur, etc.) en
parallel. Sans doute s'il m'arrive à vouloir faire une vraie
distribution, je le régarderai de nouveau, et de plus près.

N'est-ce pas aussi le but de boost ? As-tu regardé leur outil (bjam) ?

--
Loïc