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(...)
Journal Qt Creator 1.2 & Qt 4.5.2
25
juin
2009
# Mingw ain't dead
Posté par GeneralZod . Évalué à 10.
http://sourceforge.net/forum/forum.php?forum_id=969885
[^] # Re: Mingw ain't dead
Posté par tom120934 . Évalué à 2.
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 Troy McClure (site web personnel) . Évalué à 5.
[^] # Re: Mingw ain't dead
Posté par tom120934 . Évalué à 6.
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 GeneralZod . Évalué à 2.
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 tanguy_k (site web personnel) . Évalué à 10.
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 Gniarf . Évalué à 3.
[^] # Re: Mingw ain't dead
Posté par tanguy_k (site web personnel) . Évalué à 4.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.