Autoconf/Automake... la relève ?

Posté par  (site web personnel) . Modéré par Fabien Penso.
Étiquettes : aucune
0
23
juin
2003
GNU
Pour distribuer des sources, jusqu'à présent, on n'a pas fait mieux que le couple autoconf/automake. Oui... mais non, telle est la thèse défendue par Andrew McCall dans un editorial sur Freshmeat.

On peut au moins dire qu'il n'a pas froid aux yeux pour s'attaquer à un tel monument. L'auteur nous raconte l'histoire de Joe et de son rude combat pour pouvoir compiler les sources d'un package fraichement téléchargé et de Jane qui cherche à utiliser autoconf/automake pour distribuer son application.

Deux solutions sont proposées : Cons et SCons basés respectivement sur Perl et Python.

Aller plus loin

  • # Ant

    Posté par  (site web personnel) . Évalué à 2.

    Et pourquoi pas un ant-like ?

    L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: Ant

      Posté par  . Évalué à 5.

      Parce qu'on a pas forcement un JRE sous la main, alors que perl est plus courant.

      • [^] # Re: Ant

        Posté par  . Évalué à -1.

        J'ai un JRE, mais j'ai pas perl

      • [^] # Re: Ant

        Posté par  (site web personnel) . Évalué à 7.

        Quand je dis ant je parle plus du format de fichier xml. Et rien n'empèche de faire un ant en perl.

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

      • [^] # Re: Ant

        Posté par  . Évalué à 3.

        De plus on peut compiler ant avec gcj, ou la récupérer ici: http://sources.redhat.com/rhug/

      • [^] # Re: Ant

        Posté par  (site web personnel) . Évalué à 0.

        Perl dans TOUTES les distributions linux, c'est de la vente liée,

        C'EST INTERDIT EN FRANCE !!!!!!

        • [^] # Re: Ant

          Posté par  . Évalué à 3.

          Oui, de la vente gratuite.... ;-) et ca change tout !

        • [^] # Re: Ant

          Posté par  . Évalué à 2.

          > Perl dans TOUTES les distributions linux, c'est de la vente liée

          Mouaif... moi il s'était installé comme dépendance de frozen-bubble je crois... Bon d'accord, ceci dit, xfree aussi.

        • [^] # Re: Ant

          Posté par  . Évalué à 1.

          On est obligé d'acheter un ordinateur pour pouvoir faire tourner linux
          C'est de la vente lié ?



          (-1)

          • [^] # Re: Ant

            Posté par  . Évalué à 1.

            T'es pas obligé de faire tourner linux.
            T'as le droit de te contenter de le lire.

    • [^] # Re: Ant

      Posté par  (Mastodon) . Évalué à 2.

      Ça dépend, ça marche avec les quelques JVM libres et/ou GCJ ?

    • [^] # Re: Ant

      Posté par  . Évalué à 1.

      Les fichiers d'Ant me semblent peu lisibles (le XML n'a pas été conçu pour être lu par des êtres humains, mais par des machines), et je crois qu'on est assez limité quand aux commandes qu'on peut lui faire exécuter (alors qu'on peut mettre quelques lignes de shell dans un Makefile).

      • [^] # Re: Ant

        Posté par  (site web personnel) . Évalué à 1.

        Ah non c'est très lisible je trouve et tu peux aussi y mettre du script shell mais c'est MAL !!! En effet, si tu veux un truc portable tu utilises les actions proposées et c'est tout.

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

      • [^] # Re: Ant

        Posté par  (site web personnel) . Évalué à 2.

        Pour les commandes à executer, c'est limité au sens ou tu peux difficilement jouer de toutes la puissance des wildcards, substitutions, commandes shell de gourou, mais tu as une bibliothèque d'actions prédéfinies intéressantes, et tu peux en rajouter. Par exemple, pour une arborescence de fichier Java à compiler, rien à faire, et en plus, ant et javac tournent dans le même processus, donc, pas besoin de relancer de JVM, et ça va vite. Par contre, pour des compilations censées être rapides, le temps de lancement d'ant est assez décourrageant. (Genre, pour dire machin is up to date, c'est long ...)

        • [^] # Re: Ant

          Posté par  (site web personnel) . Évalué à 1.

          sinon faut remarquer que' un makefile transposé en ant fait une fichier de plus petite taille et plus simple

  • # Re: Autoconf/Automake... la relève ?

    Posté par  (site web personnel) . Évalué à 10.

    Y'a quand même un peu de mauvaise foi quand le configure de Joe lui demande de mettre à jour autoconf et automake. Si le configure a été fait avec les pieds, ce n'est pas vraiment la faute d'autofuck. Par contre pour la doc, 100% d'accord, c'est vraiment ce qu'on fait de pire. Quasiment aucun exemple simple, peu de détails interessants, des docs cloisonnées entre autoconf et automake. Heureusement qu'il y a le autobook http://sources.redhat.com/autobook/ mais il commence à vieillir un peu. Il aurait aussi pu parler de libtool. Aaaaah libtool, que du bonheur.

    • [^] # libtool

      Posté par  . Évalué à 3.

      C'est clair libtool est l'ami du packageur tout comme ses potes auto{make,conf} ... Le gars qui a créé ces trucs des fois on aurait envie de le pendre quand on fait des packages ... grrr. Même xmkmf est préférable des fois :)

      • [^] # Re: libtool

        Posté par  . Évalué à 2.

        Fait une librairie partagée qui doit tourner sous déférence Unix. Là tu comprendras l'utilité de libtool. Après tu vas même te suprendre à utiliser libtool même pour un programme qui ne doit tourner que sous Linux. Vive libtool ! et auto* ! > Même xmkmf est préférable des fois Ça marche encore ce truc ? Plus sérieusement tu peux faire une librairie avec ? et sous déférences Unix ?

        • [^] # Re: libtool

          Posté par  . Évalué à 4.

          libtool je me bat avec sous OpenBSD, FreeBSD, HP-UX, IRIX, Solaris et Linux. Je crois que ça me suffit. Au mieux il permet une certaine facilité d'un linux à un autre. Le truc c'est que quand ça marche, bon, ça marche même si ça fout des .la etc. dégueux partout. Mais quand ça ne marche pas, ça va plus vite de lire le man du compilo et de faire un makefile à la main que de chercher à comprendre pourquoi libtool ne fait que ce qu'il veut. C'est un outil linuxo-linuxien, c'est tout.

          • [^] # Re: libtool

            Posté par  . Évalué à 3.

            Oui oui.
            Et c'est pour ça qu'Apache utilise auto* libtool depuis apache 2. Tu crois qu'apache ne tourne que sous Linux ?

            Oui oui...

            Et c'est pour ça que 90 % des projets qui sont un minimum portable utilisent libtool. C'est pour se faire chiée, la beauté du geste...

            Mais oui...

            • [^] # Re: libtool

              Posté par  . Évalué à 2.

              Oui, et c'est pour ça que 90% des ordinateurs dans le monde fonctionnent sous...

              Hem, oué bon. /o\

              • [^] # Re: libtool

                Posté par  . Évalué à 2.

                Disons qu'un pourcentage d'utilisateurs peut s'expliquer par de nombreuses raisons.

                Les raisons qui poussent à utiliser un SE Microsoft ne sont sans doute pas les même que celles qui poussent à utiliser libtool.
                En particulier parce qu'a priori le public de libtool est censé être plus éclairé en informatique. Aussi, dans l'exemple que donne pti_tux, parce qu'il ne s'agit pas d'une survivance mais d'un ajout récent.

            • [^] # Re: libtool

              Posté par  (site web personnel) . Évalué à 1.

              Et c'est pour ça qu'Apache utilise auto* libtool depuis apache 2.

              C'est pas pour ça qu'ils n'aimeraient pas utiliser autre chose si il y avait mieux. Va leur demander si ils sont contents de les utiliser, je veux bien prendre les paris sur la réponse.

              autoconf/automake et libtool sont des grosses merdes mal documentées, c'est difficilement discutable. Malheureusement c'est tout ce qu'on a pour le moment, mais heureusement on commence à avoir des alternatives plus sympathiques.

              • [^] # Re: libtool

                Posté par  . Évalué à 2.

                > Malheureusement c'est tout ce qu'on a pour le moment

                C'est ce qu'il y a de mieux et ...

                > autoconf/automake et libtool sont des grosses merdes

                C'est brillant comme raisonnement.

                > mal documentées

                oui.

                • [^] # Re: libtool

                  Posté par  (site web personnel) . Évalué à 4.

                  C'est ce qu'il y a de mieux

                  Hélas oui, faute de concurrence.

                  C'est brillant comme raisonnement.

                  Ce n'est pas un raisonnement mais l'établissement d'un fait. autoconf/automake et libtool sont pathétiquement lents, beaucoup trop difficiles à utiliser, génèrent un gros tas de fichiers impossible à débugger, et surtout, le pire, cassent très souvent la compatibilité d'une version à l'autre.

                  Je pense que ces trois projets sont la cause d'une nombre effarant d'heures perdues par les développeurs du Libre, et que ceux qui les maintiennent sont irresponsables. Il est regrettable qu'on ne puisse pas les virer, pour ça il va falloir qu'une alternative crédible s'impose. Le plus tôt sera le mieux.

                  • [^] # Re: libtool

                    Posté par  . Évalué à 1.

                    Je pense que ces trois projets sont la cause d'une nombre effarant d'heures perdues par les développeurs du Libre

                    Si je puis me permettre, ca m'en a peut-etre fait perdre lors de l'apprentissage, mais apres, tu ne peux pas savoir combien j'en ai gagnees ensuite.

                    Es-tu developpeur pour affirmer de telles choses ?

                    Le bonjour chez vous,
                    Yves

                    • [^] # Re: libtool

                      Posté par  (site web personnel) . Évalué à 1.

                      mais apres, tu ne peux pas savoir combien j'en ai gagnees ensuite.

                      Pour des projets très simples dans ce genre là :

                      http://savannah.nongnu.org/users/ymettier/(...)

                      oui, c'est sur, une fois que tu as une config qui marche tu la reproduis telle quelle.

                      Es-tu developpeur pour affirmer de telles choses ?

                      Si tu jette un oeil à ma homepage tu aura la réponse à cette question.

                      • [^] # Re: libtool

                        Posté par  . Évalué à 2.

                        Pour des projets très simples dans ce genre là :

                        Ne te fie pas aux apparences. Je n'ai pas la chance d'avoir un boulot qui me permet de diffuser les sources de mes progs.

                        Merci de ne pas etre si affirmatif et dedaigneux.

                        Yves

                        • [^] # Re: libtool

                          Posté par  (site web personnel) . Évalué à 1.

                          Je ne vois pas le rapport. Tous les projets libres auquels je participe ou j'ai participé le sont à titre personnel, rien à voir avec mon employeur (qui est un éditeur de softs propriétaires).

                          Tout ce que je dis c'est que si ton expérience avec automake & Co. se limite aux projets que je vois sur savannah, je peux comprendre que tu en sois satisfait. De mon coté, avec rosegarden le constat est très négatif, et tu n'as qu'a regarder les archives des mailing lists KDE pour voir qu'on est pas vraiment une exception. Je ne crois pas que du coté Gnome on soit très enthousiaste non plus.

            • [^] # Re: libtool

              Posté par  . Évalué à 2.

              Et c'est aussi pour ça que 99,9% des packageurs ont une cible de bar avec des cases libtool et autoconf dans leur salon.
              Ces merdes sont très bien tant que l'on ne sait pas ce que l'on veut. Dès qu'il faut nettoyer derrière ou rendre les choses reproductibles proprement, ça devient sportif.

  • # Re: Autoconf/Automake... la relève ?

    Posté par  (Mastodon) . Évalué à 5.

    «He again does the typical thing and runs "./configure --prefix=/opt". The configure script runs for a while, then exits with an error which basically translates to "You have an autoconf version which is three weeks old; please upgrade", but this is displayed in the most cryptic manner possible.» C'est quoi cette connerie ? Depuis quand on a besoin d'avoir autoconf installé pour lancer un script configure ? Il y a certainement beaucoup de choses à reprocher à automake/autoconf, d'ailleurs les fois où j'ai essayé de comprendre comment faire mes propres scripts j'ai abandonné, mais là ça ressemble à un troll.

    • [^] # Re: Autoconf/Automake... la relève ?

      Posté par  . Évalué à 10.

      Depuis quand on a besoin d'avoir autoconf installé pour lancer un script configure ? Dans certaines conditions, par exemple si configure.in (ou maintenant configure.ac) est plus recent que le script configure, alors configure le detecte, et tente de relancer autoconf/automake avant de s'auto-relancer lui-meme. Quand tu telecharges un paquet depuis le net, normalement, l'auteur a fait un "make distcheck" qui genere ce paquet, avec un configure posterieur au configure.in (ou configure.ac), et le probleme ne se pose pas. Quand tu bosses sur ton projet, que tu changes de machines ou que tu mets a jour ta machine regulierement, ce genre de situations peut survenir et poser le probleme. Donc non, c'est pas un troll. Mais c'est un probleme qui est reserve aux developpeurs, et aux malheureux utilisateurs de logiciels dont le developpeur a mal fait son tarball. L'utilisateur qui telecharge un paquet propre n'a pas ce probleme. Le bonjour chez vous, Yves

    • [^] # Re: Autoconf/Automake... la relève ?

      Posté par  . Évalué à 2.

      Il y a certainement beaucoup de choses à reprocher à automake/autoconf, d'ailleurs les fois où j'ai essayé de comprendre comment faire mes propres scripts j'ai abandonné, mais là ça ressemble à un troll.

      Pour faire ses propres scripts, il faut d'abord avoir une courte introduction sur le sujet (voir linuxmag 24 ou http://www.linuxmag-france.org/vrac/AA.html(...) ). Et ensuite, regarder comment font les autres pour faire leur configure.in. Je prends comme référence pour écrire les miens celui de SDL, qui en plus gère pas mal de plate-formes, ce qui peut en intéresser certains.

  • # Re: Autoconf/Automake... la relève ?

    Posté par  . Évalué à 7.

    En tant que developpeur, je ne peut qu'etre d'accord. La suite auto* est une horreur, doc totalement cryptique, peu d'exemples valables (sur le net en tout cas), pas de vue d'ensemble du process. En tant que user, quand ca marche c'est "formidable", quand ca marche pas (ca arrive plus souvent quand on quitte linux) alors la c'est la vraie galere, on sait jamais si on doit modifilier les skel makefile le script configure.in ou autre chose. De l'horrible en baril. Plus jamais je n'utiliserais auto* en tant que dev....

  • # Commentaire supprimé

    Posté par  . Évalué à 1.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Autoconf/Automake... la relève ?

      Posté par  . Évalué à 3.

      en tout cas le projet Cons à l'air bien plus avancé que Scons. C'est dommage, je préfère un environnement Python. Scons est basé sur Python 1.5.2, c'est bien pour la portabilité, mais j'ai commencé à regarder les sources, le passage à Python > 2 aurait permis de simplifier une bonne partie du code et j'ai vu un ou deux goulet d'étranglement qui ont été notemment amélioré dans les versions supérieurs de Python.

      • [^] # Re: Autoconf/Automake... la relève ?

        Posté par  . Évalué à 4.

        des quelques tests persos que je viens de faire, je commençais à faire des cauchemards pour reprendre mon makefile. tout l'operation a enfaite simplement consitster à recupérer mes *SRC et à tout coller de la sorte env.Program(cible, ligne_SRC_de_mon_Makefile) et zou!!!! et tout fonctionne au poil, meme plus rapidement j'ai l'impression (par ce que faire les dépendances quand un Makefile, c'est assez couteux). La gestion des mise a jour avec un MD5 est un régal. que du bon!!! j'adopte. en plus ça fonctionne avec tout un tas de compilateur/LP. manque plus qu'un traducteur en Makefile pour ce qui n'ont pas installé Scons ou un traducteur Scons<->Cons

    • [^] # Re: Autoconf/Automake... la relève ?

      Posté par  . Évalué à 7.

      J'ai une petite experience de cons et franchement je prefere mille fois autoconf automake. Ca s'ecrit avec un espece de language derive du perl qui n'est absolument pas intuitif, pour etendre les fonctionnalites de cons, on a rien du tout, et la doc ne vaut pas mieux que celle d'automake/autoconf. En resume je trouve que cons ne couvre pas 5% des fonctionnalites possibles avec automake/autoconf/libtool. Dans mon equipe de travail on nous a impose cons comme systeme de build. J'ai fait des pieds et des mains pour pouvoir garder automake/autoconf/libtool pour le projet sur lequel je bosse. Beaucoup de mes collegues developpeurs (y compris ceux qui ont fait les scripts Cons) sont tres heureux qu'il reste encore un projet qui tourne avec automake/autoconf/libtool, car Cons c'est l'enfer. Je suis d'accord qu'il faudrait une doc plus sympa et plus integree, plus globale pour les debutants, mais de toute facon ceux qui croient qu'on peut apprendre a se servir d'un language de build en moins de 2 heures se foutent gravement le doigt dans l'oeil.

  • # Re: Autoconf/Automake... la relève ?

    Posté par  . Évalué à 3.

    Ca à l'air vraiment pathétique, comme article. Tout d'abord, on nous raconte que la commande habituelle est "./configure --prefix=/opt". Vraiment ? Avec SuSE peut-être, mais rien qu'avec SuSE. Quel goret ! Il nous dit qu'il y a pas mal de chance de tomber sur "You have an autoconf version which is three weeks old; please upgrade". Ca ne m'est jamais arrivé en 5 ans. Epatant pour un truc habituel. Qu'il puisse avoir plusieurs options différentes pour une même chose selon les programmes lui parait extremement critique : "He wants to use GTK, but how does he do it? Is it "--with-gtk" or "--enable-gtk"? Perhaps this time it's "--enable-gnome", or maybe "--with-toolkit=gtk". In any case, he finally "gets" it and runs the configure script, customizing the package to his heart's delight"... Ouah. Il nous parle de "Now, Joe is presented with an interesting problem. He realizes that he needs to edit something besides the Makefile. But what does he look at? configure.in? Makefile.am? Makefile.in? Makefile.yoyo? Makefile.banana? By now, the average user has done one of the following: Given up and tried a different package. Shot himself in the head with a twelve gauge shotgun. " Ben évidemment, si ça compile pas on passe à autre chose. C'est au développeur de fournir un truc qui se compile

    • [^] # Re: Autoconf/Automake... la relève ?

      Posté par  . Évalué à 5.

      Tout d'abord, on nous raconte que la commande habituelle est "./configure --prefix=/opt". Vraiment ? Quand je ne fais pas mes propres paquets, je fais meme --prefix=/opt/logiciel/logiciel-version Et si je suis motive, j'utilise GNU Stow pour faire les liens qui vont bien dans /usr/local. Chacun son style d'installation. Il nous dit qu'il y a pas mal de chance de tomber sur "You have an autoconf version which is three weeks old; please upgrade". Ca ne m'est jamais arrivé en 5 ans. En tant que developpeur, qui developpe sur une mandrake cooker, mais qui prend le soin de tester sur une debian stable, ce genre de probleme m'arrive a chaque fois. Chacun son style d'utilisation. Pour le reste, par contre, je suis d'accord: l'auteur de l'article a l'air de pas aimer autoconf/automake tout simplement parce qu'il lui arrive des trucs qui ne lui arriveraient pas, ou qui n'auraient pas d'importance, s'il savait s'en servir correctement. En tout cas, moi je vais jeter un coup d'oeil a cons et scons, mais a court terme, pas question d'abandonner autoconf/automake! Le bonjour chez vous, Yves

      • [^] # Re: Autoconf/Automake... la relève ?

        Posté par  (site web personnel) . Évalué à 2.

        Moi j'ai eu tous les problemes de l'auteur plus quelques autres. Genre, tu tapes:
        ./configure --with-qt-lib=/opt/my_qt

        et configure te dit qu'il ne trouve pas qt!! Comment se fait-il ? Tu verifies ton disque dur, tu refais un ./configure --help pour etre sur. C'est qu'au bout de 10 minutes que tu t'apercois que la seule option utile de ./configure etait --with-qt-libs (le s, vous le voyez) et pas --with-qt-lib. Et me dite pas que c'est specifique a qt/kde, on en voit partout. La vraie questions, c'est pourquoi configure ne m'a-t-il pas dit que je m'etais plante dans le nom d'une option ? Ca doit etre trop user-friendly!

        Pire, si j'ai un qt standard mais que je voulais utiliser mon qt a moi avec mes options a moi (de /opt/my_qt), le configure ne se plantera meme pas et moi je ne realiserai pas qu'il n'a pas pris mon qt.

        Pour l'instant, j'utilise tmake dans mes projets. Super simple a utiliser, pas parfait au niveau de la generation mais bien quand meme. Et surtout, il a une fonctionnalite que je ne retrouve pas dans les autres make-like: il permet de generer des projets pour Microsoft Visual C++. Ca va pas plaire a certains mais c'est un besoin pour moi.

        • [^] # Re: Autoconf/Automake... la relève ?

          Posté par  . Évalué à 1.

          Le successeur de tmake qui est qmake est en effet un excellent générateur de makefiles. Ses atouts :

          • simplicité

          • documentation claire et nette, pas dans une doc GnuInfo à 2 balles (quoique c'est utilisable avec konqueror)

          • portabilité



          La seule chose qui lui manque est la possibilité de faire de la recherche de libs, progs, etc comme le fait un script configure. Néanmoins c'est dans les plans de TrollTech.

          <mon expérience à moi>
          Je m'étais amusé à apprendre à utiliser auto* pour des projets. Effectivement c'est mal documenté, mais j'avais réussi à créer de A à Z tout les fichiers nécessaires en comprenant leur utilité. Bref j'avais fait des systèmes auto* qui cherchaient les bonnes libs, etc.

          Mais je me suis aperçu que ce qui était acquis sur auto* se perdait très vite ... Je suis systématiquement obligé de me plonger dans la doc car c'est un système non trivial et plutot complexe. Quand à Gnu M4, c'est franchement le genre de geekerie dont on se passerait bien. Pour des besoins spécifiques il faut connaitre M4 afin d'étendre le système, mais je préfère abandonner, c'est trop lourdingue.

          En comparaison, je sais faire sans doc un framework de compilation avec Jakarta Ant ou QMake. Mais avec auto*, impossible ...
          </mon expérience à moi>

          Bref, vivement un successeur. Il y a l'air d'avoir pas mal de concurrents intéressants, mais il semble que le syndrome de la crainte du changement se manifeste. Pour des projets anciens, ça ne vaut pas forcémment le coup de migrer, mais pour des projets récents ou neufs, je pense que jetter un oeil en vaut la peine.

          Mes 5 centimes :-)

          • [^] # Re: Autoconf/Automake... la relève ?

            Posté par  (site web personnel) . Évalué à 1.

            La doc de qmake est pas trop mal, mais l'outil lui-meme a encore des limitations:
            - maintenant qu'il est en C++, il est tres difficile a etendre
            - tres grave: il ne gere pas la dependance d'un executable sur une bibliotheque statique, alors qu'un Makefile et que Visual serait capable de le gerer. J'ai discute avec un mec de Trolltech, il ne prevoit pas de le faire.
            - il limite a un fichier.pro par repertoire, ce qui est chiant. typiquement, si tu as un executable qui depend de bibliotheques statiques, c'est ingerable parce que il te faut un template subdir dans le repertoire principal, puis un template staticlib pour les sous repertoires, mais il ne te reste plus de template pour ton executable. Ou bien tu dois le mettre dans un sous-repertoire mais le ne se recontruit pas quand tu changes les bibliotheques statiques.

            Pour l'instant j'utilise tmake qui est aussi pas tres bon pour gerer les dependances. Il y a plein de fichiers .h dont la modification n'entraine pas une recompilation alors qu'elle devrait.

        • [^] # Re: Autoconf/Automake... la relève ?

          Posté par  . Évalué à 2.

          Pire, si j'ai un qt standard mais que je voulais utiliser mon qt a moi avec mes options a moi (de /opt/my_qt), le configure ne se plantera meme pas et moi je ne realiserai pas qu'il n'a pas pris mon qt.

          Comment veut-tu que le script "./configure" sache que t'as un qt à toi, qu'il doit le prendre ou te signaler s'il ne le prend pas ? Il doit faire une recherche dans tout ton/tes disque(s) ?

          Concernant les options à passer, je ne vois pas comment on peut faire pour avoir à la fois un système souple et qui garantit certaines normes. La seule chose à faire me semble être d'encourager une certaine discipline de la part des développeurs.

          • [^] # Re: Autoconf/Automake... la relève ?

            Posté par  (site web personnel) . Évalué à 2.

            Tu as mal saisi ce que je voulais dire. Si je tape:

            ./configure --with-qt-lib=/opt/my_qt

            configure va ignorer silentieusement mon option parce que j'ai oublie le s (--with-qt-libs) et utiliser un qt standard. Si je ne remonte pas 25 page en arriere pour verifier qu'il a le pris le bon qt, je n'aurai aucun indice d'une erreur. Et apres, je passerai trois jour a essayer de comprendre pourquoi mes programmes crashent quand je genere une exception.

            Des programmes plus intelligents, comme il me semble le configure de mplayer (ou est-ce xine ?) t'affichent a la fin ce qu'ils ont detecte d'important sur ton systeme.

            • [^] # Re: Autoconf/Automake... la relève ?

              Posté par  . Évalué à 1.

              C'est possible de demander à auto* de résumer tout ce qui a été trouvé à la fin du script "./configure". Tout du moins, je crois.

              • [^] # Re: Autoconf/Automake... la relève ?

                Posté par  . Évalué à 1.

                Si c'est une fonctionnalite, ca m'interesse.

                Si c'est juste parce que tu l'as vu dans certains projets, sache que c'est le programmeur qui, dans son fichier configure. ajoute des lignes avec echo et le nom des variables. Ceci dit, c'est bien sympathique :)

                Le bonjour chez vous,
                Yves

        • [^] # Re: Autoconf/Automake... la relève ?

          Posté par  . Évalué à 2.

          la seule option utile de ./configure etait --with-qt-libs (le s, vous le voyez) et pas --with-qt-lib.

          avec une vraie complétion, celle de zsh ou de bash pour ne citer qu'elles, ça ne te serait pas arrivé ;)

        • [^] # Re: Autoconf/Automake... la relève ?

          Posté par  . Évalué à 1.

          Premier réflexe : aller voir dans config.cache !

    • [^] # Re: Autoconf/Automake... la relève ?

      Posté par  . Évalué à 3.

      « Ca à l'air vraiment pathétique, comme article. »

      Complètement d'accord avec ça. Ca ne manque pas de mauvais exemples.

      Je trouve que c'est là qu'on voit toute la différence avec une vraie critique constructive : l'exemple auquel je pense est Subversion, qui se veut le successeur de CVS. CVS est plein d'avantages mais aussi plein de limitations, l'équipe de Subversion l'a expliqué objectivement sans chercher à descendre CVS qui reste le standard de fait, faute de mieux pendant longtemps. De même ici, personne ne niera les inconvénients d'autoconf/automake et un successeur pourrait faire beaucoup mieux (il y a déjà de bons candidats). Ca mériterait une vraie critique objective sans tomber dans toutes ces remarques déplacées qui ne sont là que pour descendre les Auto*. Ce genre d'article ne fait que décrédibiliser les solutions qu'il cherche à promouvoir.

  • # pmk est aussi la :)

    Posté par  (site web personnel) . Évalué à 2.

    un autre programme qui peut etre interessant :) http://sourceforge.net/projects/premk/ pm

    • [^] # Re: pmk est aussi la :)

      Posté par  . Évalué à 1.

      ou Jammer utilisez notemment par la bilitohèque C++ Boost http://www.perforce.com/jam/jam.html

      • [^] # Re: pmk est aussi la :)

        Posté par  . Évalué à 1.

        Apparement il s'agit du Jam/make redux utilisé par OpenBeOS. Autant ça peut servir de remplaçant à make (et même un peu mieux), il me semble que c'est pas du tout équivalent à ce que fait autoconf. Ca ne génère pas d'auditeur (e.g. de configure), et ne fait qu'une toute petite partie de ce que ce dernier est censé faire.

  • # Re: Autoconf/Automake... la relève ?

    Posté par  . Évalué à -1.

    Pour avoir compile GCC recemment, je trouve que le systeme configure/make est une vraie horreur (j'ai connu le cas du configure qui reprend indefiniment, je n'ai jamais trouve pourquoi). Le truc bien cryptique-linuxien comme d'habitude. Je pense que la majorite des personnes veulent seulemnt controler l'endroit ou installer leur logiciel et la plupart des options ne sont pas utiles. Personnelement je verrai bien un petit wizard (graphique ou non) pour lancer la sequence buil/install.

    • [^] # Re: Autoconf/Automake... la relève ?

      Posté par  . Évalué à 0.

      Pour ça jsuis complètement d'accord avec toi! Disons qu'avec un wizard ce serait plus facile de choisir les options (liste a cocher) et ce serait facilement accessible à l'utilisateur moyen qui veut se lancer dans linux. Disons que la compilation des logiciels fait peur à beaucoup, surtout ceux qui n'ont pas beaucoup de connaissances en Linux!

      • [^] # Re: Autoconf/Automake... la relève ?

        Posté par  . Évalué à 5.

        En même temps, un utilisateur moyen va plutôt utiliser des packages tout prêt fournis par sa distrib. Je ne vois pas pourquoi il se ferait chier à tout se palucher à la mimine.
        Ensuite, pour le wizard graphique, je tiens juste à rappeler que contrairement à d'autres OS, GNU/Linux ne fonctionne pas obligatoirement en mode graphique. Perso, je n'ai pas installé X sur mon serveur, vu qu'à priori, je ne brancherai jamais d'ecran dessus.
        Je crois qu'il faut rester généraliste, mais aussi réaliste : un utilisateur lambda utilisera le mode graphique, oui, mais aussi les packages de sa distrib.
        Quelqu'un qui veut jouer au l33t et customizer sa distrib doit de toutes façons avoir un certain niveau, et devrait donc être en mesure de bosser en mode texte.

    • [^] # Re: Autoconf/Automake... la relève ?

      Posté par  . Évalué à 1.

      « Je pense que la majorite des personnes veulent seulemnt controler l'endroit ou installer leur logiciel et la plupart des options ne sont pas utiles. »

      La majorité des personnes n'a aucune raison de compiler gcc et se voit même déconseiller de compiler gcc.

      Si on veut le faire pour le fun, pourquoi pas. Mais se plaindre que ce n'est pas évident, c'est une blague. C'est pas conçu pour être évident.

      Et très franchement, j'aimerais que tu nous listes ici « la plupart des options [qui] ne sont pas utiles ».

      Ce qui m'interesserais moi, c'est l'avis des gens de gcc sur la question.

  • # Autre alternative : rake

    Posté par  (site web personnel) . Évalué à 1.

    Make-like en Ruby. Pas encore très développé, mais très prometteur :

    http://raa.ruby-lang.org/list.rhtml?name=rake(...)

  • # Re: Autoconf/Automake... la relève ?

    Posté par  (site web personnel) . Évalué à 1.

    Moi je trouve que ça fonctionne très bien le ./configure, make, make install...
    Hier j'ai essayé Scons avec cheestracker, ça m'a plutot déplu... J'ai pas trouvé d'options, pas de moyens de modifier les CFLAGS et les CXXFLAGS, etc...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.