Sohail Somani wrote:
[mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov
Thinking about it a bit more, there is a third reason that Boost.Config shouldn't be doing that. BOOST_DISABLE_THREADS is a user macro, and the config system shouldn't be touching it.
The easiest solution is to ignore Boost.Config until the meanings of _HAS_THREADS and _DISABLE_THREADS are sorted out and check everything at the library level.
Hey, this sounds awesome. So you seem to be suggesting that Boost.Config should not touch *_THREADS until we sort out the meaning of those?
I was suggesting that it would be easier to just make Boost.Threads work instead of fixing Boost.Config. But now that I looked at the code, it doesn't really seem that much easier. There is a comment in win32.hpp: // Win32 will normally be using native Win32 threads, // but there is a pthread library avaliable as an option, // we used to disable this when BOOST_DISABLE_WIN32 was // defined but no longer - this should allow some // files to be compiled in strict mode - while maintaining // a consistent setting of BOOST_HAS_THREADS across // all translation units (needed for shared_ptr etc). that indicates that our past discussion (this is not the first time this comes up) has had an effect. Mixing /Za and /Ze still seems to result in inconsistent BOOST_HAS_THREADS, though. This breaks detail/lightweight_mutex, for example. It even seems to break Regex, there are a number of BOOST_HAS_THREADS checks there that use the "are we in MT mode" meaning of the macro, as opposed to its "do we have a threading API" meaning.