Journal pkgconf: un pkg-config qui ne se mord pas la queue

Posté par  (site web personnel) .
Étiquettes :
32
28
sept.
2012

Depuis la version 0.26, pkg-config utilise glib2, très bien, pourquoi pas…

Là où ça se complique, c'est que : les versions précédentes de pkg-config embarquaient les morceaux de la glib1 qui étaient utilisés afin d'éviter une dépendance externe, la version 0.26 - elle - dépend de la glib2 uniquement en externe, rendant du coup impossible la compilation from scratch sans horribles hacks.

Bah oui, pkg-config dépend de glib2 pour se compiler et glib2 dépend de pkg-config qui dépend de glib2 qui dépend de pkg-config qui dépend de…

Du coup, certains ont pondu : http://sourceforge.net/projects/pkgconfiglite/ et le dev de pkg-config a ajouté un switch permettant en 0.27 d'utiliser une version embarquée de glib2 :
http://cgit.freedesktop.org/pkg-config/commit/?id=c74da521af566bc208ff9a2da3e43634817f73d5

Pour pallier ce problème, plusieurs initiatives de développement d'alternative à pkg-config ont vu le jour. En particulier, pkgconf, cette version a plusieurs mérites :

  • 0 dépendances : pkg-config devient un élément clef d'une chaîne de compilation ; faire en sorte qu'elle ait le moins de dépendances et de complexité permet de simplifier la vie des gens ayant besoin de créer un système "from scratch" (sans dépendance, le nombre de lignes de code est pourtant similaire)
  • Test driven : le développement de pkgconf est "test driven", à chaque fois qu'une anomalie est remontée, un jeu de test est ajouté pour éviter le maximum de régression possible. L'ajout de fonctionnalité ne peut se faire que si des fichiers de test ont été ajoutés d'abord.
  • 100% compatible avec pkg-config, toutes les incompatibilités doivent être corrigées si il y en a encore, même les idioties de pkg-config ont été ajoutées, un gros travail a été fait pour aussi permettre aux scripts de configure "idiot" de fonctionner avec pkgconf de la même manière qu'avec pkg-config (par exemple beaucoup de scripts cherchent les espaces dans la sortie de pkg-config, etc.)
  • Rapide, pkgconf est plus rapide que pkg-config, ce qui ne semble pas très important de prim'abord, mais le devient rapidement lorsque que vous avez un programme un peu conséquent faisant des centaines d'appels à pkg-config dans sa chaîne de compilation.
  • Très ouvert : il est très simple de proposer des idées ou des patchs ; c'est en général pris en compte très rapidement, mais attention, si vos contributions sont appréciées, vous risquez rapidement de devenir développeur officiel du projet !
  • Des idées folles pour l'avenir :) ( https://github.com/pkgconf/pkgconf/wiki/Roadmap )
  • Une jolie licence BSD :)

Beaucoup de projets ont déjà adoptés pkgconf :

Certainement d'autres, mais personne ne nous l'a dit :)
Vous pouvez venir discuter de pkgconf sur irc : #pkgconf sur freenode.

  • # Buildroot

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

    Il est en cours d'adoption également dans Buildroot (http://www.buildroot.org), un outil de compilation de systèmes Linux embarqués (par compilation croisée).

  • # So cool so pkg

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

    Une jolie license BSD :)

    Vade Retro Satana !! Que la Segfault celeste RMS s'abbatte sur toi  !

    Execepté ça, trés trés bon projet, pkg-config est le seul moyen valable pour fournir ses flags de compilations proprement… et de manière portable indépendament du build système( autotools, cmake, scons, waf…).

    Mais il faut bien avouer qu'il vieillit, la gestion des dépendances est lentes comme pas possible ( essayer d'utiliser les globus .pc, vous comprendrez… ), il est passablement bugggué lorsque'on l'utilise avec des paths non standards et ça ne ferait pas de mal de pouvoir étendre un peu les flags disponible à autre chose que --libs et --cflags.

    • [^] # Re: So cool so pkg

      Posté par  . Évalué à 1.

      Une jolie license BSD :)

      Vade Retro Satana !! Que la Segfault celeste RMS s'abbatte sur toi  !

      Hé beh … Heureusement qu´on est Trolldi … ;-)

      Hop,
      Moi, prends son pop-corn.

  • # Nazi de la grammaire

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

    faire en sorte qu'elle est le moins de dépendances

    Qu'elle ait[verbe avoir]. Ça va être difficile de faire une phrase où l'on est[verbe être] le moins de dépendances possible.

    Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

  • # Une petite erreur

    Posté par  . Évalué à 8.

    Beaucoup de projets ont déjà adoptés pkgconf:
    ArchLinux : Disponible via AUR ( https://aur.archlinux.org/packages.php?ID=60768 ).

    Dire que si un paquet se trouve dans AUR, se retrouve automatiquement supporté par ArchLinux, c'est au mieux une erreur, au pire un mensonge.

    AUR regroupe les paquets d'utilisateurs (ou contributeurs), et n'est pas du tout supporté par ArchLinux. Les Trusted Users se contentant la plupart du temps de vérifier à ce que les paquets postés ne soient pas "nocifs" (dangereux pour le système) et respectent les licences d'utilisations de ceux-ci.

  • # Grammar n*zi

    Posté par  . Évalué à 5.

    On dit "palier un problème", sans préposition.

    Pour s'en souvenir : "palier" veut dire "recouvrir d'un manteau" (et donc par extension le faire disparaître), on ne dirait donc pas "recouvrir à un problème".

  • # Alpine ?

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

    Tiens c'est la première fois que j'entends ce nom sur dlfp. Alors, hop :
    Alpine c'est bon, très bon, mangez en.

    Merci pour ce journal, court mais passionnant !

  • # Et pendant ce temps la a vera cruz

    Posté par  . Évalué à 4.

    Et sous pretexte que c'est écrit en un langage qui n'est pas dans le basesystem, on réinvente la roue encore une fois !

    Je rappelle juste qu'OpenBSD utilise sa propre implémentation de pkg-config en perl :
    http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/pkg-config/
    Premier commit em 2006, utilisé par défaut a la place de celui de fd.o depuis OpenBSD 4.1.. ca fait plus de 5 ans :)

  • # ya ka supprimer la glib

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

    Et pourquoi ne pas supprimer toutes dépendances à glib dans pkg-config ?
    Qui a t'il dans cette bibliothèque qui la rende à ce point indispensable ?
    Les devs ne savent plus se contenter de la glibc ?

    • [^] # Re: ya ka supprimer la glib

      Posté par  . Évalué à 2.

      Bah, tu peux facilement le voir avec un coup de readelf --symbolswhich pkg-config| grep 'UND g' par exemple. En clair, elle utilise ce que la glib fait, et que la glibc ne fait pas : tables de hachage, listes chaînées, et autres joyeusetés. De plus rendre l’utilisation de la glibc obligatoire rajoute une dépendance (par rapports aux autres libc, pour les autres fonctions utilisées dans la glib, comme l’analyse des arguments).

Suivre le flux des commentaires

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