[boost] Jamfile for build of thread libs changed.

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
    site-config.jam.

Thank you for attention,

Roland aka speedsnail