[thread] Jamfile issue
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
AMDG On 03/10/2012 01:13 PM, Emil Dotchevski wrote:
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?
Are you sure that the problem is <threadapi>, not <threading>multi? In Christ, Steven Watanabe
On Sat, Mar 10, 2012 at 1:41 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
On 03/10/2012 01:13 PM, Emil Dotchevski wrote:
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?
Are you sure that the problem is <threadapi>, not <threading>multi?
Well, if I do alias thread : $(boost)//thread/<threadapi>win32 ; I don't get an error message from Boost Build. -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Am 12.03.12 05:34, schrieb Emil Dotchevski:
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>.
Do you have <threadapi> anywhere in your own Jamfiles? Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: keyserver x-hkp://pool.sks-keyservers.net iEYEARECAAYFAk9eV0IACgkQhAOUmAZhnmr15ACdH6mWycqdwSznShilGe7M359X cvwAmwd0IlgwslLpAbBw1z7VQU+iHtbj =zL4w -----END PGP SIGNATURE-----
On Mon, Mar 12, 2012 at 1:06 PM, Frank Birbacher <bloodymir.crap@gmx.net>wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi!
Am 12.03.12 05:34, schrieb Emil Dotchevski:
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>.
Do you have <threadapi> anywhere in your own Jamfiles?
No. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
AMDG On 03/11/2012 09:34 PM, Emil Dotchevski wrote:
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?
I'm sure you're correct. The best solution right now is to force boost thread to be loaded earlier with use-project. In the long term, I'd like to re-do property handling to make this a non-issue, but that requires major changes. In Christ, Steven Watanabe
participants (3)
-
Emil Dotchevski -
Frank Birbacher -
Steven Watanabe