Journal (troll du vendredi) Configuration à l'envers ?

Posté par  .
Étiquettes : aucune
0
7
sept.
2007
Cher journal,

je me pose une grande question existentielle, les grands Gourous de Unix, qui sont toujours sages et bons, conçoivent normalement leurs systèmes de la façon la plus efficace possible.

Pourtant si on doit compiler des sources un peu longue, quand on lance le configure il teste en premier si on a gcc, ensuite si on supporte tel truc ou tel autre de base etc. Ensuite si par exemple on a besoin de QT il teste si QT est là, et zut paf, il manque de nouveau une dépendance, alors on installe cette dépendance, retest complet, test de QT, ça passe, puis au bout d'un long moment à poireauter devant la machine, test de KDE-lib, toujours pas là, installation etc

Est-ce que cela dépend d'autoconf ou des développeurs de toujours faire cela dans cet ordre, car si sur la plupart des machines où on doit compiler on a généralement les paquets de base, en revanche on n'a pas toujours les bibliothèques un peu spécifiques au logiciel (j'ai cité QT mais cela aurait pu être socket6-perl-random ou python-soja-ncurses), et justement ce sont toujours celles-ci qui sont demandées en dernier, ce qui augmente l'attente pour rien !!

  • # Logique

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

    Ca dépend d'autoconf, oui. Déjà que c'est un bordel inommable de faire des trucs simples avec les autotools (M4, anyone ?), alors on va pas s'amuser a redefinir les macros de base pour changer ce genre de trucs.

    Et puis quelque part, je trouve ca normal de tester si les murs de ta maison sont la avant de regarder si t'as accroché le bon tableau. Surtout quand le temps de lancer le configure représente une infime portion du temps total de compilation.

    Et je rajoute aussi que le boulot de ton système de paquetage est de gérer les dépendances pour toi de maniére à ce que le configure passe du premier coup.

    • [^] # Re: Logique

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

      Surtout quand le temps de lancer le configure représente une infime portion du temps total de compilation.


      C'est du plus en plus faux, il devient de plus en plus courant d'avoir des ./configure plus long que la compilation elle-même, et avec une gentoo c'est très flagrant, nottament avec des petits paquetages/ petites dépendances.

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: Logique

        Posté par  . Évalué à 3.

        En parlant de Gentoo, il y a à ce sujet l'option "confcache" qui permet justement de garder en cache les tests du ./configure.

        Mais en fait, le plus simple est d'utiliser un gestionnaire de paquet pour résoudre les dépendances avant l'installation.

        Et si tu aimes compiler et gerer finement les dépendances, il y a Gentoo (décidement...) !

        Voili voilou...

        PS : question subsidiaire, il y a encore beaucoup de gens qui installent par ./configure && make && make install ??

        • [^] # Re: Logique

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

          En parlant de Gentoo, il y a à ce sujet l'option "confcache" qui permet justement de garder en cache les tests du ./configure.

          Ah chouette je ne connaissais pas, merci :).

          PS : question subsidiaire, il y a encore beaucoup de gens qui installent par ./configure && make && make install ??

          Quand j'étais encore sous slack et que y avait pas de paquets disponibles, ça m'arrivait :p

          ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: Logique

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

      Et puis quelque part, je trouve ca normal de tester si les murs de ta maison sont la avant de regarder si t'as accroché le bon tableau.


      C'est en effet logique, mais avec nos systèmes de gestion de paquets qui gèrent les dépendances, il est plus pratique de dire que tu veux accrocher le bon tableau et il se charge de bâtir ta maison :-)

  • # README

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

    je te conseil ce merveilleux fichier, pas d'attente, info instantané, lecteur par le début ou par la fin, ...

    Un Must-Read de tout *nixien

    /me parti ^^ ===>[]

    • [^] # Re: README

      Posté par  . Évalué à 4.

      oui c'est bien entendu ce que je lis en premier, mais tu crois que toutes les dépendances sont réellement indiquées clairement ? ;)

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

  • # C'est à la charge du programmeur

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

    Autoconf offre différentes macros pour tester la présencer d'une bibliothèque, fonction, symbole, etc. Par contre, le comportement en cas de succès ou d'échec est libre. C'est au programmeur de choisir l'action réalisée, souvent un appel à AC_ERROR() qui va afficher un message et tout arrêter. En stockant le résultat de chaque test, on peut appeler AC_ERROR() tout à la fin. C'est ce que fait un bon configure.ac. Par contre, je sais pas s'il existe des méthodes propres pour le faire. Exemple de configure.ac utilisant des bidouilles pour arriver à ses fins :
    http://software.inl.fr/trac/trac.cgi/browser/mirror/edenwall(...)

    Tous les messages sont affichés d'un coup, et le script s'interrompt une fois tous les messages affichés. Ca marche bien quand les modules peuvent être testés un par un. Exemple : rien ne sert de vérifier que les modules Gnome sont présent si X11 et/ou Gtk sont absents.

  • # Euh ....

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

    Il est effectivement (ironique) plus logique de tester QT avant de vérifié si GCC est installé.

    Comme ca tu as l'erreur : "QT ...... No", tu vas installer tout un tas de truc, te gratter la tête et tout d'un coup ... 'au fait j'ai GCC' ?

    Bref, il me parait bien plus logique de vérifié d'abord si GCC existe (ainsi que les autres trucs de base), pour que le reste puis être testé correctement.

    • [^] # Re: Euh ....

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

      Sans GCC, impossible de compiler un programme en QT et donc vérifier si QT est installé et utilisable.
      Le Configure compile un tas de petits programmes afin de tester la présence/utilisabilité de telle librairie. Comme certaines lib dépendent d'autres et ainsi de suite, ça parrait pas seulement logique de tester dans cet ordre mais c'est également une nécessité.

Suivre le flux des commentaires

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