There are some fresh statechart failures: http://tinyurl.com/wsdcj The seem to be related to my change to Boost.Build, that makes it (correctly) set threading=multi on msvc, on the grounds that it always uses multi-threading with shared runtime. The comments in libs/statechart/test/Jamfile.v2 say: # Some platforms have either problems with the automatic detection of the # threading mode (e.g. vc-7_1 & gcc >= 3.4.0) or don't support single- # threaded mode (e.g. vc-8_0). We therefore manually turn MT off here local st-requirements = <define>BOOST_DISABLE_THREADS ; for local cpp-source in $(cpp-sources) { obj $(name)$(cpp-source) : $(cpp-source).cpp : <threading>single:$(st-requirements) $(requirements) ; objs += $(name)$(cpp-source) ; } I think the right fix *might be* changing <threading>single above to <threading>multi, *or* adding <threading>multi:$(st-requirements) or making $(st-requirements) unconditional. Unfortunately, I'm not sure which one is right, and the comment above does not help me. Can the library authors look into this and adjust the Jamfile as needed? Thanks, Volodya
Hi Volodya Vladimir Prus wrote:
There are some fresh statechart failures:
The seem to be related to my change to Boost.Build, that makes it (correctly) set threading=multi on msvc, on the grounds that it always uses multi-threading with shared runtime.
I've noticed the failures yesterday but have been unsure whether they were due to my adjustments last week or not.
The comments in libs/statechart/test/Jamfile.v2 say:
# Some platforms have either problems with the automatic detection of the # threading mode (e.g. vc-7_1 & gcc >= 3.4.0) or don't support single- # threaded mode (e.g. vc-8_0). We therefore manually turn MT off here local st-requirements = <define>BOOST_DISABLE_THREADS ;
for local cpp-source in $(cpp-sources) { obj $(name)$(cpp-source) : $(cpp-source).cpp : <threading>single:$(st-requirements) $(requirements) ; objs += $(name)$(cpp-source) ; }
I guess I need to give a bit of background here: As far as I understand, including config.hpp into a cpp that is compiled with a <threading>multi requirement should lead to the definition of BOOST_HAS_THREADS. Vice versa, BOOST_HAS_THREADS is not defined for cpps that are compiled with a <threading>single requirement. The comment in the jamfile attempts to explain that this automatism does not natively work on a few platforms. The idea behind <threading>single:$(st-requirements) was an attempt to fix this problem.
I think the right fix *might be* changing <threading>single above to <threading>multi, *or* adding
<threading>multi:$(st-requirements)
or making $(st-requirements) unconditional. Unfortunately, I'm not sure which one is right, and the comment above does not help me.
The idea was that only the tests that absolutely need to run in MT mode actually link against the treading library. I'll therefore make $(st-requirements) unconditional for those tests. Question: Should I still specify a <threading>single requirement for those tests or would that lead to some sort of conflict (because e.g. vc-8.0 is always <threading>multi). Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
Andreas Huber wrote:
Hi Volodya
Vladimir Prus wrote:
There are some fresh statechart failures:
The seem to be related to my change to Boost.Build, that makes it (correctly) set threading=multi on msvc, on the grounds that it always uses multi-threading with shared runtime.
I've noticed the failures yesterday but have been unsure whether they were due to my adjustments last week or not.
The comments in libs/statechart/test/Jamfile.v2 say:
# Some platforms have either problems with the automatic detection of the # threading mode (e.g. vc-7_1 & gcc >= 3.4.0) or don't support single- # threaded mode (e.g. vc-8_0). We therefore manually turn MT off here local st-requirements = <define>BOOST_DISABLE_THREADS ;
for local cpp-source in $(cpp-sources) { obj $(name)$(cpp-source) : $(cpp-source).cpp : <threading>single:$(st-requirements) $(requirements) ; objs += $(name)$(cpp-source) ; }
I guess I need to give a bit of background here: As far as I understand, including config.hpp into a cpp that is compiled with a <threading>multi requirement should lead to the definition of BOOST_HAS_THREADS. Vice versa, BOOST_HAS_THREADS is not defined for cpps that are compiled with a <threading>single requirement. The comment in the jamfile attempts to explain that this automatism does not natively work on a few platforms. The idea behind <threading>single:$(st-requirements) was an attempt to fix this problem.
Okay. Is John aware of such issues?
I think the right fix *might be* changing <threading>single above to <threading>multi, *or* adding
<threading>multi:$(st-requirements)
or making $(st-requirements) unconditional. Unfortunately, I'm not sure which one is right, and the comment above does not help me.
The idea was that only the tests that absolutely need to run in MT mode actually link against the treading library. I'll therefore make $(st-requirements) unconditional for those tests.
Excellent.
Question: Should I still specify a <threading>single requirement for those tests or would that lead to some sort of conflict (because e.g. vc-8.0 is always <threading>multi).
It should not lead to any problems. On msvc, your <threading>single will be overrden anyway. I'd still run the tests on msvc before comitting though ;-) Thanks, Volodya
Vladimir Prus wrote: [snip]
I guess I need to give a bit of background here: As far as I understand, including config.hpp into a cpp that is compiled with a <threading>multi requirement should lead to the definition of BOOST_HAS_THREADS. Vice versa, BOOST_HAS_THREADS is not defined for cpps that are compiled with a <threading>single requirement. The comment in the jamfile attempts to explain that this automatism does not natively work on a few platforms. The idea behind <threading>single:$(st-requirements) was an attempt to fix this problem.
Okay. Is John aware of such issues?
I believe so. I faintly remember having discussed this with him for GCC>=3.4.0. IIRC, then it is close to impossible to correctly detect threading mode on this platform.
Question: Should I still specify a <threading>single requirement for those tests or would that lead to some sort of conflict (because e.g. vc-8.0 is always <threading>multi).
It should not lead to any problems. On msvc, your <threading>single will be overrden anyway. I'd still run the tests on msvc before comitting though ;-)
Ok, thank you. I've commited appropriate changes in trunk & branch. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
participants (2)
-
Andreas Huber -
Vladimir Prus