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
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
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk