|
Threads-Devel : |
From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2007-10-25 11:56:07
Anthony Williams wrote:
>> I have seen, that you have purged the thread.jam, and the
>> build of boost_thread_pthread.
>>
>> I'd like to restore this feature. I hope you do not have any
>> objections.
>
> What do you want to achieve? I pulled thread.jam into Jamfile.v2 in order
> to simplify the build, and ensure that the thrd-api stuff was carried over
> into things outside the boost thread .dll and .lib files.
First let me say that I like your usage of the thrd-api default value.
(The first is always pulled in by default.)
Then I do not understand "into things outside boost thread" what does
this mean? Which things? Where is outside? Where is inside?
Also the current implementation has a bug (which I already have a
solution, thanks Volodya.) The boost Jamroot requests both
<threading>single and <threading>multi. This causes the infamous "no
best alternative" error, and in turn nothing been built. This is against
boost policy. (Also see tracker issue #16
https://zigzag.cs.msu.su:7813/boost.build/ticket/16 )
> As I understand it, boost_thread_pthread was just a build that was
> guaranteed to use pthread, even on Windows. You can achieve this by
> putting thrd-api=pthread on the bjam command line:
>
> bjam msvc-7.1 thrd-api=pthread
>
Yes, but this only is part of the solution, just try
bjam msvc-7.1 thrd-api=win32,pthread
You will get the duplicate target error.
> If that's not what you want, let me know, and we can find a way to do it.
> That may be to bring back boost_thread_pthread or split thread.jam back
> out again, but there may be a better way.
I am currently searching for a way that will let the user get 3 variants:
1) boost_thread (whatever is native api on platform
2) boost_thread_pth (a library which has an explicit tag for pthread)
3) boost_thread_w32 (a library which has an explicit tag for win32)
This will allow a user to specify which variant she likes, even for
pre-built libraries.
I also want that a user can request all variants explicitly and
in a single bjam invocation.
The current problem is that the <tag>@rule feature cannot be used
because it is already occupated by boost itself. I will need to discuss
this with Volodya.
Roland aka speedsnail