Differences

This shows you the differences between two versions of the page.

--- commit:2017:05_19 [2017/05/19 08:19] – boman
+++ commit:2017:05_19 [2017/05/19 08:32] (current) – boman
@@ Line 3: / Line 3: @@
 ===== Portage MinGW =====
-Je reconstruit une version x86 de Metafor pour anticiper la rentrée prochaine et conserver la compatibilité MinGW (pour rappel, la version x86 est compilée avec gcc sous Windows pour pouvoir tourner sur n'importe quelle machine, meme Vista, voire XP ; ce que ne permet pas le Visual Studio).
+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é du code MinGW avait été perdue. Le problème récurent 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'instancation 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'').
+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 ([[http://www.mingw.org/|MinGW]]) et une "nouvelle" ([[https://sourceforge.net/projects/mingw-w64/|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.
+Concernant les libs, j'ai recompilé mes libs avec MinGW. Il existe 2 versions de MinGW. Une vieille ([[http://www.mingw.org/|MinGW]]) que j'utilisais auparavant et une "nouvelle" ([[https://sourceforge.net/projects/mingw-w64/|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). L'inconvénient est qu'il devient difficile de produire un exe "debug" vu l'absence de Python Debug dans les binaires officiels. Ici, je m'en fous vu que seule une version Release m'intéresse.
+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 presque sans problème (j'ai dû légèrement modifier le code source mais rien de terrible).
+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 de code source).
+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épendu 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 [[http://www.msys2.org/|MSYS]] (une sorte de mini système cygwin fourni avec MinGW et que j'avais utilisé la dernière fois pour pouvoir compiler certaines libs).
+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 [[http://www.msys2.org/|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).
 ===== Divers =====
-Depuis l'utilisation de version debian plus récentes sur gaston et thorgal, certains tests CGAL ne passent
+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'acharger (lancer, relancer, relancer, jusqu'à ce que ça marche...).
+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
-<note warning>Je ne l'ai pas fait et j'ai donc commité ces 2 tests en FAILED</note>
+<note warning>J'ai donc commité ces 2 tests CGAL en FAILED</note>