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
> In my own Jamfile targets, if I refer to Boost Thread as:
> alias thread : $(boost)//thread ;
> I get:
> error: No best alternative for
> next alternative: required properties: <threadapi>win32
> not matched
> next alternative: required properties: <threadapi>pthread
> 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
> Is there a better way to refer to Boost Thread?
> Emil Dotchevski
> Reverge Studios, Inc.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk