Code::Blocks & WxWidgets, le retour…

On a vu que l’installation de Code::Blocks sur un PC sous windows avec la bonne configuration pour pouvoir utiliser WxWidgets n’est pas triviale.

Voici les points testés vendredi et qui ont des résultats mitigés :

• Installer Code::Blocks, version incluant MinGW, dans un répertoire sans espace, par exemple c:\tools
• On va avoir : Code::Blocks dans le répertoire C:\tools\CodeBlocks ; MinGW sera dans le répertoire C:\tools\CodeBlocks\MinGW
• Installer MSYS dans C:\tools également par exemple. En profiter pour installer MSYSDTK (au même endroit), ça peut servir aussi. Spécifier le bon répertoire de MinGW quand il sera demandé.
• La procédure décrite dans “docs\msw\install.txt” du répertoire WxWidgets ne marche pas :
  

  cd $WXWIN
  mkdir build-debug
  cd build-debug
  ../configure –with-msw –enable-debug –enable-debug_gdb –disable-shared
  make
  make install

• La porcédure décrite dans le wiki : Compiling wxWidgets 2.8.6 to develop Code::Blocks ne semble pas non plus fonctionner directement :
  

  cd $WXWIN
  cd build\msw
  mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=release clean
  mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=release

  Il est indiqué que ces options de compilation soient les seules supportées par C::B.
  On retrouve des explications similaires ici (sur une autre page du même wiki). Il y est confirmé qu’il ne faut pas trop changer les options de compilation ci-dessus et que les paths avec espaces sont assez malvenus. Il est aussi spécifié que la procédure marche avec WxWidgets-2.8.7, or la version actuelle téléchargeable est la 2.8.8. Serait-ce là que le bas blesse ?

Les tentatives du jour sont les suivantes :

• Essai en utilisant “configure” :
  

  cd $WXWIN
  cd build/msw
  ../../configure –with-msw –disable-debug –enable-shared –enable-unicode –enable-monolithic
  make
  make install

  La directive “–enable-release” n’existant pas pour “configure”, on suppose que si on spécifie”–disable-debug”, il va bien faire une version release. Si ça ne marche pas, on pourra toujours essayer avec la version 2.8.7.

• Bilan : on obtient bien une dll dans le répertoire “lib” : “wxmsw28u_gcc_custom.dll”. Par contre, on est obligé de déplacer le “include” manuellement dans “build/msw” (!), mais de toutes façons, C::B ne reconnait toujours pas la dll. Là je bloque et je ne pense pas que revenir à la version 2.8.7 change grand chose.
• J’essaie de bouger la dll dans le répertoire $WXWIN/lib. ça ne marche pas mieux. Ni dans ses sous-répertoires d’ailleurs (gcc_dll, … ).
• Acharnement. J’efface tout WxWidgets et je recommence. Ca tombe bien, ce n’est pas comme si ça mettait beaucoup de temps à compiler… grmpf.
• Essai avec “configure”, ça ne marche pas. Apparemment Code::Blocks cherche un répertoire “gcc_dll” dans le répertoire “lib”. Il chercherait également un fichier “libwxmsw28u.a” dans “gcc_dll”. Autant dire qu’on n’est pas tiré d’affaire.
• Réinstallation de WxWidgets et essai avec “mingw32-make”. Quelle déception, ça marche. Fin du jeu. Il met bien les fichiers et répertoires qu’il faut dans le “lib” de $WXWIN et ensuite, ça passe.

Conclusion : Quelle perte de temps !!

1. Emporté par mon élan, j’en compile même la version “debug” pour être un petit peu plus exhaustif.
2. Certains vous diront que la dll est tellement grosse que des fois il faudrait presque mieux pour les petits programmes d’utiliser la version statique. A ce stade, je ne sais pas s’il faut conseiller la version non monolithique.