Boost logo

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




Threads-Devel list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk