Non, je ne me fiche pas du tout de ce qui se passe à la racine de mon projet ... Je tiens a avoir une arborescence qui se tient. 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).
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 Larry Cow . En réponse au message Utiliser Anjuta sans les autotools. É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.