Reini Urban wrote:
> Andrew Dunstan schrieb:
>
>>> We
>>> had lots of Cygwin-specific defines in there already so Win32 just
>>> means
>>> both Mingw and Cygwin. You will see only a few cases where we want
>>> Mingw and not Cygwin, but in those case we often also want MSVC and
>>> Borland, so it really is WIN32 && ! __CYGWIN__. We do have one or two
>>> tests for __MINGW32__ where we really do want just that.
>>>
>>> Would you look around and see if this can be improved. I can't see
>>> any.
>>
>>
>> As I said, I did look at all the include cases. That was based on the
>> assumption that we actually wanted what I thought was the intention,
>> namely that WIN32 was for Windows native only. If that's not the case
>> we would need to review every one of the ~300 cases where WIN32 is
>> used in #ifdef and friends.
>>
>> Bottom line - this is something of a mess. If we can make sure Cygwin
>> isn't broken, we can probably live with what have for now.
>> Personally, I would have configure work out something cleaner, like,
>> say, defining WINDOWS_ALL for both Windows native and Cygwin. Then we
>> could use that for cases meant to cover both, and __CYGWIN__ and
>> __MINGW32__ for the specific cases, without worrying what the
>> compiler and/or the system header files might have defined for us.
>
>
> Most of the ~300 cases are ok for CYGWIN. And probably for MINGW also.
> But I don't do MINGW countertests. I assume you do :)
>
>
Cygwin is the likely point of failure here, since we know WIN32 is
always defined on MinGW.
cheers
andrew
