|
Threads-Devel : |
From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2007-10-29 04:40:36
Anthony Williams wrote:
>Hopefully you and Volodya can come up with something.
Attached is a patch set for three files that change the
boost_thread build process in the following way:
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
site-config.jam.
Anthony, I would be glad if you could do some testing and possibly
comment on the solution before I commit.
We also need to wait for approval of the property.jam patch by
Volodya before we can use the new Jamfile.
Roland aka speedsnail