Désolée si j'ai laissé entandre que je trouvais les autotools inutiles.
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:
configure: error: Library requirements (libgnomeui-2.0 >= 2.0.0
libgnome-2.0 >= 2.0.0
gtk+-2.0 >= 2.4.0
libglade-2.0 >= 2.0.0
gconf-2.0 >= 1.1.11) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them.
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.
[^] # Re: Pinaillage
Posté par Larry Cow . En réponse au message Utiliser Anjuta sans les autotools. É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/