Journal Qt Creator 1.2 & Qt 4.5.2

Posté par (page perso) .
Tags : aucun
14
25
juin
2009
Un petit journal pour vous informer que l'IDE (1) multiplateforme Qt Creator 1.2 vient de sortir. http://labs.trolltech.com/blogs/2009/06/25/qt-creator-12-rel(...)
Ce petit bijou supporte désormais Visual C++ et cdb (le format de debug de Visual C++) en plus de GCC et GDB, ce que aucun autre IDE OpenSource ne sait faire à ma connaissance.
L'intérêt : MinGW est franchement à la ramasse par rapport à Visual C++ (performance, debuggage, 64bits, vieille version de GCC 3.x, pas mal de bugs...)

Qt 4.5.2 vient également de sortir http://labs.trolltech.com/blogs/2009/06/25/qt-452-has-been-r(...)
Que des corrections de bugs. La grande nouveauté est l'intégration pour la première fois de patchs provenant de développeurs extérieurs à Nokia grâce au passage de Qt sur gitorious.
32 merges extérieurs sont actuellement en attente pour review sur http://qt.gitorious.org/qt/qt/merge_requests
Une vrai communauté de développeurs en plus de Nokia est en train de naitre. Je rêve que des développeurs s'attaquent au portage sous IPhone (et Android) en plus de S60 et WinCE. Je ne suis pas sur que Nokia fasse le boulot pour porter Qt sous IPhone :)

(1) http://fr.wikipedia.org/wiki/Environnement_de_d%C3%A9veloppe(...)
  • # Mingw ain't dead

    Posté par . Évalué à 10.

    L'équipe Mingw a sorti une version de sa chaine de compilation basé sur GCC 4.4.0 il y a 2 jours. Et il y a toujours eu des builds non-officiels de basé sur GCC 4.x et qui marchaient très bien.
    http://sourceforge.net/forum/forum.php?forum_id=969885
    • [^] # Re: Mingw ain't dead

      Posté par (page perso) . Évalué à 2.

      Quid du 64 bits ? Je me suis confronté il y a peu à la compilation sous win 64 (pas de build Yafaray dispo sur cette plateforme)

      Entre les dépendances basiques (pthread, zlib, libjpg...) pas dispo en 64bits (ou alors bien cachées sur le net) et l'absence de plate-forme unifiée (make de VC++, make GNU via MinGW, scons etc...) j'ai vraiment été surpris de la galère que c'était. J'ai alors compris pour il n'y avait pas tant de builds win64 que ça ;)
      • [^] # Re: Mingw ain't dead

        Posté par (page perso) . Évalué à 5.

        l'autre raison c'est que sauf cas particulier (genre besoin de beaucoup de ram) un build 64-bit n'apporte rien sous windows puisque les applis 32-bit fonctionnent très bien, contrairement à linux ou il faut faire l'effort d'installer les paquet "ia32-libs-*" et où les utilisateurs ont souvent des attitudes très tranchées "ouin je veux un systeme 100% 64-bit"
        • [^] # Re: Mingw ain't dead

          Posté par (page perso) . Évalué à 6.

          sauf cas particulier (genre besoin de beaucoup de ram)

          Je pertinente, mais c'est bien le souci sur de gros modèles 3D avec plusieurs millions de polygones.
      • [^] # Re: Mingw ain't dead

        Posté par . Évalué à 2.

        Effectivement, les plateformes 64 bits sont le talon d'achille de Mingw et le peu de popularité de Windows 64 n'aide pas.
        Néanmoins, le projet mingw-w64 offre déjà une chaine de compilation minimale, reste à améliorer le port (notamment la partie WinAPI/DDK) et les paquets externes.
        D'après le mainteneur de Mingw dans Fedora, il y a encore pas mal de trucs à régler pour que Mingw64 soit utilisable en production, même si le minimum syndical est déjà présent.


        http://mingw-w64.sourceforge.net/
      • [^] # Re: Mingw ain't dead

        Posté par (page perso) . Évalué à 10.

        l'absence de plate-forme unifiée (make de VC++, make GNU via MinGW, scons etc...)

        Pour bien comprendre, à la base il y a les Makefile bas niveau format GNU ou VC++ qui sont donc dépendant d'une plateforme/compilateur.
        SCons, CMake, Waf, QMake... sont des systèmes de compilation haut niveau multiplateforme. CMake et QMake par exemple génèrent des Makefiles au format GNU et VC++ alors que SCons et Waf reimplementent tout en Python.

        La première étape est donc d'utiliser un système de compilation multiplateforme. Mon préféré est CMake (SCons est beaucoup trop lent et j'ai jamais utilisé Waf, encore trop jeune surement). Il faut penser le truc suffisamment adroitement pour pouvoir désactiver des librairies et des bouts de code suivant la plateforme. Les fichiers de build ainsi que le logiciel lui-même seront donc pensés de manière assez modulaires.

        La deuxième étape est d'utiliser un langage multiplateforme et des librairies multiplateformes -> pour du C++ l'idéal est donc Qt qui permet de limiter le nombre de dépendances. Boost aussi est assez sympa pour le multiplateforme.

        La troisième étape (facultative) est de mettre en place un Buildbot qui recompile automatiquement pour toutes les plateformes et génère les binaires.

        Sur le repo, de mon point de vue, toutes les petites librairies (genre zlib, TinyXML...) sont intégrées dans un répertoire 3rdparty et recompilées en utilisant le système de build du logiciel (par exemple CMake). Pour les grosses bibliothèques manquantes sur une plateforme, l'idéal est de commiter les versions binaires (en les mettant à jour régulièrement bien sur). L'idée est de centraliser le bordel et de pouvoir effectuer un checkout sur un PC neuf sous n'importe quel OS/compilo sans devoir installer 10 librairies externes avant de pouvoir compiler le logiciel en question.

        Bref porter sous Windows une appli Linux C/C++ qui a pas mal de dépendances et qui n'a pas été pensé pour dès le départ, c'est chaud car sous Windows rien n'est livré avec l'OS et le compilo. C'est principalement le cas pour les applis GTK+ qui se tapent énormément de dépendances en plus de GTK+ (glib, xml, dbus, sql...)

        Bien choisir ces outils et librairies permet d'adresser Windows qui accapare ~90% des utilisateurs, bref ca vaut le coup. Firefox et OpenOffice.org n'auraient pas eu le succès qu'on leur connait s'il n'existait pas de version Windows.

        Ouai je sais je parle trop, j'avais envie :-)
        • [^] # Re: Mingw ain't dead

          Posté par . Évalué à 3.

          un détail typique est qu'on se retrouve vite fait avec un build de GTK pour The Gimp, un pour Inkscape, un pour Dia, un pour Pidgin, un pour Gajim, un pour SongBird, un pour ...
          • [^] # Re: Mingw ain't dead

            Posté par (page perso) . Évalué à 4.

            on se retrouve vite fait avec un build de GTK pour The Gimp, un pour Inkscape [...]

            Comme pour les applications qui utilisent Qt sous Windows, c'est la philosophie de l'OS. Jusqu'à récemment (VC++ 2005) même la libc et la libc++ étaient livrées avec chaque application. Je crois que c'est même encore le cas pour les MFC. http://en.wikipedia.org/wiki/DLL_hell
            Les applications qui utilisent le framework .NET sont en revanche + ou - épargnées.

Suivre le flux des commentaires

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