J'ai reconstruit une version Windows x86 de Metafor pour anticiper la rentrée prochaine et conserver la compatibilité MinGW. Pour rappel, la version Windows x86 est compilée avec gcc sous Windows 10 pour pouvoir tourner sur n'importe quelle machine, même Vista, voire XP ; ce que ne permet pas le Visual Studio 2015 sous Windows 10. C'est une version qui n'utilise pas MKL, ni parasolid.

La compatibilité MinGW du code source de Metafor a été perdue au cours de cette année. Le problème récurrent provient de l'exportation de templates instanciés explicitement. Autrement dit, il s'agit de classes templates compilées dans une DLL et qui doivent être appelés dans une autre. J'ai par exemple dû ajouter une instanciation explicite des StickingElements. Ces éléments sont instanciés dans mtElements et utilisés dans mtDrawables. Si on ne gère pas correctement l’instanciation explicite, le mot clef __declspec(dllexport) est ignoré lors de la création de la première DLL, ce qui provoque un “unresolved” lors du link de la seconde. Evidemment, pour compliquer les choses, chaque compilateur gère ça différemment. Certains permettent une instanciation explicite même si le template n'est pas encore tout à fait défini (c'est le cas de gcc); et d'autres pas (clang).

Concernant les libs, j'ai recompilé mes libs avec MinGW. Il existe 2 versions de MinGW. Une vieille (MinGW) que j'utilisais auparavant et une “nouvelle” (MinGW-W64). Toutes les 2 fonctionnent en 32 bits mais seule la seconde permet une compilation 64 bits (qui ne nous intéresse pas ici). J'ai fait le choix d'utiliser la version de MinGW utilisée par les binaires officiels de Qt. Il s'agit de MinGW-W64 avec un gcc 5.3.0. Ceci permet de ne pas recompiler Qt.

Pour python, on pourrait utiliser le python fourni par MinGW-W64 (oui, il y en a un!) mais j'ai finalement décidé d'utiliser le python officiel (qui, pour rappel, est compilé avec le Visual Studio 2008). Cette solution marche bien et a l'avantage de permettre plus tard l'utilisation de “pip” pour installer des packages (mumpy, mpi4py, matplotlib). Je ne crois pas que pip fonctionnerait avec la version python MinGW… mais il faudrait tester pour en être sur. L'inconvénient avce le Python officiel, c'est qu'il devient difficile de produire un exe “debug” vu l'absence de “Python debug” dans les binaires officiels et que le Visual Studio force l'utilisation des 2 DLLs séparées (python27.dll et python27_d.dll). Ici, je m'en fous, vu que seule une version Release m'intéresse.

Pour VTK, j'ai recompilé la toute dernière version (7.1.1) presque sans problème: j'ai dû légèrement modifier le code source de libtiff, rien de terrible. Pareil pour PyQt (une légère modif dans le code source de… python). MUMPS est compilé avec OpenBLAS. TBB ne pose pas de problème.

Suite à ce commit, je remarque que compiler les libs devient de plus en plus simple. Le support MinGW me semble bien répandu parmi les libs qu'on utilise et MinGW m'a semblé cette fois-ci beaucoup plus robuste. En particulier la compilation parallèle fonctionne (mingw32-make -j X) et je n'ai pas eu besoin de MSYS (une sorte de mini système cygwin fourni avec le vieux MinGW et que j'avais dû utiliser la dernière fois pour pouvoir compiler certaines libs).

Depuis l'utilisation de version Debian plus récentes sur gaston et thorgal, certains tests CGAL ne passent pas. Luc avait investigué et avait conclu qu'il devait y avoir un bug depuis le début quelque part. Il suffit de s’acharner pour que ça passe (lancer, relancer, relancer, jusqu'à ce que ça marche…) mais je ne l'ai pas fait.

• mtExactDataTransfer_CGAL.tests.disk3D_LocMort_2
• mtExactDataTransfer_CGAL.tests.disk3D_LocMort_3

— boman 2017/05/19 07:54