Boost logo

Boost :

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?


On Sat, Mar 10, 2012 at 1:13 PM, Emil Dotchevski

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at