[boost] BOOST_DISABLE_WIN32

From: Peter Dimov (pdimov_at_[hidden])
Date: 2008-04-11 12:53:12

John Maddock:

>>> Lets see where these changes get us, and then we need to decide what
>>> to do on Win32 in strict mode when <windows.h> is unavailable :-)
>>
>> I believe that the fact that <windows.h> is unavailable (this can
>> happen in non-strict mode as well under VC++ Express, if the Platform
>> SDK hasn't been installed) should be indicated by a new macro that is
>> documented as such.
>
> Well we have BOOST_DISABLE_WIN32 which is set when <windows.h> is
> unavailable - or alternatively optionally by the user.

I don't like the fact that the macro names do not reflect their actual 
meaning. This inevitably leads to their being set in situations where they 
shouldn't be, and vice versa. A macro that indicates the absence of 
windows.h should be called BOOST_NO_WINDOWS_H, and the reverse should be 
BOOST_HAS_WINDOWS_H. A user macro that overrides the detection should be 
called BOOST_DISABLE_WINDOWS_H. In general, we should follow a consistent 
naming scheme.

It's obvious when this macro should and should not be set, and it's obvious 
when it needs to be tested - when the code decides whether to #include 
<windows.h> or not.

The problem with making the macro clear and unambiguous in this manner is 
that it exposes that libraries - in reality - have no use for it. :-)

>> Still, the easiest way out is just to use an internal macro for
>> communication and leave BOOST_DISABLE_* as pure user macros.
>
> If we stop setting BOOST_DISABLE_THREADS when BOOST_DISABLE_WIN32 is set 
> this issue become moot doesn't it?

There are other places where BOOST_DISABLE_THREADS is being set by 
Boost.Config. The problem is that I can't really know whether they are 
correct or not - from user point of view.

The good thing about testing a user macro is that one is 100% certain that 
the user means what he says; the library better do what it's being told.