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@gmail.com>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