- Il faut absolument MASM, l’assembleur de Microsoft . (celui de gcc n’est pas supporté)
- Il y a 2 bugs dans la batch build.bat qui compile bjam (le ‘make’ de Boost)
- La procédure d’installation/compilation est mal conçue et il faut éditer manuellement des fichiers de configuration.
Nous allons voir comment corriger tout cela...
PREREQUIS
- MASM est installé. Voir absolument ce post pour éviter de devoir installer MSVC avec MASM.
MASM doit être dans le PATH. - MinGW est installé, soit directement soit via un outil tel que Qt ou Code::Blocks.
Quelle que soit l’origine de MinGW il faut obligatoirement ajouter au PATH le répertoire ’bin’ de MinGW - Télécharger les sources des librairies Boost.
Ce qui suit a été testé avec Boost 1.55 + win7 64bits
PREMIER BUG de tools\build\v2\engine\build.bat.
Le programme d’installation de Boost s’attend à trouver MinGW dans C:\MinGW mais si vous l’avez installé ailleurs, ou utilisez le MinGW de Qt ou CodeBlock ça ne marchera pas.Voici comment corriger cela.
Dans le fichier tools\build\v2\engine\build.bat remplacer (ou mettre en commentaire avec REM) les 4 lignes :
if EXIST "C:\MinGW\bin\gcc.exe" (Par ces 5 lignes:
set "BOOST_JAM_TOOLSET=mingw"
set "BOOST_JAM_TOOLSET_ROOT=C:\MinGW\"
goto :eof)
call :Test_Path mingw32-make.exe
if not errorlevel 1 (
set "BOOST_JAM_TOOLSET=mingw"
set "BOOST_JAM_TOOLSET_ROOT=%FOUND_PATH%..\"
goto :eof)
Pourquoi chercher mingw32-make.exe et non gcc.exe dans le PATH ?
- Si on cherche gcc.exe on risque de trouver une installation de gcc qui n’appartient à MinGW mais à cygwin.
- Si on cherche mingw32-gcc.exe on ne trouvera pas gcc si c’est la version 64 bits qui est installée car son nom est i686-w64-mingw32-gcc.exe
- Réciproquement, si on cherche i686-w64-mingw32-gcc.exe on ne trouvera pas la version 32 bits.
Par contre si on cherche et trouve mingw32-make.exe on est certain qu’avec lui il y a une version de gcc (32 ou 64 bits) appartenant à MinGW.
DEUXIEME BUG de tools\build\v2\engine\build.bat
Ce bug a pour effet de détecter la présence du compilateur de Microsoft MSVC même quand il n’est pas installé. La cause de ce bug est que pour certaines versions de Windows la commande
set test=%~$PATH:1
met à jour le errorlevel et pour d’autres non. Ce bug est par exemple présent pour WIN7 64 bits.
Dans la fonction :Test_path, avant la ligne ‘endlocal’ il faut ajouter cette ligne
if not defined test ( call :Set_Error ) else ( call :Clear_Error )
Ce qui donne :
:Test_Path
REM Tests for the given file(executable) presence in the directories in the PATH
REM environment variable. Additionaly sets FOUND_PATH to the path of the
REM found file.
call :Clear_Error
setlocal
set test=%~$PATH:1
if not defined test ( call :Set_Error ) else ( call :Clear_Error )
endlocal
if not errorlevel 1 set FOUND_PATH=%~dp$PATH:1
goto :eof
TROISIÈME BUG
Une fois ces deux premier bugs corrigés, on peut ouvrir une ligne de commande (cmd) dans la racine des sources de Boost et taper :
bootstrap.bat
Ensuite NE PAS TAPER b2 comme indiqué à l’écran !
Il faut au préalable éditer le fichier project-config.jam et remplacer msvc par mingw.
La raison de ce travail supplémentaire est expliqué dans les commentaires du fichier bootstrap.bat :
REM Ideally, we should obtain the toolset that build.bat hasIncroyable, n’est-ce pas, qu’après tant d’années personne n’ai trouvé de solution...
REM guessed. However, it uses setlocal at the start and does
REM export BOOST_JAM_TOOLSET, and I don't know how to do that
REM properly. Default to msvc for now.
set toolset=msvc
Après avoir modifiè project-config.jam vous pouvez exécuter « b2 »
TRUC:
Utilisez "b2 -j 4" pour utiliser 4 theads de compilation, ou plus si votre processeur le supporte.
Pour tout effacer b2 --clean
Après un temps plus ou moins long (de 10 à 50 min) suivant la vitesse cpu et disque de votre machine et le nombre de threads mis en jeux vous obtiendrez :
The Boost C++ Libraries were successfully built!
The following directory should be added to compiler include paths:
C:/xyz/boost_1_55_0
The following directory should be added to linker library paths:
C:\xyz\boost_1_55_0\stage\lib
(xyz depend de là où vous avez décompressé Boost)
Bravo !
Boost 1.55 et MSVC 2013 (Quatrième bug)
En compilant Boost 1.55 avec Microsoft Visual Studio Express 2013 (donc version 12) on a cette erreur de compilation:
transform_width.hpp(151) : error C2039: 'min' : is not a member of 'std'
transform_width.hpp(151) : error C3861: 'min': identifier not found
Pour la corriger il faut ajouter cette simple ligne:
#include <algorithm>au début de boost/archive/iterators/transform_width.hpp
Il n’y a donc pas que GCC qui est mal testé par les développeurs de Boost !
NB: Je n'utilise Boost que quand c'est imposé car, depuis toujours, c'est la galère.