Re: [boost] [thread] Jamfile issue

Subject: Re: [boost] [thread] Jamfile issue
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2012-03-12 00:34:24

It appears that both the <threadapi> and <python-debugging> properties
cause the same problem. Currently, my only workaround is to delete all
mentioning of <threadapi> and <python-debugging> from the Boost
distribution Jamfiles, which obviously is not ideal.

I think that the problem is due to some of my own targets being seen twice
in the same build environment: once before and once after Boost Thread and
Boost Python get defined, leading to the ones seen before to be missing the
default values of <threadapi> and <python-debugging>.

Does this seem plausible? Is there a solution to this problem?

Thanks,
Emil

On Sat, Mar 10, 2012 at 1:13 PM, Emil Dotchevski
<emildotchevski_at_[hidden]>wrote:

> Hello,
>
> In my own Jamfile targets, if I refer to Boost Thread as:
>
> alias thread : $(boost)//thread ;
>
> I get:
>
> error: No best alternative for
> boost_1_48_0/libs/thread/build/thread_sources
>     next alternative: required properties: <threadapi>win32
> <threading>multi
>         not matched
>     next alternative: required properties: <threadapi>pthread
> <threading>multi
>         not matched
>
> I could do this instead:
>
> alias thread : $(boost)//thread/<threadapi>win32 ;
>
> But that clumsy, I'd be dispatching between POSIX and WIN32
> configurations, which ideally should be done internally by Boost Thread's
> Jamfile.
>
> Is there a better way to refer to Boost Thread?
>
> Emil Dotchevski
> Reverge Studios, Inc.
> http://www.revergestudios.com/reblog/index.php?n=ReCode
>