Re: [boost] Boost threads + MSVSC + /Za + client code
[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? Just thinking of what sort of local patch I will apply (this is what I've actually done currently). Thanks! Sohail
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.
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.
John Maddock wrote:
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.
True. But the problem here is that this is a legitimate scenario for not using the same options everywhere. Typically, when protability is desired, all code that uses <windows.h> is isolated into a translation unit or two, and the rest of the code base is compiled with /Za. So the fact that <windows.h> will not compile is a feature in this case; it shows people that someone has introduced a Windows dependency in the portable code. We can't support this scenario if our libraries test for /Za and do something different because of ODR violations. We can leave BOOST_DISABLE_WIN32 as a user macro and not have the config system set it. Or we can just make the libraries not test for BOOST_DISABLE_WIN32, if that's feasible. Since bjam doesn't set /Za, they will build fine; as long as they don't include <windows.h> in their headers, and they must never do so, they will be usable with or without /Za. I think.
participants (3)
-
John Maddock -
Peter Dimov -
Sohail Somani