Sortie de CMake 2.4.1

Posté par  (site web personnel) . Modéré par Nÿco.
Étiquettes :
0
5
mai
2006
Communauté
CMake 2.4.1 vient juste de sortir. Comme d'habitude il apporte son lot de nouveautés et de corrections de bugs.

CMake est un logiciel libre, sous License BSD, qui permet la construction de logiciel indépendamment du système d'exploitation ou du compilateur. À la différence de beaucoup de systèmes de multiplateforme, CMake est conçu pour être employé avec les outils natifs de compilation.

CMake est testé de manière continue grâce a l'intégration avec Dart. À intervalle régulier pendant la journée, CMake est recompilé sur différentes plateformes, et il est recompilé complètement chaque nuit sur toutes les plateformes supportées. À chaque fois les tests de non régression sont exécutés et le résumé est envoyé au serveur Dart. Si la compilation et/ou un des tests échoue un email est envoyé à la personne concernée, trouvée via le cvs log.

Mais la principale nouvelle, c'est surtout que CMake a été choisis par l'équipe de KDE. Après un premier essai avec le système de construction Scons, l'équipe de KDE s'est heurté à des problèmes insolubles. Les problèmes ont été soumis à l'équipe qui proposait CMake et tous ont été réglés de manière très rapide grâce au soutien de l'équipe de développeurs de CMake. Les fichiers de configuration (appelé fichiers CMakeLists.txt) sont employés pour produire des fichiers standard de construction (par exemple, fichiers Makefile sur Unix et projets sous Microsoft Visual Studio). CMake peut compiler le code source (C, C++, Fortran, Java), créer des bibliothèques (statique et dynamique avec gestion des dépendances), produire des exécutables (support des WinMain sous Win32 et Bundle sous MacOSX, ainsi que les « universal binaries »). CMake supporte les constructions en place et externe au répertoire contenant les sources, et peut donc soutenir des constructions multiples de répertoires de source. CMake supporte aussi les constructions parallèles (make -jx). CMake supporte aussi via son langage de script: SWIG, Latex, Qt...

Liste des environnements supportés :
  • Makefile (*nix systèmes)
  • Visual Studio 6/7/8
  • NMakefile
  • Borland Makefile
  • MingW Makefile
  • MSYS Makefile
  • Cygwin Makefile
  • Wacom Makefile
  • XCode (1.5 et 2.x)

CMake fonctionne sous :
  • GNU/Linux
  • FreeBSD
  • AIX
  • SunOS
  • IRIX/SGI
  • Darwin (MacOSX)
  • HP-UX
  • Microsoft Windows

Aller plus loin

  • # ObjC / Framework / MacOS X / GNUstep

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

    > CMake peut compiler le code source (C, C++, Fortran, Java) ...
    >....
    > produire des exécutables ....et Bundle sous MacOSX, ainsi que
    >les « universal binaries »

    Plusieurs questions :
    - Est-ce que Objective-C est supporté ? ( a priori oui si on peut faire des bundles )
    - Est-ce que les bundles et les "universal binaries" sont supportés hors MacOSX ( c.a.d. GNUstep )
    - Est-ce que les frameworks ( au sens MacOSX / GNUstep ) sont supportés
    - Est-ce que cmake support Objective-C++ ( berk )

    En gros est ce que cela peut remplacer gnustep-make ?
  • # à la tinderbox

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

    À intervalle régulier pendant la journée, CMake est recompilé sur différentes plateformes, et il est recompilé complètement chaque nuit sur toutes les plateformes supportées. À chaque fois les tests de non régression sont exécutés et le résumé est envoyé au serveur Dart. Si la compilation et/ou un des tests échoue un email est envoyé à la personne concernée, trouvée via le cvs log.


    Dart est un système similaire aux tinderbox de Mozilla ( http://tinderbox.mozilla.org/ ), à la différence prés que c'est pas à intervalle régulier que les compils sont effectués, mais en permanence. Et gare à celui qui commit et fait echouer une compil, ou fait echouer les tests de performances. le Sheriff veille :-)

    Je trouve que c'est une bonne idée d'utiliser ce genre d'outils (tinderbox ou dart), ça permet de réagir trés vite et d'améliorer la qualité en permanence. D'être toujours sûr qu'une nightly build fonctionne un minimum, afin que n'importe qui puisse tester n'importe quand.
    • [^] # Re: à la tinderbox

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

      "En permanence" comment ca peux marcher. Genre je fais 2 commits (qui sont lies) mais je veux faire deux commentaires differents. Si tinderbox comment a recompiler juste apres le premier commit il va faire du bruit pour rien...
      • [^] # Re: à la tinderbox

        Posté par  . Évalué à 4.

        C'est parce que tu te sers mal des outils de gestion de version. Les commits sont censés être atomiques et faire passer l'arbre d'un état stable à un autre état stable.
        Si tu veux faire deux commentaires différents, mets les un à la suite de l'autre.
        • [^] # Re: à la tinderbox

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

          Ca marche bien dans le cas ou tu n'as qu'un arbre. Mais pour moi tu peux avoir une application qui depende d'une librarie et les deux CVS (ou bien un CVS et un SVN) ne peuvent pratiquement pas etre stable a la meme seconde. Je comprends que c'est un peu special, mais ca m'etonnait que personne n'ai eu le probleme.
      • [^] # Re: à la tinderbox

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

        IMO si les deux commits sont interdépendants, ça ne devrait en faire qu'un. C'est pas comme si on pouvait pas écrire plusieurs lignes dans un commitlog.

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: à la tinderbox

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

          J'ai des images de regression dans un CVS et des tests (C++) dans un autre repository. Effectivement les deux sont dependant mais dans mon cas ils sont physiquement dans deux repository differents...
  • # KDevelop

    Posté par  . Évalué à 3.

    Dans la liste des environnements supportés il manque KDevelop.
    • [^] # Re: KDevelop

      Posté par  . Évalué à 2.

      Je ne pense pas. Il me semble qu'ici "environment supporté" désigne le système de build cible (make & co), et que "Visual Studio" et "XCode" concerne la génération de leurs fichiers projets spécifiques réciproques.
    • [^] # Re: KDevelop

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

      Bien vu ! Autant pour moi...
  • # Question de base

    Posté par  . Évalué à 2.

    CMake est un logiciel libre, sous License BSD, qui permet la construction de logiciel indépendamment du système d'exploitation ou du compilateur. À la différence de beaucoup de systèmes de multiplateforme, CMake est conçu pour être employé avec les outils natifs de compilation.

    En fait ce serait plus à rapprocher de GNU make, des autotools ou les 2 à la fois ?

    (désolé si la question est stupide, pas le temps de regarder + pour l'instant...)
    • [^] # Re: Question de base

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

      Ce serait plutôt des autotools à vue de pif, puisqu'il semble générer le Makefile.
      En tout cas, je vais y jeter un nyeux...

      Yth.
    • [^] # Re: Question de base

      Posté par  . Évalué à 2.

      Celui-ci est surtout à rapprocher de Qmake. Le texte est un peu accrocheur, mais au fond Cmake est toujours un générateur de code, tout comme les autotools.
    • [^] # Re: Question de base

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

      Ca serait plutot autotools+m4. Tu auras toujours besoin de ton bon vieux make. CMake ne fais que generer les Makefiles (avec dependences) pour toi. En gros:

      $ autogen.sh
      $ ./configure
      $ make

      devient:

      $ cmake /chemin/des/sources
      $ make
  • # CMake, KDE-4: meme combat

    Posté par  . Évalué à 1.

    Je suis tombe la-dessus (enfin c'est plutot mon aggregateur qui me l'a lance):

    http://www.omat.nl/drupal/?q=node/65
    http://www.cmake.org/Wiki/HowToBuildKDE4Software

    -> plein de petits trucs sympas pour CMake et KDE...

Suivre le flux des commentaires

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