Premièrement je profite de ce journal pour dire que je trouve les autotools pratiquement inutiles ...
On peut tout faire avec un makefile et je trouve ca beaucoup plus propre. On pourrait imaginer le makefile suivant:
CC=gcc
CFLAGS=
LIBS=
CC=gcc
CFLAGS=-g -Wall -I/usr/include/libxml2
LIBS=-lxml2
help:
@echo "Vous devez d'abord lancer la cible 'configure' par la commande 'make configure' pour configurer l'application"
@echo "Ensuite, pour compiler le projet, il faut lancer la cible 'all' avec 'make all'."
configure:
@# Script demandant à l'utilisateur ce qu'il veut
@# Par exemple suite de questions réponses
@touch configured
all: configured mon-app
mon-app: main.o
$(CC) $(LIBS) main.o -o $@
main.o: src/main.c
$(CC) -c $(CFLAGS) src/main.c -o $@
Je ne vois pas ce qui est difficile dans ce makefile.
Donc, ma question est: Comment utiliser un makefile tel que celui ci avec Anjuta en conservant toutes ses fonctions (débogage notamment) ?
Avez vous des solutions ?
Sinon, je n'ai pas trop envie d'utiliser les autotools pour deux raisons:
- Ce n'est vraiment pas évident
- Cela nécessite quantité de fichiers qui mettent en désordre le dossier de mon projet.
Forum Programmation.c Utiliser Anjuta sans les autotools
24
nov.
2004
# Makefile en désordre.
Posté par Mildred (site web personnel) . Évalué à 0.
[^] # Re: Makefile en désordre.
Posté par Mildred (site web personnel) . Évalué à 1.
# Pinaillage
Posté par Larry Cow . Évalué à 10.
En fait, cet aspect des choses n'est qu'un petit plus "pratique" qui est rendu possible par les scripts de configuration. Le but initial, c'est de déterminer la configuration de la machine de manière automatique. Il suffit de zieuter l'éxecution d'un script configure d'autotools pour voir qu'il ne se limite pas vraiment à prendre en compte les --with-killer-but-nevertheless-unstable-feature qui trainent sur sa ligne de commande. Il teste aussi et surtout l'existence et/ou les prototypes de nombreuses fonctions (plus ou moins) standard. Ainsi, on peut s'assurer que le programme pourra tourner y compris sur des archis différentes (lire éventuellement "merdique").
Alors effectivement, si ton programme est dédié à un ensemble relativement limité d'architectures (genre uniquement des linux de versions récentes), tu peux te permettre de faire ce genre de choses, et effectivement tu n'auras pas besoin d'un Makefile plus compliqué. Au pire, tu auras à demander à l'utilisateur le racine de X et deux-choses un peu siouxes.
Si tu commences à cibler des plateformes plus variées, telles de vieilles versions de divers unices, des unices propriétaires et peu respectueux des standards (j'ai pas dit HPUX! me regardez pas comme ça!), voire des pas-unix-du-tout (mingw, ou dans une moindre mesure cygwin ou beos), tu risques fort de trouver ton makefile "pas compliqué" nettement plus tordu et difficile à maintenir. Tu commenceras à avoir des choses comme:
cat > test.c << EOF
#include <header-precolombien.h>
void main {};
EOF
gcc test.c
if $COMPILATION_FOIRED then echo "Error: you need to install libdeluge-devel to compile my happy program, please come back later.
Rajoute ce genre de choses pour 25 librairies et fonctions tordues. A ce moment-là, tu en viendras peut-être à te dire que les autotools, pour compliqués et contraignant qu'ils soient, pourraient bien te simplifier la vie en fin de compte.
Bien entendu, je suis complètement off-topic et je ne t'aide absolument pas, mais je ne pouvais pas laisser passer l'idée que les autotools ne servent à rien. Qu'ils soient lourds, imparfaits, j'adhère complètement. Mais leur objectif est louable, et relativement bien rempli.
[^] # Re: Pinaillage
Posté par Bruno Muller . Évalué à 3.
[^] # Re: Pinaillage
Posté par Christophe Fergeau . Évalué à 1.
« - Cela nécessite quantité de fichiers qui mettent en désordre le dossier de mon projet. » Y a pas besoin de tant de fichiers que ça, il faut un configure.ac, un Makefile.am par répertoire et en fait ça doit pouvoir être suffisant si tu ignores les plaintes des autotools au sujet de fichiers manquants (README, ChangeLog, ...). Ensuite effectivement les autotools génèrent pas mal de fichiers, et ça peut être un peu perturbant au début. Mais avec l'habitude, tu sais quels fichiers sont utiles et quels fichiers ne le sont pas, et puis tes sources sont dans un sous répertoire src/ de toute façon, donc tu t'en fiche de ce qu'il se passe à la racine de ton projet ;)
[^] # Re: Pinaillage
Posté par Mildred (site web personnel) . Évalué à 2.
Si ce n'était que moi, je ne mettrais même pas les sources dans src. Il me parait évident que le dosier de projet contient des sources C. Pas besoin de les séparer (à part pour les préserver de la polution autotools).
Ensuite, je remarque que ca ne fonctionne pas très bien. Avec Anjuta, et un nouveau projet, pas moyen de compiler un simple HelloWorld.
Si je dois les utiliser j'aimmerais bien avoir une doc qui me dise exavtement à quoi cela sert en détail. Pourquoi avoir choisi cette solution plutot qu'une autre ? Qu'est ce qu'est une macro ? ...
Et je n'ai pas encore trouvé.
Donc pour le moment, je garde mon Makefile.
Sinon, j'ai réussi comment on fait avec Anjuta pour ne pas utiliser les autotools. Tu met ton makefile dans le dossier src à la racine du projet. Ce makefile doit générer un fichier qui correspond au nom du projet dans ce dossier src.
Et ca marche mieux que les autotools. Et je trouve ca plus facile.
[^] # Re: Pinaillage
Posté par Larry Cow . Évalué à 3.
Et justement, avoir les sources dans un sous-répertoire, ça se tient tout à fait. Ca permet notamment de ne pas mettre /doc, /data et autres données diverses dans des sous-répertoires des sources (ce qui n'est pas excessivement logique, tu en conviendras). Parce que bon, mettre sur un pied d'égalité /libmyengine et /libmyparser sur un pied d'égalité avec /images et /tools, c'est assez discutable.
Sans même parler du cas ou ton projet est multilangage (python, pyrex et C, par exemple) et ou il devient vital de séparer nettement les différents types de sources.
Ensuite, je remarque que ca ne fonctionne pas très bien. Avec Anjuta, et un nouveau projet, pas moyen de compiler un simple HelloWorld.
Comme je l'ai déjà dit, je n'y connais pas grand chose à Anjuta, donc je ne peux pas tellement t'aider. Mais si c'est réellement lui qui prétend gérer les autotools et le le fait pas, il serait plus logique de s'en prendre à lui, plutôt qu'à ces derniers.
Maintenant, si en connaissance de cause tu trouves les autoconf et automake lourdingues, c'est un choix qui se respecte, et libre à toi de faire le script configure qui va bien à la main. Mais si ce qui te pose problème est que, justement, tu ne connais pas ces outils, il est un peu rapide de conclure qu'ils ne servent à rien.
Si je dois les utiliser j'aimmerais bien avoir une doc qui me dise exavtement à quoi cela sert en détail.
Les autotools servent à simplifier l'écriture et la gestion des scripts configure et Makefile. J'ai expliqué plus haut l'utilité des scripts configure. Maintenant pour qu'ils soient réellement utiles, il faut qu'ils ne se limitent pas à se plaindre en cas de problème: par exemple, s'il manque une fonction simple qui existe sur l'immense majorité des plateformes, le configure a pour charge de l'implémenter vite fait dans le projet. Ainsi, si il manque une version de malloc qui initialise le bloc alloué à zéro, il est tout à fait envisageable de rajouter la-dite fonction dans un fichier C à part, fichier qui sera compilé et linké avec le reste du projet.
Dans le cas où la fonction n'est pas facilement rajoutable, ou que le test concerné vise une fonctionnalités spéciale de la plateforme (présence de /dev/urandom, de /proc ou que sais-je), il est important que le configure informe le reste du projet de la non-existence en question. Pour cela, quoi de plus simple qu'un #define? On rajoute donc une floppée de #define PENTIUM_BUG, #define NO_DEV_RANDOM et autres dans un header à part: par exemple config.h.
Reste au final à expliquer à tes Fairefichier (qui ne sont pas forcément au courant) qu'ils doivent linker contre telle ou telle librairie plutôt qu'une autre. Pour ce faire, il faut donc que le script configure soit capable de modifier tes Makefiles (ou du moins un fichier inclus par tes Makefiles, dans le cas où le make local le permet).
En bref, une véritable usine à gaz est nécessaire pour parvenir à un résultat acceptable. Car, comme tu t'en doute, les tests de ton configure (en shell, donc) utilisent souvent des programmes qui ne fonctionnent pas partout pareil (versions différentes de test, de bc, de sed, de grep, ...).
Si on était tordu, on créerait un premier script d'audit, preconfigure par exemple, testerait les commandes shell disponibles et qui construirait un configure fonctionnel sur la plateforme courante. Le configure créerait ensuite le config.h et les Makefile.inc qui vont bien. Simple non? ;)
Pour pallier à ce douloureux problème, on ajoute une contrainte supplémentaire au système: un moteur de macros à part, qui permet d'exprimer les tests du configure de manière portable, sous réserve que le moteur soit disponible. L'interpréteur de macro choisi, c'est m4. Ainsi, au lieu de devoir dépendre de l'existence d'une multitude de commandes shell d'origine diverses, on n'a plus à dépendre que d'un seul outil/langage, simple et portable.
On pourrait donc se débrouiller uniquement avec m4, et écrire nos configure entièrement à la main. Seulement, les autotools nous apportent une aide supplémentaire: ils nous fournissent une floppée de tests (macros) m4 tous faits, pour répondre aux questions les plus courantes Ainsi, on peut savoir simplement si printf fonctionne comme prévu, quel est nom du compilateur (cc, gcc, icc, ...), quel flag est nécessaire pour la production de librairies dynamiques (.so) et quelle est l'extension des executables. Ce genre de choses.
Pourquoi avoir choisi cette solution plutot qu'une autre ?
Ca dépend de l'autre solution que tu proposes. Les choix qui font des autotools ce qu'ils sont viennent des possibilités de l'époque. Il fallait quelquechose qui soit capable de répondre "tout seul" aux cas simples, mais qui puisse être étendu aux cas compliqués.
On peut faire de nombreux reproches aux autotools (et les gens concernés ne s'en privent pas, tu peux en être assuré). Par exemple le bordel qui suit les gros changements de versions d'autoconf/automake. Mais c'est la seule solution raisonnable à l'heure actuelle: les autres sont soit trop lourdes, soit présentes par défaut sur trop peu de plateformes, soit les deux (exemple: Ant, Jam, ...).
En outre, les solutions alternatives ont comme particularité de remplacer le couple configure/makefile, ce qui perturbe les habitués de make.
Qu'est ce qu'est une macro ?
Je devrais t'avoir un peu éclairci à ce sujet, j'espère.
[^] # Re: Pinaillage
Posté par Mildred (site web personnel) . Évalué à 1.
Sachant que je ne toens pas a passer 3 mois a apprendre les autotools et à configurer mon projet.
peut être que ca ne compile pas partout, ca navertit pas des dépendances comme le ./configure ou ca re recrée pas la fonction malloc() mais au moins, c'est plus facile à gérer.
Comme je l'ai dit plus bas, je compte sur gcc pour avertir si une lib n'est pas présente, et je trouve ca personellement plus pratique.
Ensuite, je me demande pourquoi:
- on ne ferait pas "make configure" à la place de "./configure"
- "./configure" ne nous dit pas ce qui manque
- ne pas fusionner les fichiers de configurations. Ou les ranger dans un répertoire ".autotools" dans chaque dossier.
PS: la première version de ce post a été perdur pour cause de plantage.
[^] # Re: Pinaillage
Posté par Larry Cow . Évalué à 2.
Pas de problème, d'autant que fondamentalement les autotools peuvent être inutiles (notamment si ton projet est limité à quelques fichiers source et à un nombre restreint d'utilisateurs).
mais je me demande très serieusement: Qu'est ce que les autotools peivent m'apporter que mon simple Makefile ne peux pas faire ?
Plein de choses, cf. ce qu'on dit depuis ton article initial. Plein de choses qui ne te sont pas forcément utiles à toi là tout de suite maintenant, mais plein de choses utiles à beaucoup de développeurs (la majorité, en fait).
A commencer par toute la phase de "configuration", que ta cible configure ne fait qu'approcher.
Sachant que je ne toens pas a passer 3 mois a apprendre les autotools et à configurer mon projet.
Il est clair que passer trois mois sur le sujet ne serait pas raisonnable.
peut être que ca ne compile pas partout, ca navertit pas des dépendances comme le ./configure ou ca re recrée pas la fonction malloc() mais au moins, c'est plus facile à gérer.
Tu vois que tu as une petite idée quand même des avantages des autotools ;)
Mais bon, ce n'est pas tellement "plus facile" que ça à gérer, puisque ça pose problème à ton Anjuta.
Comme je l'ai dit plus bas, je compte sur gcc pour avertir si une lib n'est pas présente, et je trouve ca personellement plus pratique.
Pour toi, oui. Pour tes utilisateurs potentiels, c'est beaucoup moins pratique (ils ne sont pas forcément sensés savoir quelles bibliothèques tu utilise).
Ensuite, je me demande pourquoi:
- on ne ferait pas "make configure" à la place de "./configure"
Parce que ce n'est pas le boulot de make. Le boulot de make, c'est de compiler un programme en s'assurant que seul ce qui est nécessaire sera compilé. Comme je te l'ai expliqué quelques messages plus haut, le configure a un but beaucoup large que ce que fait ton make configure. Ton make configure serait bien embêté s'il devait faire le boulot du configure. (je te laisse réflechir à un Makefile qui aurait pour tâche de générer les Makefiles de ton projet. Ca se fait, mais c'est pas franchement recommandable).
- "./configure" ne nous dit pas ce qui manque
Alors là, je proteste violemment. Je teste sur le premier truc qui me passe sous la main (une applet Gnome, sachant que je n'ai pas les librairies qui vont bien sur ma machine) et:
Je sais pas ce qu'il te faut de plus :)
- ne pas fusionner les fichiers de configurations. Ou les ranger dans un répertoire ".autotools" dans chaque dossier.
On ne fusionne pas les fichiers de configuration justement parce que le but c'est de faire simple. On pourrait probablement décider de remplacer tous les fichiers d'autoconf et automake par un gros machin binaire illisible, mais ça n'est pas le but. De même qu'on pourrait décider de mettre tout le source dans un seul fichier, pour éviter de faire du bazar dans /src. Pourtant, étrangement, les gens semblent chercher à faire l'inverse. Maintenabilité, tout ça...
En outre, le fait d'avoir les répertoires "pointés" cachés, ce n'est qu'une convention unixienne qui n'est pas présente sur toutes les archis couvertes par les autotools, si je ne dis pas de conneries.
PS: la première version de ce post a été perdur pour cause de plantage.
C'est la saison \o/
[^] # Re: Pinaillage
Posté par Mildred (site web personnel) . Évalué à 1.
Et lorsque j'execute mon makefile, GCC (enfin le linker) me dit bien:
Mais passons ...
Sinon, on est pas obligé de mettre les fichiers de config dans ".autotools" mais dans "autotools".
Sinon, je fais un grand shema avec OpenOffice pour comprendre comment ca fonctionne. j'ai peut que cela nécessite plus de configuration qu'un simple Makefile car j'ai l'impression qu'on doit mettre la liste de toutes les sources dans le Makefile.am, non (variable monprog_SOURCES).
# Alternative à make
Posté par plusplus . Évalué à 4.
# Mouais
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
1) les dépendances
2) la compilation dans un répertoire séparé
3) la cible "install"
4) ...
Au fur et a mesure de l'évolution du truc, tu vas vouloir tester la version du compilo, la disponibilité d'un fichier d'en-tête, ... et tu vas écrire des bouts de scripts qui feront ça automatiquement.
Au bout d'un moment, tu auras réécrit les autotools, et tu sera hyper content, mais tu auras perdu beaucoup de temps !
[^] # Re: Mouais
Posté par Mildred (site web personnel) . Évalué à 1.
2- Tu peux compiler dans un répertoire séparé:
gcc src/source.c -o dist/source
3- La cible install est très facile à faire. Il sagit juste de copier des fichiers
4- ...
je ne pense pas que je réécrirais les autotools, trop compliqué a mon goût. Je trouve que gérer un Makefile est plus simple que gérer les autotools.
De plus je ne fais pas bien confiance aux outils pour déterminer tout seul les dépendances de mon code. D'autant qu'il y a une grande partie du code que je ne maitrise pas.
PS: Firefox ayant planté (ca arive) la première version de ce post à été perdue.
[^] # Re: Mouais
Posté par Larry Cow . Évalué à 3.
Ok. Soit l'erreur (réelle) suivante:
postproc/libswscale.a(rgb2rgb.o)(.text+0x62b9): In function `rgb24toyv12':
: undefined reference to `w1111'
Tu me suggères quoi comme librairie à installer?
Bon ok, j'avoue, j'ai triché. Il s'agit en fait d'un programme autotoolifié (MPlayer 0.93 patché de partout pour des besoins divers). N'empêche que l'erreur de gcc est totalement insuffisante pour déterminer le soft à installer. Surtout avec un nom de symbole manquant aussi peu parlant.
Plus facile que le ./configure ou on voit des centaines de lignes défiler avec un yes ou un no. Lorsque ca ne marche pas, on installe ce qui est marqué sur les lignes avec no en espérant que ca marchera ...
Faudrait voir à apprendre à se servir de configure avant de décréter qu'il ne sert à rien. Un configure bien fait (ceux d'autoconf en particulier) s'arrête lorsqu'il tombe sur une dépendance manquante critique, et il te le signale bien violemment. Aller te taper la liste des yes/no pour savoir ce qui a bien pu merder, c'est un petit peu vain: si ta compilation foire malgré un configure qui termine avec succès, c'est que l'auteur du programme a raté quelque-chose, pas qu'il manque un truc à ton système.
2- Tu peux compiler dans un répertoire séparé:
gcc src/source.c -o dist/source
Le but de ce genre de manipulation étant quand même de permettre à l'utilisateur de compiler son source dans le répertoire de son choix (typiquement s'il n'a pas les droits en écriture sur les sources). Par exemple:
cd ~/src/killerprogram/
/mnt/cdrom/src/killerprogram-0.1/configure
make
Au terme de cette configuration/compilation, rien n'aura été écrit dans le répertoires des sources, et le répertoire de compilation est donc autonome. Tes makefiles sont loin de permettre ce genre de choses facilement.
3- La cible install est très facile à faire. Il sagit juste de copier des fichiers
Eventuellement il faut déterminer l'endroit ou les copier, mettre à jour un uninstall.sh, etc...
je ne pense pas que je réécrirais les autotools, trop compliqué a mon goût. Je trouve que gérer un Makefile est plus simple que gérer les autotools.
C'est évident, et personne ne remet ça en cause. Ce qu'on dit, simplement, c'est qu'un Makefile ne peut pas être comparé à un couple configure/makefile comme tu le fais, et qu'autotools est une aide formidable pour gérer le couple configure/makefile.
De plus je ne fais pas bien confiance aux outils pour déterminer tout seul les dépendances de mon code.
Et tu fais confiance au compilateur pour écrire ton binaire? Tu es vraiment pas méfiant ;)
Sarcasme mis à part, si tu ne fais pas confiance aux autotools pour gérer configure/makefile, j'ai du mal à concevoir que tu puisse faire confiance à Anjuta pour gérer ton projet.
M'enfin ce que j'en dis...
D'autant qu'il y a une grande partie du code que je ne maitrise pas.
Raison de plus pour faire confiance aux outils, alors, BdM! :)
[^] # Re: Mouais
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
2- Comment fait-tu
mkdir build-option1
cd build-option1
../configure --with-option1
make
cd ..
mkdir build-option2
cd build-option2
../configure --with-option2
make
?
3- Oui, il suffit de copier les fichiers, mais il faut savoir quels fichiers, et dans quel répertoire les installer. Donc, tu vas avoir un truc du style
make prefix=$HOME/usr config
et il va falloir gérer ça.
4- Par exemple, génération des tags avec etags/ctags, gestion des bibliothèque statiques ou dynamiques par portion du projet, "make dist" qui te fait un .tar.gz avec juste les bons fichiers, ...
Bref, même moi qui ne connais pas très bien les autotools, je vois assez clairement que tu critiques quelque chose que tu ne connais pas. J'insiste : tu passes à coté de quelque chose (il y a d'autres alternatives aux autotools par contre), mais bon, tu fais ce que tu veux, hein ;-)
[^] # Re: Mouais
Posté par Mildred (site web personnel) . Évalué à 2.
Un simple Makefile est plus acessible même si il permet de faire moins de choses ...
Sinon, pour la compilation dans un autre dossier, je ne conaissait même pas ... merci.
Comme je l'ai dit plus hait, je fais un shema complet sur les autotools à l'aide de la page http://igm.univ-mlv.fr/~dr/XPOSE/Breugnot/(...)
[^] # Re: Mouais
Posté par Larry Cow . Évalué à 2.
Sinon on peut aussi faire un gcc *.c, hein ;)
[^] # Re: Mouais
Posté par Christophe Fergeau . Évalué à 2.
Un autre truc que font les autotools (enfin libtool, personnellement je l'inclue dans les autotools, les avis varieront peut être) c'est de te permettre de générer facilement des lib statiques ou partagées, et ce quelle que soit la plateforme (unix proprios, windows, ...)
# Linker: bibliothèque statique
Posté par Mildred (site web personnel) . Évalué à 1.
J'ai réussi à compiler un petit HelloWorld, et même à utiliser des bibliothèques dynamiques (à l'aide d'Ajunta, je ne saurais pas faire sinon) mais je n'ai pas trouvé comment on pouvait compiler avec une bibliothèque statique.
Sinon, j'aimmerais bien savoir comment on fait pour indiquer aux autotools qu'un fichier a besoin de bibliothèques ?
C'est un peu de que je reproche aux autotools: c'est que les choses les plus simples (compiler avec une bibliothèque statique) devient très compliqué.
Mais je suppose qu'une fois qu'on sait faire ca permet d'aller plus vite. Mais ce n'est pas très évident.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.