Re: [Threads-devel] Cannot build on trunk

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
>>> 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.)

Thanks.

> 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
works.

> 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
two.

> 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
something.

Anthony
-- 
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