Journal CMake dans KDE

Posté par  (site web personnel) .
Étiquettes : aucune
0
16
avr.
2006
Ok pour l'instant c'est pas officiel, mais le build system de KDE va etre completement reecris pour CMake (pour l'instant seulement kdelibs l'est) ! Apres un essai de scons, les dev de KDE se sont heurtes a un manque complet de reaction de la part des dev de scons. CMake de son cote a ete jusqu'a diffuse une version CMake special KDE !
La version 2.4 va bientot sortir (qlq semaines), avec notamment l'ajout de CPack.

Refs:
http://aseigo.blogspot.com/2006/03/get-cozy-with-cmake.html
http://planetkde.org/
http://www.kdedevelopers.org/node/1928
http://mail.kde.org/pipermail/kde-buildsystem/2006-January/0(...)
http://www.na-mic.org/Wiki/index.php/NA-MIC/Projects/NA-MIC_(...)

Nightly testing:
http://public.kitware.com/dashboard.php?name=kde

Lien off:
http://www.cmake.org

CMake rules !

  • # Enorme

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

    J'hésitais jusqu'à maintenant à utiliser CMake, son usage n'étant pas assez répandu pour garantir sa pérenité. Avec KDE, plus aucun doute ne subsiste, c'est génial!
    CMake est à mon avis beaucoup plus pratique à utiliser que la concurrence. Il ne manque plus qu'une doc bien faite et un plugin eclipse, et je serai le plus heureux des developpeurs!

    • [^] # Re: Enorme

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

      C'est vrai CMake c'est comme un nouveau langage a apprendre ca prend du temps. Enfin des que KDE sera convertit y'aura un 'real world example' (de memoire KDE est le plus gros projet en comptant le nombre de lignes).

  • # CMake sadness

    Posté par  . Évalué à 4.

    C'est le titre d'un des billets[1] d'Aaron.
    Un billet dans lequel il se plaint de CMake.

    La n'est pas le plus important, comme il le dit lui-meme, la migration autoTRUC vers CMake est douloureuse mais necessaire.

    Non, ce qui est interessant de noter, c'est un des commentaires dans lequel un courageux anonyme se demande pourquoi utiliser CMake alors qu'il existe qmake...

    Je trouve que c'est en effet une question qui merite d'etre posee.
    Quelqu'un a la reponse ?

    [1] http://aseigo.blogspot.com/2006/04/cmake-sadness.html

    • [^] # Re: CMake sadness

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

      Enfin pour n'importe qui qui fais un peu de prog, ca arrive ce genre d'incident. Ca me surprend d'ailleurs un peu vu qu'il y a un nightly et continuous testing de la compilation...

      Au passage Scribus est aussi passer (non off) en CMake

      [Success: Scribus 1.3.x cvs and CMake]
      http://public.kitware.com/pipermail/cmake/2006-April/008847.(...)

      • [^] # Re: CMake sadness

        Posté par  . Évalué à 3.

        Bien sur que ca arrive qu'une nightly soit cassee de temps en temps. C'est fait pour ca (enfin, c'est fait pour detecter quand ca casse, c'est pas fait pour etre cassee tous les 4 matins).

        Ce qui est rageant (vecu inside) c'est:
        - quand la nightly est cassee a cause des outils de compilation,
        - quand on ne peut pas developper parce que les outils de compilation sont casses,
        - quand on perd du temps a reparer les outils de compilation,
        - ...

        Mais apparemment les gens de CMake sont rapidement sur le coup.

    • [^] # Re: CMake sadness

      Posté par  . Évalué à 1.

      Franchement, qmake est sympa, bien pratique, mais quand même assez limité : il est très bien pour de petites bibliothèques ou de petits programmes, mais pour quelque chose d'aussi gros que KDE... et dès qu'on veut faire quelque chose d'un peu exotique, ce n'est pas possible.

      Il n'est par exemple pas possible de définir des commandes post-compilation, pour copier les fichiers de traduction à côté du binaire (s'il est généré dans un autre répertoire).

      L'autre question, plus intéressante, c'est pourquoi Trolltech ne l'améliore pas pour KDE ?

      • [^] # Re: CMake sadness

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

        L'autre question, plus intéressante, c'est pourquoi Trolltech ne l'améliore pas pour KDE ?

        Euh... il sont peut être un peu occupé ?

        Qt Designer,
        Qt Assistant,
        QMake,
        Qt Linguist,
        moc,
        uic,
        rcc,
        qtconfig,
        qtopia

        et ... humm... ah oui, leur petit framework QT.

  • # courageux

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

    Il me semble que les devs du projet KDE sont hardis et n'hésitent pas à changer leurs méthodes et outils de travail pour augmenter leur productivité.
    Ils ont migré vers Subversion alors que Gnome reste avec CVS et maintenant ils migrent vers CMake alors qu'ils sont en pleine transition vers Qt4/KDE4.
    Chez Gnome après le gros passage vers GTK+ 2 ils sont plus dans une optique d'améliorations lentes et incrémentales en gardant les mêmes outils.
    C'est marrant de voir que tous les oppose...et que c'est tout bénéfice pour le choix des utilisateurs !

  • # Pour ceux qui ne saisissent pas tout...

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

    Pour ceux qui comme moi ne saisissent pas tout à cette guerre d'outils de compilation, CMake serait le remplacement de Make.

    Avantage principal : fonctionne sur plusieurs plateformes.
    Sinon : syntaxe plus agréable pour le débutant

    Quelques liens :
    - http://www.cmake.org/HTML/About.html (anglais)
    - http://yansanmo.no-ip.org/412

    J'ai tout compris ?

    • [^] # Re: Pour ceux qui ne saisissent pas tout...

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

      Plus exactement, je dirais que c'est un remplaçant du couple autotools+make, tout comme SCons.

      C'est vrai qu'on peut reprocher plein de choses aux autotools, mais je ne crois pas que ces alternatives soient meilleures, elles utilisent les mêmes principes, il n'y a pas vraiment de révolution en la matière. La recette : un langage suffisament universel (M4 pour les autotools, python pour SCons, un home-made pour CMake) et une tonne de script pour gérer tous les cas.

      L'avantage et en même temps l'inconvénient des autotools+make, c'est que tout le boulot est partagé entre plusieurs programmes et que des fois, on ne sait plus trop lequel fait quoi. C'est bien parce qu'on peut utiliser une partie sans utiliser le reste (par exemple, on peut utiliser make sans les autotools), l'inconvénient, c'est que c'est le foutoir (apparent). Un outil comme SCons ou CMake oblige à sortir une grosse artillerie même pour un hello world. Les petits programmes simples ont souvent fait leur preuve devant les usines à gaz...

      Le seul bon point que je vois à CMake, c'est qu'il peut compiler du LaTeX, alors que SCons m'a l'air très orienté programmation, limite même programmation en C/C++.

    • [^] # Re: Pour ceux qui ne saisissent pas tout...

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

      CMake genere les Makefiles pour toi. Si tu developpe que sous Unix ya pas vraiment grand interet. Si tu fais du cross plateforme (Qt4, KDE), alors ca devient genial, car il fait les dependencies pour toi en C++, C, Fortran, Java et genere donc des Makefiles, NMakefiles, Visual Studio Projects, Borland Makefiles, Cygwin ...
      Mais a la fin t'as toujours besoin de ton bon vieux make ( a noter que les Makefiles genere sont parallel, tu peux utiliser make -jx !)

  • # suxor

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

    Sur http://www.cmake.org/HTML/About.html me saute aux yeux une capture d'écran sous Windows enregistrée en GIF..

    Il faut du courage pour ne pas tout de suite abandonner.

    • [^] # Re: suxor

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

      ...vraiment bonne remarque...
      1. Le patent GIF est expire, il n'a jamais ete applique
      2. CMake est BSD de toute facon

      T'ecris toujours tes Makefiles a la main toi ?

      • [^] # Re: suxor

        Posté par  . Évalué à 1.

        Tu es sur qu'il n'a jamais été appliqué ?

        Je croyais pourtant que c'était pour cette raison que BeOS n'avait pas de support natif du format GIF.

        BeOS le faisait il y a 20 ans !

    • [^] # Re: suxor

      Posté par  . Évalué à 10.

      Moi j'ai décidé de plus payer mes impots parce que le site du ministère des finances fout ses images en gif, et que c'est pas compatible avec mes convictions.

  • # Explications de la part du developpeur de BKsys

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

    La page web de BKsys:
    http://www.freehackers.org/~tnagy/bksys.html
    dommage le lien est down actuellement.

    http://blog.openwengo.com/index.php?/archives/15-SCons,-the-(...)

    On the BKsys webpage you can read now:
    I was then encouraged in 2005 to start porting kdelibs to bksys (the project has about 1500 cpp files). Then the following issues became obvious:

    * Scons does not scale for large projects - startup time used to take more than 50 seconds on fast computers for only 1/3rd of kdelibs. And that amount of time becomes only bigger as source files are added, showing a nasty non-linear trend.

    This is exactly the problem that we encounter on WengoPhone using SCons.

    Finally The kde developers were in a hurry and decided in February to use Cmake instead of bksys/scons. [...]
    Last November, I have decided to start an experimental branch of scons called "waf" [...] I ended up rewriting scons from the ground, starting a brand new branch.
    [...]waf should be ready for production in mid-2006

  • # Un manque complet de reaction de la part des dev

    Posté par  . Évalué à 5.

    C'est le cas d'Automake aussi, notre compatriote et mainteneur d'Automake ne semble intéressé que par résoudre les bugs! J'ai proposé un patch très simple pour ajouter un système de plug-in. Je m'en sert par exemple pour avoir le support de SWIG. C'est pas très propre. Mais de toute façon les Autotools ne le sont pas! Par contre ça permet d'ajouter facilement le support de son langage sans avoir à patcher le code officiel. Comme j'ai pas le temps ni l'envie de forker Automake, je suis le seul à m'en servir ... Vivre le libre. C'est vraiment dommage que SCons ne prenne pas la relève, parce que franchement sh + m4 + make, c'est de la grosse bidouille! Et je préfère installer Python que d'avoir des tonnes de logiciel qui implémente leurs propres langages, leurs clones de la STL, de la libc ... Cette manie me sidère, c'est une grave erreur de conception.

    • [^] # Re: Un manque complet de reaction de la part des dev

      Posté par  . Évalué à 4.

      Ouaip, le probleme c'est qu'apparemment SCons n'arrive pas a gerer une base de code aussi grande que le module kdelibs.

      Moi aussi ca me semble plus sein de ne reposer que sur du "bete" code python mais apparemment, il ne faut pas esperer une trop grand reactivite du cote de SCons.

      Je suis egalement un peu dubitatif quant a CMake.
      Cela ressemble grandement a CMT, qui a lui aussi sa "syntaxe" pour produire des Makefiles (a la volee).
      A mon humble avis, utiliser un langage que beaucoup de monde connait est quand meme une idee loin d'etre completement idiote...

      • [^] # Re: Un manque complet de reaction de la part des dev

        Posté par  . Évalué à 5.

        Le développeur principal de scons c'est rendu compte du manque de réactivité du mode de développement de scons.

        Il a décidé de le réorganiser pour le rendre plus réactif.
        - Un nouveau système de test unitaire va être mis en place, afin d'éviter toute régression.
        - Des responsables pour les différents modules (latex, pdf, msvc, hp-ux etc...) vont être identifiés, et seront associés à une équipe QA. L'intégration de nouveaux outils s'en trouvera facilité.

        sur le wiki de scons on peut trouver la page suivante qui décrit le processus, et le partage des taches.

        http://www.scons.org/cgi-sys/cgiwrap/scons/moin.cgi/SconsDev(...)

        Cela laisse présager du meilleur pour la suite de scons, Ne reste plus qu'à participer.

        Bonne soirée

      • [^] # Des cas d'utilisation très différents

        Posté par  . Évalué à 1.

        Scons est destiné à répondre avant tout aux besoin des build masters: construire des logiciels proprio sur un grand nombre de platformes, utiliser le système de gestion des sources, effectuer les tests de non-régression, etc. La compilation incrémentale est donc un objectif secondaire et les innovations doivent rester compatibles avec les anciennes versions de scons.

        Maintenant, rien n'empêche qui que ce soit de développer sa propre branche de scons pour répondre à ses propres besoins, par exemple:
        http://freehackers.org/~tnagy/bksys.html

Suivre le flux des commentaires

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