j'ai trouvé
c'est vraiment très c*n en fait... j'ai commencé par ajouté le fameux repertoire include contenant le fameux 'windows.h' via la console de visual à l'aide de la commande :
set INCLUDE=C:\chemin trop long\Include
bon, après il me manquait une lib ... donc comme on ne change pas une équipe qui gagne :
set LIB=C:\chemin trop long\Lib
et là j'ai enfin pu compiler bjam.
ensuite je suis aller compiler la lib qui me manquait (copie de bjam.exe dans le rep ...\system\build), là j'ai découvert que mon nouvel ami (bjam) compil par defaut en debug. j'ai tenté un truc, ajouté release à la fin de ma ligne de commande :
bjam release
j'ai récupéré effectivement une lib en release :
boost_system-vc80-1_34_1.lib
content, j'ai linker vers cette lib, le problème c'est que visual attend :
libboost_system-vc80-1_34_1.lib
et là c'est à nouveau la ...
je vais donc voir la lib de plus près, je me rend compte qu'il s'agit d'une lib dynamique...
un tour sur Gogole.fr pour voir comment lui faire comprendre que je veux du static (n.b. ajouté static à la suite de la commande ne fontionne pas)
j'ai donc ajouté la commande static :
bjam release link=static
j'ai récupéré le fichier :
libboost_system-vc80-1_34_1.lib
c'est presque ça... il manque un 'mt' dans le nom... un petit tour sur le net pour apprendre que cela veut dire 'multithreading' et qu'on lui fait comprendre ça en écrivant :
bjam threading=multi release link=static
et là... enfin, la bibliothèque tant attendue
mon prog link est fonctionne!
n.b. : j'ai détaillé les commandes que j'ai entré. Elles pourraient peut être un jour reservir...
Partager