Commit 2007-07-24

J'ai modifié les makefiles Unix pour permettre une compilation de libs dynamiques sous Unix (.so, l'équivalent des DLLs sous Windows). Contrairement à ce que je pensais, j'ai vraiment pas eu beaucoup de problèmes. L'exécutable Linux et OSF font quelques dizaines de ko comme sous Windows et toutes les libs sont compilées dans un repertoire lib (en release) et libd (en debug) qui est automatiquement ajouté au path par metafor. Il n'y a donc pas besoin de modifier son profile pour que ça marche.

Quelques subtilités:

• J'ai dû faire des libs séparées pour les sources Sabca et IntelSig. Il y a donc, sous Unix, deux libs supplémentaires (libmtIntelSig.so et libmtSabca.so) . Normalement, ça devrait être possible de faire la même chose sous Windows.
• J'ai dû déplacer certains fichiers et créer des répertoires distincts pour tous les wrappers python. Ceux-ci étaient anciennement dans le répertoire mtPython mais n'avaient rien à faire là. il y a donc des nouveaux répertoires du type _mtPyGlobal, _mtPyGeo, _mtPyFEM, etc. Il faut donc modifier son projet Visual en conséquence.
• Nurbs++ n'est pas encore une lib dynamique (mais une lib statique). Je prévois des merdes lors de la transitions donc j'ai préféré laisser comme ça.
• Les Makefiles doivent être nettoyés (vérification des répertoires d'include et ajout d'un Makefile.in spécifique à mtMain).
• La compilation parallèle de certaines libs dont les répertoires sources sont multiples pourrait être améliorée.

On pourrait penser naïvement (j'ai été le premier à le faire) qu'on peut donc maintenant se passer de l'exécutable metafor pour lancer un calcul en le remplaçant par python comme on peut le faire sous Windows… et bien non, ça marche pas et ceci, “simplement” parce qu'il existe toujours des dépendances cycliques dans les libs. Par exemple: mtFEM dépend de mtMaterials (et l'inverse est évidemment vrai) via le LoadApadtationManager et (honte sur moi), l'ALE. Il faudra donc essayer de résoudre ces dépendances dans le futur (on peut les détecter facilement sous Windows en limitant au minimum les répertoires d'include dans le projet Visual ou, plus brutalement, avec dependancy walker.

• Modifier l'emplacement de vos sources pour les librairies des “wrappers” (celles qui commencent par un underscore).
• Modifier les “includes” swig et C++ des projets “wrappers” pour que les fichiers “.i”, “.h” et “.swg” puissent être accédés sans problèmes lors de la compilations des wrappers dépendants.

Note: ce serait peut etre utile de modifier le projet de développement pour définir le minimum de rep d'include.

File	Text status
_mtPyFEM	added
_mtPyGeo	added
_mtPyGlobal	added
_mtPyKernel	added
_mtPyMath	added
_mtPyShapeFunctions	added
_mtPyViz	added
_mtPyFEM/initFEMShadow.cpp	added (+)
_mtPyGeo/mtPyGeoExtended.cpp	added (+)
_mtPyGlobal/initGlobalShadow.cpp	added (+)
_mtPyKernel/initKernelShadow.cpp	added (+)
_mtPyFEM/initFEMShadow.h	added (+)
_mtPyGeo/mtPyGeoExtended.h	added (+)
_mtPyGlobal/addToPyDict.h	added (+)
_mtPyGlobal/initGlobalShadow.h	added (+)
_mtPyGlobal/initIDList.h	added (+)
_mtPyKernel/initKernelShadow.h	added (+)
_mtPyFEM/mtPyFEM.i	added (+)
_mtPyGeo/mtPyGeo.i	added (+)
_mtPyGlobal/mtPyGlobal.i	added (+)
_mtPyKernel/mtPyKernel.i	added (+)
_mtPyMath/mtPyMath.i	added (+)
_mtPyShapeFunctions/mtPyShapeFunctions.i	added (+)
_mtPyViz/mtPyViz.i	added (+)
_mtPyFEM/Makefile.in	added
_mtPyGeo/Makefile.in	added
_mtPyGlobal/Makefile.in	added
_mtPyKernel/Makefile.in	added
_mtPyMath/Makefile.in	added
_mtPyShapeFunctions/Makefile.in	added
_mtPyViz/Makefile.in	added
mtDrawables/Makefile.in	added
mtElements/Makefile.in	added
mtFEM/Makefile.in	added
mtGeo/Makefile.in	added
mtKernel/Makefile.in	added
mtMaterialLaws/Makefile.in	added
mtMaterials/Makefile.in	added
mtPython/Makefile.in	added
mtQt/Makefile.in	added
mtShapeFunctions/Makefile.in	added
mtViz/Makefile.in	added
_mtPyGlobal/mtCommon.swg	added (+)
_mtPyKernel/UserNo.swg	added (+)

intelSig/src/Makefile.in	added
sabca/src/Makefile.in	added

— Romain BOMAN 2007/07/24 08:27