[MPlayer-cvslog] r32724 - trunk/configure

[Reimar Döffinger]

On 1 jan 2011, at 15:38, Diego Biurrun <diego at biurrun.de> wrote:
> On Wed, Dec 29, 2010 at 03:47:58PM +0100, Reimar Döffinger wrote:
>> On 28 dec 2010, at 12:33, Diego Biurrun <diego at biurrun.de> wrote:
>> 
>>> On Sun, Dec 19, 2010 at 11:02:53PM +0100, reimar wrote:
>>>> 
>>>> Log:
>>>> Compilation fixes for currentl Cygwin.
>>>> 
>>>> --- trunk/configure    Sun Dec 19 15:19:04 2010    (r32723)
>>>> +++ trunk/configure    Sun Dec 19 23:02:52 2010    (r32724)
>>>> @@ -1519,6 +1519,12 @@ if win32 ; then
>>>> 
>>>> +if cygwin ; then
>>>> +  # e.g. priority.c needs _WIN32 define, but
>>>> +  # latest cygwin no longer defines it
>>>> +  extra_cflags="-D_WIN32 $extra_cflags"
>>>> +fi
>>> 
>>> I just talked about this with Jean-Baptiste Kempf on IRC and it looks
>>> quite suspicious.
>>> 
>>> Cygwin should define _WIN32, why isn't it doing it?  See the discussion
>>> of the patch I posted to dvdnav-discuss and the MSDN entry:
>> 
>> What makes you think it should? Cygwin is _not_ intended for compiling
>> WIN32 (in terms of API) but POSIX.
> 
> I'm getting more confused by the minute, likely due to my ignorance of
> all things Windows.  Why are you #defining _WIN32 for Cygwin then?

Because we know how to use the win32 API and we _want_ to use it, even though that's not how cygwin is supposed to be used.
We do not support cygwin as a POSIX wrapper for Windows, just as a lazy way to compile for Windows, so for us it is win32.

> It seems to that replacing checks for _WIN32 with checks for both
> __MINGW32__ and __CYGWIN__ is the correct fix.

That is just pointlessly verbose and brittle IMO. Of course if we wanted to make the effort we should check each case separately and decide whether in that case it is better to use the cygwin POSIX layer or the win32 API, but I think we'd still come to the conclusion that we want to use the win32 API in almost all cases.
>