07-Mar-2006

Modifs

• Creation de la version 4 de Metafor.
  • J'ai créé la version 4 de Metafor (oo_meta) et celle de oofelie (il n'y a pas eu de numéro 2 et 3 - c'est juste pour ne pas se casser la tête). oo_nda reste à la version de base. Vous devez migrer vers ce nouveau repository (oo_meta-4 et oofelie-4).
  • Réorganisation complète des fichiers sources pour permettre plus facilement la création des DLLs sous windows. La philosophie est la suivante:
    • un répertoire mtMachin (et éventuellement oeMachin) par projet Visual. Par exemple le projet mtKernel.dll se compose des sources oo_meta/mtKernel et oofelie/oeKernel. grâce à ça, les sources OE sont toujours séparées des nôtres.
    • un minimum de sous répertoires! (j'ai viré par exemple easModes, nurbs, bwoptimethod etc) De nombreux sous répertoires qui ne correspondent pas à de vrais modules (DLLs) ne font qu'encombrer la ligne des rép. d'includes additionnels (on ne s'y retrouve vite plus du tout). Libre à vous de trier les sources sous visual dans des répertoires de projet (c'est même très fortement conseillé).
    • seule petite exception: mtQt est une lib statique qui se linke avec mtViz. Cette division permet une gestion du projet Qt extrêmement simplifié grâce à qmake.
  • Suppression de commandes #include superflues.
• Gestion correcte des interruptions CTRL-C, etc
  • Pour ceux qui aurait remarqué, vu que je gère maintenant stdin avec un thread séparé, les signaux du type CTRL-C, CTRL-D n'étaient plus correctement gérés.

Nouveau projet VC.NET avec création de 13 DLLs

La création du projet n'est pas très compliquée (mais longue). Chaque répertoire DLL est constituée des sources contenues dans oo_meta/mtMachin et oofelie/oeMachin.

Commencez par mtGlobal.DLL. Elle ne dépend de rien d'autre.

Pour créer une DLL (vous pouvez le faire dans votre solution .NET actuelle):

• Ajouter/Nouveau projet.
• Choisir "Projets Visual C++" / Projet console Win32
• Entrez le nom: mtGlobal puis OK (le nom doit être celui-là!! - nurbspp pour nurbs++)
• "paramètres d'application": cochez "DLL" puis "exporter les symboles" puis "Terminer"

Paramétrez le projet :

• supprimez les sources crées par défaut.
• ajoutez les sources de oo_meta/mtGlobal/*.*
• allez dans "Propriétés" (click droit sur le nom du projet/Propriétés)
• C++/Général/rép d'includes : ajoutez les includes habituels (cfr votre projet actuel - on inclut tout par facilité). Attention, en fct de votre config, les includes release et debug sont différents.
• C++/Prépocesseur : définissez vos macros de prépros OU ajoutez HAVE_CONFIG_H (définissez alors un fichiers meta_config.h qui rassemble votre config)
• C++/Génération du code/runtime : mettez vous en multithread DLL et multithread debug DLL.
• C++/Langue/Activation des infos de type : Oui (c'est pour les infos RTTI & autres dynamic_cast)
• C++/En-têtes précompilées : virez tout (pas d'entêtes précompilées)
• Editeur de liens/Général : placez votre DLL dans oo_meta : ..\..\..\oo_meta\mtGlobal_d.dll (pensez à donner un nom différent en debug et en release)
• Editeur de liens/Entrée/Dep suppl.: ajoutez les libs à utiliser pour le link (seulement les externes). dans le cas de mtGlobal, il s'agit uniquement de vtkzlib.lib.
• Editeur de liens/Général/Répertoires de Dep suppl.: ajoutez le chemin vers les libs (ici $(VTKBIN)\bin\Release pour vtkzlib).
• Lancez la compilation.

En image : une belle anim avec le codec supplémentaire à installer avant.

Pour les autres DLLs:

Click droit sur le projet puis "dépendances du projet" permet de définir les dépendances. Par exemple, c'est la qu'on définit que mtMath dépend de mtGlobal. Ca permet d'éviter de mettre mtGlobal.lib dans la ligne de link de mtMath et aussi que le visual relinke mtMath quand mtGlobal a changé!

Autres subtilités:

• Les DLLs mtMaterial, mtDrawables, mtElements et mtMaterialLaws contiennent des objets non référencés directement. Si on ne fait rien, le .NET vire les objets lors du link en release. Pour éviter ça, il faut aller dans:
  • Editeur de liens/Optimisation/Références et choisir: "Conserver les données non référencées (/OPT:NOREF)"
• mtQt est un projet "lib statique" qui s'ajoute à mtViz pour former la DLL mtViz.DLL. Cette séparation est pratique pour pouvoir utiliser qmake (ça permet de faire le projet Qt en 2 clicks de souris!). Pour ce faire, utilisez mon fichier mtQt.pro avec le fichier batch make_vcproj.bat.
• ... [N'HESITEZ PAS A AJOUTER DES INFOS SUPPL. ICI!!!]

Le projet qt (ajouté par PP)

Pour insérer le projet mtQt de Romain (ce qui est le plus rapide) dans son projet Metafor :

• On s'assure d'abord qu'on a dans son path le chemin des binaires de qt (D:\Metafor\Libs\QT_3.2.1\bin chez moi) et la variable d'environnement : QMAKESPEC qui vaut win32-msvc.net.
• On créé dans le répertoire projet le répertoire mtQt.
• On édite le fichier mtQt.pro pour mettre les bons chemins d'accès (INCLUDEPATH et VPATH)
• On exécute le fichier make_vcproj.bat et hop, on a un beau fichier mtQt.vcproj qui apparaît (c'est magique!)
• Dans son projet Metafor, on va dans Fichier / Ajouter un projet / Projet existant et on va rechercher le fichier mtQt.vcproj.
• On fait un build du projet mtQt et hop ça marche (c'est toujours aussi magique!)

Remarques :

• Dans le projet de Romain, les fichiers générés par uic et moc sont dans le répertoire projet/uics et projet/mocs. Si ça ne vous va pas, changez la variable MOC_DIR et UI_DIR dans le fichier mtQt.pro pour mettre le chemin que vous voulez, réexécutez le fichier make_vcproj.bat et enfin rebuildicifiez le projet mtQt.
• Si vous avez installé la version non commerciale, vous n'avez qu'une version release, si vous voulez une version debug, prenez le projet mtQt.vcproj de Robo
• Dans mtViz, il faut linker avec la version commerciale de la lib et pas avec la version non commerciale, sauf si vous tenez vraiment à perdre votre temps (j'ai passé deux jours et demie à essayer que ça marche et ça n'a jamais marché, j'ai rien compris -c'est pas surprenant-, mais Romain n'a pas compris non plus -ça l'est plus!).

Finalement

Créez un projet console appelé "Metafor" avec le fichier contenu dans mtMain (main.cpp) et linkez le avec toutes les DLLs! et hop, c'est fini!

Ce qu'il faut savoir pour travailler avec des DLLs

• Les DLLs sont des lib dynamiques qui sont déjà linkées.
• Elles forcent une structure hiérarchique des classes (les dépendances cycliques sont interdites). On a donc des "modules" de développement (des vrais, pas des modules bidons à la OE).
• Elles permettent de linker une petite partie de Metafor quand on travaille de manière localisée sur qq classes (par exemple, si on travaille sur la visu, on ne linke que les classes de visu c-à-d qq secondes vs qq minutes auparavant).
• En pratique, on "exporte" des classes en ajoutant une macro MTMACHIN_API dans la définition de classe. Il est donc possible d'exporter une quantité limitée de classes. Si vous voulez en savoir plus, n'hésitez pas à me contacter.
• Contrairement à des libs statiques, les variables statiques sur lesquelles reposent l'initialisation des éléments finis, matériaux, etc de Metafor sont correctement initialisées.
• La dédéëllisation de Metafor n'est pas finie: j'espère faire rapidement un module ALE. Il serait aussi très intéressant d'extraire les algorithmes d'intégration...

Si vous vous en sortez vraiment pas: voici mon projet à titre de référence.

	created :07-Mar-2006		modified : 07-Mar-2006
	contact : r_boman_AT_yahoo.fr