Peter Dimov wrote:
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.
I think that's right. So... thinking out loud, how about we decouple BOOST_DISABLE_WIN32 and BOOST_DISABLE_THREADS: /Za sets BOOST_DISABLE_WIN32 but doesn't disable threads (if they're turned on). Now the library code must: * Build separate libs with extentions on: to get windows.h. * If the code uses win32 thread API's in a *header*, then it might now be broken: user has to decide what to do (enable extentions or disable threads project wide). There may still be issues with BOOST_DISABLE_WIN32 causing binary incompatibity between object files compiled with and without it (I think it might with regex, but haven't fully checked). The problem is we've never really supported this: it's always been a "use the same options everywhere" policy. In order to test this we would need to be able to build the libraries with one set of options, and the test programs with another (and then find a test machine to run the tests). Is this moving in the right direction? John.