Re: [boost] Boost threads + MSVSC + /Za + client code

From: John Maddock (john_at_[hidden])
Date: 2007-01-06 05:16:26

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.