[Tried sending this through news://gmane.comp.lib.boost.user a few days ago, but it didn't seem to get through anywhere] Hi, I've started experimenting a bit with Boost.Thread, platform is currently WinXP / VC.NET. Just a question on the generated libraries and their names. Wouldn't it be more convenient to put all resulting .lib files in the same directory, and distinguishing between debug/release versions by name, e.g.: libboost_thread.lib // release libboost_thread_d.lib // debug libboost_threadmon.lib // release threadmon ... etc ... and, when the libraries support static linking of the CRT also: libboost_thread_static.lib libboost_thread_static_d.lib As it is now (Boost 1.27.0), it really is a bit awkward to use. Also, why not put all Boost library files in the same directory (e.g. BOOST_ROOT/lib) during build? Sorry if this topic already has been covered, I've been off the Boost lists for some time now. // Johan
--- In Boost-Users@y..., "judoka1981"
[Tried sending this through news://gmane.comp.lib.boost.user a few days ago, but it didn't seem to get through anywhere]
Hi,
I've started experimenting a bit with Boost.Thread, platform is currently WinXP / VC.NET.
Just a question on the generated libraries and their names. Wouldn't it be more convenient to put all resulting .lib files in the same directory, and distinguishing between debug/release versions by name, e.g.:
Yes, it would ;).
libboost_thread.lib // release libboost_thread_d.lib // debug libboost_threadmon.lib // release threadmon ... etc ...
and, when the libraries support static linking of the CRT also:
libboost_thread_static.lib libboost_thread_static_d.lib
The current CVS snapshot does just this (including static linking to the CRT). Unfortunately, it also doesn't work ;). (At least for the Win32 platform. The files are simply renamed and moved, and this breaks import libraries.)
As it is now (Boost 1.27.0), it really is a bit awkward to use. Also, why not put all Boost library files in the same directory (e.g. BOOST_ROOT/lib) during build?
The real issue here is simply that Boost.Build isn't (yet) prepared to do this sort of thing. There is work being done on this, though, and as soon as Boost.Build fully supports this, Boost.Threads will do what you (and I) want here. Bill Kempf
participants (2)
-
bill_kempf
-
judoka1981