GNU Autoconf, Automake, and Libtool

Posté par  . Édité par Benoît Sibaud. Modéré par Fabien Penso.
Étiquettes :
0
17
avr.
2001
Doc

Extrait : « Vous connaissez sans doute les commandes ./configure;make;make install mais lorsque l'on désire aller plus avant dans la configuration ou lorsque l'on désire passer du côté développeur, ça devient franchement l'horreur : il y a de quoi devenir chèvre. Cela tombe bien voici un livre avec un dresseur de chèvres sur la couverture qui devrait grandement vous aider à maîtriser le trio Autoconf, Automake et Libtool. »

Sommaire

GNU Autoconf, Automake, and Libtool
Auteur : Gary V. Vaughan, Ben Elliston, Tom Tromey & Ian Lance-Taylor
Éditeur : New Riders
ISBN : 1-57870-190-2
Pages 390
Prix : Prix Constaté 317F
Rédacteur : trollhunter

Couverture

Au cours des deux premiers chapitres de ce livre le lecteur a droit à un historique de ces outils, puis à une introduction vue du coté utilisateur de Configure et des Makefiles.

Déjà l'on sent que l'on est en présence d'un ouvrage "différent" : alors que d'autres ouvrages se contenteraient de lister les options de Configure les auteurs prennent la peine d'expliquer certains points qui sont implicites pour l'initié mais pas nécessairement pour le béotien.

Le troisième chapitre permet de faire plus ample connaissance avec les Makefiles.

Le quatrième chapitre vient rompre le coté théorique avec un exemple de mini projet permettant de mettre en pratique ce qui a été vu précédemment. Cette fois-ci l'on rentre dans le vif du sujet puisque l'on devient développeur. Au cours de ce projet minimal, le lecteur est guidé pas à pas dans les manipulations. De nombreuses sorties d'écran agrémentent la lecture, en outre, l'on a droit a des explications détaillées concernant le pourquoi du comment, ce qui est assez rare.

Puisque le but est d'écrire des programmes portables, le cinquième chapitre est consacré à la portabilité. Ce chapitre est court, mais important et comme pour l'ensemble de l'ouvrage les notions qui y sont présentées seront réutilisées plus tard, attention donc à la lecture en diagonale ;-)

Le sixième chapitre lui, est une introduction à Automake.

À nouveau l'on replonge dans la pratique avec un chapitre exemple qui sera réutilisé dans deux autres chapitres. La portabilité est toujours présente à l'esprit. Le langage C K&R a droit à son paragraphe.

Le chapitre 8 est très court (3 pages), mais comme tous les chapitres de ce livre il couvre un aspect important appelé bootstraping. Vous seront présenté les deux approches bootstrap et autogen, bien entendu l'on vous donne les moyens de faire votre choix.

Les deux chapitres suivants vous présentent Libtool et son utilisation, ainsi la création et l'utilisation des bibliothèques n'auront plus de secrets pour vous.

Dans le onzième chapitre, vous retrouverez le projet exemple vu au chapitre 7 mais cette fois ci il est largement développé avec entre autres choses l'utilisation de Libtool vu précédemment et l'intégration d'une suite de tests.

Puisque vous êtes désormais capables de gérer des projets importants, il est temps de passer à l'étape suivante : la distribution et l'installation/désinstallation de votre travail: c'est l'objet des deux chapitres suivants.

Les chapitres 14 et 15, eux, vous donnent les conseils nécessaires à l'écriture de programmes portables en C et en C++, avec l'épineux problème de la portabilité Unix/Windows.

Les plug-ins ou modules rencontrent un succès croissant. À l'issue du chapitre suivant vous serez à même d'ajouter cette fonctionnalité à vos projets puisque vous saurez coder un petit chargeur de modules.

Puisque vous commencez à prendre goût aux modules, le chapitre suivant vous présente libdtl avec pour exemple un chargeur de module utilisant cette bibliothèque.

À partir d'ici vous allez pouvoir approfondir vos connaissances concernant Automake dans un court chapitre.

Le dix-neuvième chapitre vous présente un projet complexe avec chargement dynamique de modules.

Les cinq derniers chapitres sont consacrés a des aspects moins immédiats comme les M4, l'écriture de scripts portables, la création de nouvelles macros pour Autoconf, la migration de packages existants vers les utilitaires GNU. Enfin l'on vous présentera la mise en œuvre de ces outils avec Cygwin. La cross-compilation ou compilation croisée étant un aspect important du développement, vous avez droit dans le dernier chapitre à une bonne introduction sur ce sujet.

Ce livre suit une démarche, logique et progressive, avec des petits encarts intitulés

  • Warning Pour les avertissement concernant par exemple la compatibilité avec de futures version de ces outils.
  • Best Practice Pour les pratiques recommandées dans les projets.
  • Hands On Ce sont des exercices d'application de notions passées en revue.
  • Note Lorsqu'une note permet d'approfondir une explication ou d'aller plus loin.

Il est à signaler aussi de nombreux tableaux récapitulatifs des différentes options comprises par les utilitaires, ces tableaux sont non seulement exhaustifs mais en outre les différentes options sont expliquées, le cas échéant avec un exemple à l'appui. L'on voit que les auteurs ont fait un gros effort pour se mettre à la place du lecteur.

Ainsi, au fil des pages c'est un tout cohérent qui est construit, petit à petit, même si la lecture et l'assimilation de certaines parties de l'ouvrage demande un certain effort, les auteurs ont fait de gros effort pour vous aider dans votre progression.

Cet ouvrage possède aussi un ton particulier ; en effet bien qu'écrit par 4 personnes l'emploi de la première personne est très fréquent et en outre les auteurs, afin d'éviter au lecteurs des déboires, évoquent avec franchise les échecs qu'ils ont rencontrés en utilisant telle approche plutôt qu'une autre. Autant les gens sont près à parler de leur réussites autant ils sont peu loquaces sur leurs échecs, pourtant les échecs sont aussi tout autant instructifs pour peu que l'on prenne la peine de les analyser.

Ainsi, une démarche pourtant logique lorsqu'il s'agit de tenter de développer un programme pour plusieurs plateformes (chapitre 5) a fait perdre beaucoup de temps et d'énergie à l'un des auteurs.

L'on sent vraiment que les auteurs et les relecteurs se sont appliqués pour faire de ce livre qui aborde un sujet assez technique reconnaissons-le, un ouvrage plaisant à étudier.

Autre grande qualité des auteurs et de cet ouvrage, non seulement une partie du produit de la vente est reversée à la FSF mais ce livre est consultable en ligne et téléchargeable.

Table des matières

  1. History
  2. How to Run Configure, and the most Useful Standard Makefile Targets.
  3. Introducing `Makefile's
  4. Using GNU Autotools to Manage a "Minimal Project"
  5. Writing a Portable `configure.in'
  6. Introducing GNU Automake
  7. A Small GNU Autotools Project
  8. Bootstrapping
  9. Introducing GNU Libtool
  10. Using GNU Libtool with configure.in' andMakefile.am'
  11. A Large GNU Autotools Project
  12. Rolling Distribution Tarballs
  13. Installing and Uninstalling Configured Packages
  14. Writing Portable C with GNU Autotools
  15. Writing Portable C++ with GNU Autotools
  16. Dynamic Loading
  17. Using GNU libltdl
  18. Advanced GNU Automake Usage
  19. A Complex GNU Autotools Project
  20. GNU M4
  21. Writing Portable Bourne Shell
  22. Writing New Macros for Autoconf
  23. Migrating an existing Package to GNU Autotools
  24. Using GNU Autotools with Cygnus' Cygwin
  25. Cross-Compilation with GNU Autotools
  • A Installing GNU Autotools
  • B Platforms
  • C Genarated File Dependencies
  • D Autoconf Macro Reference
  • E Open Publication License

Références

  • # linux mag

    Posté par  . Évalué à 3.

    Je fonce l'acheter, ce bouquin.

    J'avais ecrit deux article sur le theme dans linux mag, faute d'avoir d'autre doc en francais. Peut-etre me donnera-t-il des idees?

    En attendant, j'aimerais bien faire un sondage relativement technique:
    quel est votre impression d'un logiciel qui ne dispose pas de ./configure ?

    1. On s'en fout: make

    2. Ou est le fichier INSTALL?

    3. Tant pis, je cherche le .deb/.rpm

    4. Bah, s'il n'a pas ./configure, c'est qu'il est pas encore assez developpe, et probablement instable, donc tant pis.

    5. je vais le faire moi-meme, ce ./configure et je l'envoie a l'auteur

    6. d'autres reactions?



    Perso, ma reaction est un melange de 4 et 5.

    Le bonjour chez vous,
    Yves
    • [^] # Re: linux mag

      Posté par  . Évalué à 1.

      Personnellement, s'il n'y a ni README, ni INSTALL, l'ensemble risque fort de partir au paradis des octets (/dev/null) ! Il faut vraiment que j'aie besoin du truc en question pour que je me plonge dedans.

      En fait, je rejoins tout à fait le point de vue de je ne sais plus qui dans un commentaire de je ne sais plus quelle nouvelle de ce site (je n'ai pas envie de rechercher ...), le fait d'écrire sous GPL ne donne pas le droit de faire n'importe quoi. La moindre des choses si on veut que son soft soit testé et reçoive des critiques (<0 ET >0), c'est d'expliquer comment l'installer.

      En attendant, il se peut que le logiciel ne soit pas assez avancé et/ou assez compliqué pour nécessiter un ./configure. Dans ce cas, ça ne me pose pas de problème. On ne va pas non plus exiger un outil plutôt qu'un autre ... J'ai déjà utilisé des solutions basées sur Ant (pour des softs en Java) qui étaient tout à fait correctes. L'essentiel reste pour moi la documentation.
    • [^] # Re: linux mag

      Posté par  . Évalué à 1.

      s'il n'y a pas de ./configure c'est le fichier INSTALL et/ou le README puis le "make". Si le projet est petit je regarde le make avant de me lancer.

      donc c'est un mélange de 2) et de 1).

      par contre si le projet est mal documenté >/dev/null.

      J'ai pas encore le niveau pour faire mes propres *.am et configure.in les doigts dans le nez mais avec les articles de LinuxMag j'ai commencé à m'y mettre (parce que la doc "info" de ces outils GNU est trop obscure).
      • [^] # Re: linux mag

        Posté par  . Évalué à 1.

        Doc trop obscure?
        Si tu prends la doc info, je suis tout a fait d'accord. Par contre, si tu vas sur http://www.gnu.org/manual/autoconf/index.html(...) et http://www.gnu.org/manual/automake/index.html,(...) c'est jouable. C'est a partir de la que je suis parti.

        Le plus marrant, c'est que le contenu est exactement le meme, mais c'est la forme qui, en ce qui me concerne, rend le format info inexploitable.

        O'reilly devait sortir un autre book sur autoconf/automake en janvier. Je ne sais pas s'il est sorti.

        Le bonjour chez vous,
        Yves
        • [^] # Re: linux mag

          Posté par  . Évalué à 0.

          Je trouve exaspérante cette obsession de la GNU à mépriser les pages du manuel en ligne (man) et à vouloir imposer son format info.

          On voit le résultat dans Debian, par exemple: un certains nombres de commande sont mal documentées, ou pas du tout (càd que l'on a le hautain "si vous aimeriez voir une page man, écrivez-la. Sinon, arrêtez Debian.").

          J'aimerais voir une distribution Linux à la OpenBSD, càd avec des pages man pour tout, et de bonne qualité. Ca serait vraiment très chouette!
          • [^] # Re: linux mag

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

            Le format info a pour moi pas mal d'avantages sur les pages man "de base". En fait, le *gros* plus est d'avoir une gestion des liens hypertexte. En plus, la plupart du temps, si tu fais "info bidule" et que le bidule a pas de page info mais une page man, alors info t'affiche la page man à la place.
            Donc moi j'aime bien info.
            Mais bon c'est un point de vue personnel et discutable 8-)
            • [^] # Mouais l'ergonomie de info est pas terrible

              Posté par  . Évalué à 1.

              J'ai du regarder l'info de GRUB, il n'y a pas tres longtemps. Heuh, bof, bof.

              Quand on connait pas, ce n'est pas tres intuitif!

              J'ai du faire man info pour m'y retrouver!
              Heureusement la recursion s'est arretee la :-)
          • [^] # Re: linux mag

            Posté par  . Évalué à 0.

            On voit le résultat dans Debian, par exemple: un certains nombres de commande sont mal documentées, ou pas du tout (càd que l'on a le hautain "si vous aimeriez voir une page man, écrivez-la. Sinon, arrêtez Debian.").

            Un des objectifs et devoir du projet debian est que chaque commande ait sa page man. Y a eu une news recemment pour chercher des volontaires.

            Engagez vous !
          • [^] # Re: linux mag

            Posté par  . Évalué à 1.

            En ce qui me concerne, c'est juste que pour un meme contenu, je prefere une page html a une page info. C'est juste une affaire de convivialite.
            Ca n'engage que moi.

            Il en faut pour tous les gouts, non?

            Le bonjour chez vous,
            Yves
    • [^] # Re: linux mag

      Posté par  . Évalué à 1.

      Bien d'abord c'est la recherche des README et INSTALL, puis si il y en a pas c'est regardons la Makefile.
    • [^] # Re: linux mag

      Posté par  . Évalué à 1.

      Je suis de l'avis d'Acné. Avant de compiler un soft, je jete un coup d'oeil à sa documentation (le README, l'INSTALL, voire même les commentaires du Makefile ou des sources). Si il n'ya pas de doc disant ce que le soft fait, ce qu'il requiert ou sa procédure d'instal, je laisse tomber.
  • # très bien ce document

    Posté par  . Évalué à 0.

    Je suis allé voir la version en ligne.

    C'est un ouvrage très instructif.
    Comme toujours, l'explication par l'exemple est un excellent point de départ.
    Malheureusement, je suis resté sur ma faim pour les explications plus en détails.

    Oui, je sais, vous allez me dire de lire la doc des outils ...

Suivre le flux des commentaires

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