From: Anthony Williams (anthony_at_[hidden])
Date: 2007-10-25 12:41:13
Roland Schwarz <roland.schwarz_at_[hidden]> writes:
> 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
>> 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?
By "outside boost thread" I mean code that is not linked into the boost thread
DLL or LIB files.
When I initially tried running tests using pthread-win32 on windows, I found
that the DLL or LIB would be built fine, but the tests would be built
expecting win32 threads, and get a linker error. With my changes this now
> 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 )
OK. What's the solution?
>> 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.
I can believe that. Are there any features where you can specify both options
to get two copies of the library built?
>> 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)
I'd rather only have two options, since the default will be one of the other
> 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.
I like the idea. I'm only just beginning to understand boost.build, so I don't
have anything to offer as yet. Hopefully you and Volodya can come up with
-- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL