Commit 2007-03-01

Et oui, ça devait arriver un jour: j'ai fait le portage .NET 2005. Pour vous motiver à passer à ce compilateur, j'ai remarqué des gains CPU jusqu'à 30% sur certains cas tests (apps.qs.tube p.expl) !

Normalement, la version actuelle du source compile toujours avec le .NET 2003, l'ancien python et l'ancien SWIG. Mais je pense qu'il est important de mettre à jour toutes vos libs rapidement (pour Vista). Comptez au minimum 1 journée de travail avec ce guide (et pensez qu'il m'en a fallu 4!).

• gros gain cpu sur certains tests.
• debug beaucoup plus visuel (p.expl. les std::vectors peuvent être vus dans leur intégralité en 1 click de souris).
• STL sécurisée en debug (il y a des asserts très pratiques partout)
• seul compilateur utilisable sous Vista.
• aide MSDN mieux faite (accès au web intégré).
• meilleur respect de la norme C++.
• le syntax highlight est plus beau (il tient compte par exemple des directives de prepro actives).

• Il faut recompiler/installer pas mal de trucs (ou attendre que Luc refasse son package pour les moins motivés).
• Les DLLs de metafor ne peuvent plus être placées à part dans un répertoire exe.local (ceci à cause des “manifest”, voir plus loin). Ce n'est pas un problème.
• Purify 2003 ne marche plus (il faut réinstaller Purify V7).

• Installation des softs:
  • Installer le Visual Studio 2005 (je vous conseille de désinstaller le .NET 2003 avant - la cohabitation est sensée fonctionner mais chez moi, ça n'a pas marché!). Inutile de désinstaller Incredibuild. J'ai juste désactivé le add-on sous 2003 (dans “Agent Settings” à partir du tray icon) avant la suppression et j'ai activé celui de 2005 après installation (même menu). N'installez pas le vs2005 version Express! (cette version gratuite qui est soi-disant une version ou seules les MFC manquent n'est pas directement compatible avec CMake!). Faites un tour également du côté de vos variables d'environement pour supprimer tout ce qui référencie vs2003. Moi, j'y suis allé encore plus bourrin en exécutant un nettoyeur de registre (même pas peur!).
  • Installer le SP1.
• Python 2.5:
  • Désinstallez Python 2.4 et installez Python 2.5 (voir plus bas). En effet, si vous compilez l'interface python de VTK, il vous faut python 2.5 installé pour l'étape suivante.
• Qt & VTK:
  • Il faut réinstaller Qt (vs2005) et recompiler VTK. Pour ce faire, il est impératif d'avoir la dernière version de CMake.
  • Ici déja, il y a un petit problème: Qt utilise des structures de templates que vs2005 n'arrive pas à compiler (avec le SP1 - c'est un nouveau bug et vu les nombreuses corrections du SP1, j'ai pas essayé de le désinstaller). Puisque Qt ne veux pas modifier son source (“c'est pas nous, c'est un bug visual”) et que Microsoft fait son Open Engineering dans la résolution du bug (ce sera fait le mois prochain depuis septembre 2006), il n'y a pas d'autre solution que de patcher manuellement le code (fichiers qmap.h et qhash.h - voir DVD Metafor). [corrigé dans Qt-4.3.0!]
  • Autre problème: si vous utilisez vtk-5.0.2 avec l'interface python, vous allez tomber sur ce bug. Il suffit de rajouter un const dans le source ou ça plante (vtkPythonUtil.cxx). [corrigé dans vtk-5.0.3!]
  • Je n'ai pas essayé de recompiler Qt version non commerciale avec vs2005 (ça semble possible mais encore plus casse-tête qu'avec le vs2003 - en particulier à cause des “manifest” - voir plus loin).
• Conversion du projet .NET:
  • A ce stade, j'ai commencé à compiler le source de Metafor. Pour le projet, vs2005 se charge de faire la traduction des vcproj automatiquement. Il faut juste changer le répertoire de destination des DLLs (à côté de Metafor.exe) et remouliner les projets Qt avec qmake. Pas de problèmes majeurs à signaler mis à part mes beaux itérateurs (ElementIterator) qui ne compilent plus lorsqu'ils sont utilisé dans des boucles std::for_each. J'ai aussi dû modifier certains prototypes de fonctions de mtShapeFunctions et nurbs++ pour que les DLLs fonctionnent.
  • Il est possible que les dépendances de Metafor à mtQt et gengui ne fonctionnent plus (même si elles sont activées). Pour résoudre ça, il suffit de supprimer les 2 projets de la solution, la sauver, fermer le visual, le réouvrir, ajouter les 2 projets et recréer les dépendances.
  • Incredibuild perd un peu les pédales pour les dépendances quand on fait un “full build”. il suffit de relancer le “full build” pour que ca fonctionne.
• Metis:
  • J'ai dû recompiler Metis avec vs2005 parce que l'ancienne version m'envoyait des unresolved symbols à la figure. J'utilise une version 4 modifiée et j'ai fait un projet à la main. Cette version est dispo sur le DVD Metafor.
• Si on lance l'exec Metafor.exe à ce moment, seule la version release fonctionne (mis à part apps.complex - voir plus loin). C'est ennuyeux, surtout que le plantage de la version debug n'est pas claire du tout (ça dit juste qu'un module inconnu a tenté de charger une mauvaise version de la CRT et que je peux contacter l'équipe de développement du programme pour en savoir plus). Le problème est en fait double: il vient d'une part de PetSc et d'autre part de python.
• Python:
  • installez la version Python 2.5 (voir + bas). Ce qui suit est un mémo…
  • Si on recompile python 2.4 en debug avec vs2005, on constate que tout se passe bien jusqu'au moment où on essaye de lancer l'exécutable python_d.exe. On se retrouve avec un problème de signaux. Là encore, les développeurs de python s'en foutent royalement (“c'est la faute à Micro$oft que personne n'utilise donc on corrige pas et on attend le service pack suivant”). En ce qui nous concerne, je nous vois mal attendre 1 an sans debuguer Metafor (ou pire debuguer a coup de ladebug) donc j'ai fouillé le net et j'ai touvé un patch (voir DVD Metafor) qui fonctionne assez bien. Il suffit de patcher pythonrun.c en faisant patch < pythonrun.diff et recompiler tout. Ouf! [corrigé dans Python-2.5!]
  • Reste à utiliser un python release compilé avec vs2005 sinon tout marche sauf PyRun_SimpleFile (voir cet article). Symptome: apps.complex plante… Recompilez python24.dll et écrasez brutalement c:\windows\system32\python24.dll (ou arrangez vous pour que votre Metafor charge celui-là. Ouf bis!
• PetSc:
  • PetSc doit impérativement être recompilé avec le vs2005 et ce, pour une sombre histoire de “manifest”. En qq mots, vs2005 utilise un fichier XML appelé “manifest” pour connaître la bonne version des CRT à charger lors de l'exécution d'une DLL ou d'un EXE. Ce fichier peut être inclus dans le produit du link ou être un fichier séparé (p.expl. mtFEM.dll.manifest). Il est d'ailleurs possible d'obtenir de magnifiques plantages très vraiés en modifiant ce fichier à la main). Chaque bibliothèque doit donc avoir son “manifest” pour charger la bonne CRT. Microsoft explique que ça permet plein de trucs, entre autres ca règle les conflits de DLL (le fameux DLL Hell) ou l'installation “locale” d'une application sans privilèges administrateur (mieux vaut tout de même avoir les connaissances d'un administrateur pour le faire)… Pour ce qui nous concerne, ça se rémume à “PetSc n'a pas de manifest, donc PetSc va tout faire planter” (en debug seulement - je sais pas pourquoi). Il faut donc recompiler PetSc avec vs2005 alors qu'il n'a pas été prévu pour ça. En pratique, c'est simple mais comme chaque tentative est très longue, c'est très très long (près de 3h sur mon PC)!
  • Utilisez mon fichier de config garfield4.py (sur le DVD Metafor). J'ai un petit mémo qui détaille la procédure. J'ai utilisé la toute dernière version (2.3.2p8) mais le source reste compilable avec la version 2.3.0 (à l'aide de qq #ifdef).

• Tant qu'on y est, on peut passer à Python 2.5.
• Luc a transformé l'opti pour utiliser NumPy au lieu de numarray (obsolete).
• Pour passer à Python 2.5, il suffit de désinstaller les packages que vous avez installés (numarray, etc), désinstaller Python-2.4 (et supprimer les DLLs de python qui trainent un peu partout). N'oubliez pas votre version debug. Ensuite, installez les binaires Windows.
• Pour la version debug, téléchargez les sources. Vous pourriez penser naïvement qu'il faut utiliser le projet PCbuild8 spécialement fait pour vs2005… et bien non: il est incomplet - il manque le fichier ..\Modules\_typesmodule.c dans pythoncore (voir ici) et _socket est absent!. Utilisez donc le projet vs2003 PCbuild et compilez pythoncore et _socket.
• Modifiez votre projet (y compris le .pro de mtQt) et compilez Metafor.
• Noubliez pas également de renommer vos DLLs python (celles qui commencent par un underscore dans wrap) en .pyd au lieu de .dll sinon python ne les chargera pas.
• Avant de lancer Metafor, vérifiez que votre PYTHONPATH contient le répertoire PCbuild pour que Metafor debug trouve _socket_d.pyd.
• Attention: les accents provoquent une erreur fatale si on ne met pas une entête aux fichiers .py. J'y suis pas allé par 4 chemins: j'ai ajouté l'entête à tous les fichiers .py. Voici la fameuse entête:

# -*- coding: latin-1; -*-

et voici l'erreur en question:

SyntaxError: Non-ASCII character '\xe9' in file 
e:\dev\oo_meta\..\oo_nda\intelSig\tests\xfem\mooney4fast.py on line 135, 
but no encoding declared; see http://www.python.org/peps/pep-0263.html for details

• Ce brave vs2005 m'a permis de trouver un bug dans MeshPointDetector.
• Bug ArcProjectionOperator trouvé par Luc en compilant avec gcc 4 sur calimero (arrondis non gérés).
• La compilation en debug sous Unix fonctionne à nouveau
• Bug dans le conservatif corrigé (voir screenshots).

• Pour ceux qui veulent profiter de la mise à jour du compilateur pour changer de SWIG, c'est possible (pas obligatoire). J'utilise actuellement SWIG-1.3.31.

• Dans votre projet, je vous conseille de renommer l'extension des dll d'interface SWIG en pyd (expl: wrap/_mtGlobal.pyd à la place de wrap/_mtGlobal.dll). C'est la norme et l'extension .dll ne fonctionnera plus avec python 2.5!
• Ajoutez ceci dans votre meta_config.h:

#if !defined(_CRT_SECURE_NO_DEPRECATE)
#define _CRT_SECURE_NO_DEPRECATE
#endif

Exemple de problème au runtime:

Mes options:

— Romain BOMAN 2007/03/01 10:11