From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2007-11-02 04:50:47
The build script for the thread library had some short-comings:
*) Incorrect handling when <threading>single was specified on
the command line.
*) Annoying unrelated messages even when build boost libs,
that had nothing to do with the thread lib.
*) Name clashes when trying to build the thread lib for
win32 and pthread at the same time.
I addressed these issues with a new Jamfile, without changing
the default behavior known from version 1.34:
1) Even when requesting <threading>single on the command line
(or in Jamroot) the requirements of <threading>multi will
now be honored correctly. (This is boost policy.)
2) It is possible to request a build of the threading lib for
a specific api. The feature <threadapi> with allowed values
"win32" and "pthread" is used for this. On the cmdline e.g.
this is bjam --with-thread threadapi=pthread .
(I removed the hyphen from the name on Volodyas recommendation.)
3) There is the concept of "native" api. On windows (more exactly
the result of os.name is NT) this is win32, else pthread.
The resulting library has the usual name "boost_thread" for
the native api. The non native api is tagged with the
api. E.g. the request
bjam --with-thread install threadapi=win32,pthread
will result in libraries booot_thread* and boost_thread_pthread*.
(No more duplicate name errors.)
4) The information messages telling, that pthread is not available
will only be emitted when really trying to build with pthread.
I hope this will be less annoying to users that are not
interested in pthread api.
5) The paths to the installed pthread lib now can be set in
one of three places: environment, user-config.jam and
Thank you for attention,
Roland aka speedsnail
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk