pourquoi virer autotools ?

• [^]Re: pourquoi virer autotools ?

  Posté par gnumdk (page perso, ) le 17/03/2005 à 19:58. (lien). Évalué à 0.

  Si ils virent autotools, c'est pour utiliser un truc mieux foutu et codé par un mec de Kde. Parce que bon, autotools...

  --
  Agogo

  • [^]Re: pourquoi virer autotools ?

    Posté par udok () le 17/03/2005 à 20:12. (lien). Évalué à 1.

    merci à toi et à Seb
    
    bon l'interet d'autotools c'est d'harmoniser cette tache entre les différents programmes
    je suis conscient que c'est pas parfait, mais plutot que de réinventer la roue à chaque fois qu'un truc ne va pas dans un logiciel (ça arrive souvent qu'il existe bcp de prog pour faire la même chose ... alors le choix c'est bien mais faut pas que ça empeche d'unir les forces en présence)
    je critique pas la (future) démarche de l'équipe kde (je me permettrais pas vu mon niveau), mais n'était-il pas possible/préférable de faire évoluer autotools plutot que de refaire un équivalent, ce qui va nuir à l'harmonisation dans ce domaine (et accessoirement emmerder debian)

    • [^]Re: pourquoi virer autotools ?

      Posté par Superted () le 17/03/2005 à 21:56. (lien). Évalué à 4.

      n'était-il pas possible/préférable de faire évoluer autotools
      Les autotools sont d'un complexité incroyable. C'et typiquement le genre d'outils qui semble avoir évolué de manière démeusuré et tentaculaire depuis trop longtemps. Le seul problème avec c'est que ça marche ;-).
      Parce que au final c'est chiant à utiliser mais ça permet de distribuer des sources qui vont pouvoir être compilés sur pleins de plateformes, ce qui est génial ! Mais c'est tellement énorme comme truc que le modifier pour en faire quelque chose de simple c'est pas réellement possible.
      Mais avoir un autre outils aussi puissant et plus élégant ne serait pas un mal.
      
      Pour faire un parallèle ça me rappele sendmail qui est lui même très puissant, mais complexe à configurer.

      [^]Re: pourquoi virer autotools ?

      Posté par Philippe Fremy (page perso, ) le 17/03/2005 à 22:59. (lien). Évalué à 8.

      Disons que vue la complexite d'autotools, je passe moins de temps a faire un support en live pour des config exotiques qu'a essayer de faire marcher ce bousin.
      
      Pour te repondre, je te redonne un bon dicton d'informaticien: "Il ne faut pas reinventer la roue. Sauf quand le premier inventeur a invente une roue carree".
      
      autotools, c'est clairement une roue carree. C'est un arrachage de cheveux a maintenir. Parmis les milliers de contributeurs et parmi la quarantaine de developpeurs principaux de KDE (qui ont un sacre niveau en informatique), il y a en tout et pour tout deux developpeurs qui comprennent completement le systeme des autotools utilise par KDE et qui sont capables de le maintenir. Ca ne fait pas beaucoup.
      
      Les developpeurs de KDE ne prennent pas des decisions techniques a la legere. Si ils se debarrassent d'autotools, c'est que ce n'etait plus gerable.
      
      Il y a des super projets pour remplacer autotools, qui ont tous la caracteristiques d'etre simple a utiliser et simple a faire evoluer. Deux qualite qui manquent terriblement a autotools. Je peux te dire que le type qui s'occupe d'autotools pour KDE (il me semble que c'est Stephan Kulow) est super motive pour utiliser autre chose, pour te donner une idee du truc.
      
      Scons semble etre une alternative interessante. Il y en a d'autres. Pourquoi se prendre la tete avec un systeme super complexe quand des alternatives plus simples existent.
      
      Faut pas etre trop sentimental. Autotools etait une bonne solution au moment ou il a ete cree, mais aujourd'hui, l'outil ne fait plus le poids. Avoir python ou perl installe sur sa machine n'est pas une contrainte extraordinaire alors qu'a l'epoque ou autotools a ete cree, sh etait la seule dependance acceptable.
      
      
      Par exemple, je suis toujours choque que ./configure ne detecte pas les erreurs de syntaxes dans ses options:
      
      ./configure --enable-truc-muche ne te renverra aucune erreur. Sauf que en fait, il fallait taper:
      ./configure --enable-trucmuche
      
      Et encore, ca c'est un probleme mineur d'utilisateur, rien a voir avec la complexite de la mise en place du truc.

      --
      phil.freehackers.org

      • [^]Re: pourquoi virer autotools ?

        Posté par fabb () le 17/03/2005 à 23:36. (lien). Évalué à 1.

        > Disons que vue la complexite d'autotools, je passe moins de temps a faire un support en live pour des config exotiques qu'a essayer de faire marcher ce bousin.
        > il me semble que c'est Stephan Kulow
        
        J'ai l'impression que les gens s'emballent pour rien. Si c'est pour unsermake, il ne remplace "que" automake.
        - "Unsermake is a replacement for automake by KDE developer Stephen Kulow."
        - "Unsermake replaces automake but keeps everything else, including the strange Makefile.am syntax the same."

        • [^]Re: pourquoi virer autotools ?

          Posté par fabb () le 18/03/2005 à 00:13. (lien). Évalué à 1.

          Oubliez ce commentaire, il semble que unsermake est déjà utilisé.

          • [^]Re: pourquoi virer autotools ?

            Posté par Philippe Fremy (page perso, ) le 18/03/2005 à 08:14. (lien). Évalué à 2.

            Oui, unsermake est deja utilise mais ton commentaire est tout a fait pertinent. unsermake ne fait que simplifier une des 12 etapes qui genere les makefile de KDE.
            
            Le but de se debarasser d'autotools, c'est probablement de passer de 12 etapes a 2, et de beneficier en sus d'ameliorations de performances diverses au niveau de la compilation.
            
            Je ne connais pas bien le sujet, mais j'ai entendu dire que le fait que make n'est qu'une vision repertoire par repertoire rend pas mal d'optimisations (distribution de la compilation, blocage de certains morceaux de la compilatino, ...) plutot difficiles.

            --
            phil.freehackers.org

            • [^]Re: pourquoi virer autotools ?

              Posté par Sebastien Binet () le 18/03/2005 à 09:01. (lien). Évalué à 2.

              Moi personnellement, ca ne me gene pas que make ait une vision repertoire par repertoire. Tout ce qu'on attend de lui, c'est qu'il passe les bonnes options de compilation au compilateur pour le package qu'on est en train de compiler, et ensuite qu'il passe au package suivant, non ?
              
              Ensuite, il me semble que la gestion de l'ordre de compilation des paquets, la possibilite de faire de la compilation parrallele (sur plusieurs machines et/ou sur plusieurs paquets) et autres optimisations doit etre efftectuee par une couche au-dessus : CMT, unsermake ou autre.

              • [^]Re: pourquoi virer autotools ?

                Posté par spart (page perso, ) le 18/03/2005 à 15:00. (lien). Évalué à 3.

                > Tout ce qu'on attend de lui, c'est qu'il passe les bonnes options de
                > compilation au compilateur
                
                en fait ce qu'un développeur attend de lui, c'est surtout qu'il ne recompile pas les 3/4 de ton arbre local au moindre changement si ce n'est pas strictement nécessaire.
                
                Avec un make récursif, la gestion des dépendances inter-répertoires est lente et très aléatoire.

        [^]Re: pourquoi virer autotools ?

        Posté par herodiade () le 18/03/2005 à 10:29. (lien). Évalué à 2.

        Juste pour signaler un remplaçant très chouette et qui manque de publicité: pmk. http://pmk.sourceforge.net/(...)
        
        C'est un remplaçant entièrement en C pour autotools, libtool et pkg-config. C'est très éléguant, très rapide, très simple à utiliser, et ça diminue encore les dépendances et les problèmes liés au shell script (par rapport à autotools, ou python pour scons etc.).
        On peut supposer qu'il pourrai facilement être porté sur des plateforme win32 (plus que les shells scripts auto* pour sûr ;) même si ce n'est pas un objectif immediat.
        
        Je serai ravi que plus de developpeurs l'utilisent, en raison de l'objectif principal du projet: être irreprochable sur la sécurité pour l'utilisateur. Ça fonctionne sur la base de fichiers de description (parsés et 'éxecutés' par l'outil en C) avec bien entendu un nombre d'actions et de possibiltés prédéfinies et limités, bien étudiées. Il est censé ne pas permettre de faire des choses dangeureuses.
        
        En effet il ne faut pas oublier qu'un script configure est toujours susceptible de vous installer une rootkit en loucedé (ou jouer avec votre courriel ou ....). Les scripts configure (et libtool) sont très gros et complexes, en pratique très penibles à auditer ; comme c'est du shell script, tout leur est permis. Pensez-y quand vous installez à la main un nouveau logiciel ...

        • [^]Re: pourquoi virer autotools ?

          Posté par Sebastien Binet () le 18/03/2005 à 12:28. (lien). Évalué à 2.

          Je veux pas jouer a celui qui a la plus grosse, hein, on n'est pas la pour ca :)
          mais CMT est ecrit en C++, deja porte sous win32 et solaris (pour solaris je m'avance un petit peu, j'en avais entendu parle, j'ai vu des bug reports, mais...), il me semble qu'il y a aussi possibilite de le scripter via python et une GUI (Visual CMT) est disponible.
          
          CMT lit lui aussi un fichier (habituellement appele requirements) dans lequel tu donnes les dependances aux paquets de ton appli, dans un langage relativement simple :
          use MonPaquet MonPaquet-00-00-01 Chemin/dans/larbo/rescence/de/mon/appli/vers/mon/paquet
          (sur une ligne)
          
          et puis tu lui dis ce que tu veux faire, un shared object, une appli static...
          La syntaxe est relativement simple (meme un physicien un peu bete comme moi peut s'en servir :)
          
          Ensuite c'est juste une affaire de configuration d'un (ou quelques) paquet mere dans lequel tu mets toutes les regles de compilations, les differentes actions que tu peux vouloir faire (creer la doc doxygen, lancer des scripts de pre/post-installation, configurer l'environnement de travail du developpeur (runtime, include paths,...), etc...)
          
          De plus CMT ce n'est pas *que* un programme pour compiler une appli, cela sert aussi a interagir avec ton appli (dans le sens demander quelles sont les dependances de tel paquet, ses clients,...)
          
          C'etait un message a caractere informatif.

    [^]Re: pourquoi virer autotools ?

    Posté par Sebastien Binet () le 17/03/2005 à 20:23. (lien). Évalué à 4.

    codé par un mec de Kde
    
    Un peu de respect quand même ;)
    Ce gars là c'est Stephan Kulow, release manager de KDE...

    [^]Re: pourquoi virer autotools ?

    Posté par Alex () le 17/03/2005 à 20:24. (lien). Évalué à 1.

    Si ils virent autotools, c'est pour utiliser un truc mieux foutu et codé par un mec de Kde.
    
    En fait ils trouvent qu'autotools est trop rude à maintenir, et qu'il est trop dur d'y "renter". Mais a prioris ils vont peut etre utiliser unsermake (par un gars de kde) mais ca sera surement scons ou cmake

    • [^]Re: pourquoi virer autotools ?

      Posté par Pinaraf (Jabber id, ) le 17/03/2005 à 20:42. (lien). Évalué à 6.

      Ils ont parlé aussi de la vitesse de compilation.
      En effet, il semblerait que rien qu'en filtrant l'affichage, on arrive à réduire la durée de compilation de quelques pourcents même sur un PC récent, parce que les console sont très très lentes !
      De plus, un configure qui prend 1 minute à tester 100 trucs ... c'est gonflant, surtout quand il le fait 15 fois !

  [^]Re: pourquoi virer autotools ?

  Posté par Sebastien Binet () le 17/03/2005 à 20:03. (lien). Évalué à 4.

  Je crois qu'ils veulent le(s) remplacer par un truc à eux : unsermake[1].
  
  Après une rapide lecture de la page, ce que j'en conclus c'est qu'ils veulent un peu plus rationaliser et factoriser le processus de compilation : regrouper les options de compilation dans un seul (gros?) Makefile.
  Moins de Makefile disséminés un peu partout dans l'arborescence.
  
  C'est quand même dommage de réinventer la roue avec unsermake : il y a déjà CMT[2] qui existe (quoi je ne vous ai pas encore parlé de CMT? Mais si regardez mes derniers journaux...) et qui est bien dimensionné pour les gros projets.
  
  [1] http://www.kde.me.uk/index.php?page=unsermake(...)
  [2] http://www.cmtsite.org(...)

  • [^]Re: pourquoi virer autotools ?

    Posté par spart (page perso, ) le 18/03/2005 à 15:17. (lien). Évalué à 3.

    Unsermake a été créé suite à un article de Peter Miller[1] pointant les insuffisances de make et plaidant pour un procédé non récursif.
    
    Au début, c'était juste une expérience, mais les gains se sont avérés si substantiels que beaucoup de développeurs l'ont adopté au quotidien.
    
    [1] http://webcvs.kde.org/kdenonbeta/unsermake/doc/auug97.pdf?rev=1.1&view=auto
    

  [^]Re: pourquoi virer autotools ?

  Posté par Croconux () le 18/03/2005 à 07:32. (lien). Évalué à 4.

  donc si ils virent ça, ça risque de poser pb au moins sur debian
  
  Pas forcément. Ce qui emmerde le plus les développeurs c'est tout le bordel de macro M4 absolument imbitable. Pour les mainteneurs de paquets, l'important est de pouvoir modifier les options de compilation, notamment les chemins (--bindir=, --prefix) et activer/désactiver des composants optionels (--with-xxx, --without-xxx). Le packager se fout de savoir avec quoi le script configure a été généré du moment qu'il s'utilise de la même façon (./configure --plein-de-chose && make && make install). Il suffit de garder la même syntaxe pour les commandes et options et de remplacer les truc.in et machin.am par quelque chose de plus simple.

  • [^]Re: pourquoi virer autotools ?

    Posté par Raphaël Gertz (page perso, ) le 18/03/2005 à 13:50. (lien). Évalué à 1.

    Les options nécessaires au packager :
    --enable-something (avec du --with ou autre tant que ça marche)
    --prefix (tout les prefix modifiables, pour mettre les fichiers de conf dans /etc ou autre selon le paquet, etc...)
    et une option pour installer le paquet dans un rep de destination sans se casser la tête a bouger 50 fichiers a la mais parce que le script marche pas...
    
    parce que honetement après le 50ème install --permission en tout genre tagada/src/machin.so RPM/DEB/ETC_ROOT_DIR/bonchemin(tm)/machin.so.bonneversion c'est super lourd!!!
    
    Perso j'aime bien les autotool et ça marche pas mal.
    Et si vous voullez pas vous casser la tête utilisez kdevelop pour créer votre projet avec, d'accord c'est lourd mais ilvous gère tout le bouzin très bien dans la plupart des cas sans se prendre la tête avec les dépendances en tout genre...

    --
    site perso : http://rapsys.free.fr/