Commit 2010-06-13

Modifs

Projet CMake (2/2)

Le projet CMake est maintenant opérationnel. Il remplace dorénavant le projet de Luc et les makefiles Unix générés par autoconf. <html></html> Je vous conseille de prendre le temps de lire attentivement ce qui suit et mettre à jour au plus vite vos sources. <html></html>

Comment ça marche (en gros)?

Je dis “en gros”, parce que l'idéal est de lire le manuel (mais comme vous n'allez pas le faire, je vous traite de “gros”):

Tutorial : A lire!!
CMAke FAQ: quelques réponses intéressantes
Syntax: explication détaillée des listes/strings
CMake 2.8 Docs: la ref complète

En résumé, CMake, c'est simple mais c'est différent. Il vous faut d'abord le programme CMake (inclus dans les futures libs de Luc). Le principe est de créer un répertoire séparé du source dans lequel le projet (ou makefiles sous Linux) et toutes les crasses générées par la compilation (obj, exe, wrap.cpp, etc.) vont aboutir.

Ce répertoire peut être n'importe où et cela peut même être le répertoire source (même si ce n'est pas conseillé). Bref, créez par exemple un répertoire oo_metaB à coté de oo_meta. Ouvrez ensuite une ligne de commande dans oo_metaB (dans l'explorer, c'est “SHIFT-click gauche”, puis “ouvrir une fenêtre de commande ici” dans le menu).

Tapez la commande suivante (rassurez vous, il ne faut le faire qu'une fois):

cmake -C ..\oo_meta\CMake\config_choisie.cmake ..\oo_meta

où config_choisie.cmake est un fichier de config relatif à votre PC. Si vous utilisez mes libs (Arnaud, Vinciane), choisissez garfield.cmake. Pour les libs de Luc, attendez que Luc commite un fichier similaire au mien. Si vous êtes sous Linux (et que vous vous appelez Geoffrey), ça tombe bien, j'ai fait un fichier natacha.cmake qui devrait être +/- bon.

Si vous n'avez pas peur du désordre et que vous ne faites jamais de backups de vos développements (“in-source build”):

cd oo_meta
cmake -C CMake\config_choisie.cmake .

Vous pouvez aussi utiliser comp.py sous Windows. Ca marche jusqu'au moment où il essaye de faire un gmake sur votre solution Visual

Bref, la commande cmake devrait vous créer un premier projet Metafor.sln dans oo_metaB (ou une série de Makefiles sous Linux). Si vous avez des erreurs à ce stade, c'est que le fichier choisi n'est pas bon pour votre installation. Faites le vôtre et modifiez le contenu pour que ça marche (c'est peut être le moment de regarder la doc).

Ouvrez Metafor.sln et travaillez! (ALL_BUILD permet de tout compiler). Pour Geoffrey, un make -j 4 dans oo_metaB compile tout d'un coup avec des belles couleurs. Pour mieux voir ce qui se passe: gmake VERBOSE=1 affiche les lignes de commande pour chaque fichier traité.

Sous Linux, il n'y a qu'un niveau d'optimisation disponible (par défaut Release) par répertoire binaire. Pour compiler en debug, il faut le spécifier lors du moulinage cmake initial:

cmake -C ..\oo_meta\CMake\natacha.cmake -D CMAKE_BUILD_TYPE=Debug ..\oo_meta

On peut donc sans problème avoir 2 jeux de binaires (un debug dans oo_metaD et un release dans oo_metaB par exemple) pour un seul jeu de sources.

Sous Windows, contrairement à un projet visual classique, vous avez ici 4 configs. Seules Release et Debug sont utiles pour le développeur moyen (même si la Debug tend à devenir une config avancée avec le temps). Il serait intéressant de faire aussi des configs permettant le profiling. Ce n'est pas encore fait. Pour les développeurs VTK et ceux qui n'ont pas peur d'un débogueur, la config RelWithDebInfo est très utile puisqu'elle permet de déboguer le code optimisé. C'est celle que j'utilise par défaut.

Metafor.exe est créé dans oo_metaB/bin/config où config est la fameuse config dont on vient de parler. Sous Linux, c'est oo_metaB/bin puisqu'il n'y a qu'une config présélectionnée.

L'exe Metafor n'est donc plus dans oo_meta! C'est voulu! Pour lancer Metafor, double-cliquez sur l'exe. Faites un lien définitif sur votre bureau, c'est + simple.

Utilisation "avancée"

Ajout d'un fichier: Imaginons que vous vouliez ajouter un fichier.

Vous l'ajoutez dans le source (dans le répertoire de la lib en question).
Vous lancez CMake (lancez l'interface graphique, c'est + simple - gmake-gui sous linux)
Vous cliquez sur “Configure” puis “Generate”
Allez sous le Visual.
Faites comme d'habitude: ne lisez pas le popup (mais répondez “non”)
Le Visual recharge la solution (cliquez sur “reload” si des popups apparaissent)
Votre fichier est ajouté!

Attention: CMake ajoute tous les fichiers automatiquement. Si vous avez Powergreppé votre source et que vous avez des “Backup of blabla.cpp”, ils seront ajoutés aussi. Configurez donc vos backups powergrep en “.bak” et ça devrait aller.

Modification des options de compilation: Imaginons que vous vouliez compiler sans l'interface graphique.

Lancez la GUI de CMake
Modifiez l'option (METAFOR_USE_GUI, anciennement _WITH_GUI_)
Remoulinez comme pour l'ajout d'un fichier et votre projet ne devrait plus contenir de traces de VizWin.

Démarrage de Metafor: Vous vous demandez d'où Metafor tire sa force pour retrouver le répertoire apps qui peut être placé à l'autre bout de votre disque:

Toute la procédure d'initialisation de Metafor.exe a été externalisée dans un fichier nommé .pythonrc.py placé à côté de lui.
Si vous déplacez Metafor.exe, il faut impérativement déplacer ce fichier.
Pourquoi ce nom étrange? Il s'agit en fait du nom standard du fichier de startup de python en interactif. Utiliser ce nom permet de lancer Metafor avec un interpréteur python traditionnel et en définssant PYTHONSTARTUP=.pythonrc.py dans ses variables d'environnement. Cette manip. n'est utile que si vous désirez faire du Metafor sous python en interactif.

Batterie

Windows: La batterie se lance à partir de oo_metaB/bin/Release. C'est comme avant: python battery.py tout simplement. Les résultats (.res et verif) sont actuellement envoyés dans le source. Dans un commit futur, je déplacerai les résultats vers oo_metaB/bin/Release pour être cohérent avec la nouvelle manière de faire.

Linux: Le script comp.py a été adapté (il faut le copier de toolbox/comp.py vers ~/bin par exemple). Supprimez vos comp.cfg pour que le script détecte le fichier de config cmake à utiliser.

Le fichier “diff” a été déplacé dans le workspace (dans oo_metaB/bin/Release/workspace).

Modif du source

MTGLOBAL_EXPORTS ⇒ mtGlobal_EXPORTS pour respecter la convention CMake.
Suppression des using namespace dans un .inl et ajout du nom de namespace dans un beau paquet de fichier.
Ajout d'un saut de ligne final dans de nombreux fichiers.
Corrections diverses (suite à un run de chkrep.py)
Suppression de profiles, wrap, makefiles
Ajout de Mesher dans le namespace mtGeo (conflit sur spring et thorgal avec libGLU.so)
Adaptation de comp.py, toolbox/battery.py et les runs “paramétriques”. Sans le vouloir, grâce à la nouvelle manière de faire (via .pythonrc.py), tout a été uniformisé.

Stations

Compilation de cmake 2.8 sur les machines possédant des versions ≤2.4
spirou, gaston: utilisation de vtk-5.6.0. (au lieu de 5.0.3!!)
spirou, gaston: mise à jour de Qt
Suppression du /home/local sur gaston. Ce qui était nécessaire à la version actuelle de Metafor (libmetis, tetgen, triangle) a été déplacé dans /usr/local
Suppression des vieilles libs. Dès que tout le monde a mis à jour, je supprimerai les anciennes versions de vtk.

Mettez à jour votre “profil” Linux. il faut en effet que Qt (qmake) soit dans le PATH pour que cmake détecte correctement les libs installées sur la machine.

CMake - Idées pour la suite

MetaLub sous CMake: pas difficile vu le travail effectué avec Metafor.
Install via CMake (ca s'appelle CPack).
DoxyGen sous CMake.
On pourrait même imaginer faire certains tests sous CMake (ça s'appelle CTest).
Utilisation d'un IDE sous linux (KDevelop, Eclipse). Il suffit d'essayer…
Configs “profiling”
Lien des projets CMake stp2e et Metafor (stp2e serait un sous-projet de Metafor)
Supprimer les warnings qui restent.
etc.

Tables de hachage

Correction des problèmes de perfs liés aux tables de hachage (Grâce à Geoffrey et Luc). Il devrait maintenant être possible de charger des gros fichiers gmsh (ou tetgen) sans attendre des heures.

Tests BoneAniso & co

Je n'ai pas réussi à compiler le matériau de Marlène en /O1 avec CMake (pour rappel, ils merdouillent en /O2). C'est de toutes façons un peu ridicule de commencer à compiler certains fichiers autrement pour éviter de débuguer un problème réel du code. J'ai donc laissé ces tests planter dans la batterie Windows et Linux64 (il y a donc un FAILED et plusieurs qui ont 0 itérations!).

⇒ Il faudrait donc regarder au plus tôt pourquoi ils ne fonctionnent pas (ça doit être un problème d'initialisation ou quelque chose du genre). Peut être qu'en activant les warnings au maximum, il serait même possible de détecter l'erreur sans regarder le code.

Sont concernés:

apps.biomec.toothAnisoDamage 	
apps.biomec.toothAnisoDamage2 	
apps.monosMaterials.evpIsoDamageAnisoAlvBoneRemod2DAxiCis 	
apps.monosMaterials.evpIsoDamageAnisoAlvBoneRemod2DAxiTrac 	
apps.monosMaterials.evpIsoDamageAnisoAlvBoneRemod2DCis 	
apps.monosMaterials.evpIsoDamageAnisoAlvBoneRemod2DTrac 	
apps.monosMaterials.evpIsoDamageAnisoAlvBoneRemod3DCis 	
apps.monosMaterials.evpIsoDamageAnisoAlvBoneRemod3DTrac 	
apps.monosMaterials.evpIsoDamageAnisoBoneRemod2DAxiCis 	
apps.monosMaterials.evpIsoDamageAnisoBoneRemod2DAxiTrac 	
apps.monosMaterials.evpIsoDamageAnisoBoneRemod2DCis 	
apps.monosMaterials.evpIsoDamageAnisoBoneRemod2DTrac 	
apps.monosMaterials.evpIsoDamageAnisoBoneRemod3DCis 	
apps.monosMaterials.evpIsoDamageAnisoBoneRemod3DTrac 	
apps.monosMaterials.evpIsoDamageAnisoDummy2DAxiCis 	
apps.monosMaterials.evpIsoDamageAnisoDummy2DAxiTrac 	
apps.monosMaterials.evpIsoDamageAnisoDummy2DCis 	
apps.monosMaterials.evpIsoDamageAnisoDummy2DTrac 	
apps.monosMaterials.evpIsoDamageAnisoDummy3DCis 	
apps.monosMaterials.evpIsoDamageAnisoDummy3DTrac

Projet

Effacez-le et utilisez CMake! Cette rubrique n'est plus utile.

Fichiers ajoutés/supprimés

Cette rubrique n'est plus utile puisque les fichiers sont ajoutés automatiquement au projet!

Added

— Romain BOMAN 2010/06/13 17:16

Table of Contents