[MPlayer-cvslog] r32724 - trunk/configure

[Reimar Döffinger]

On 2 jan 2011, at 20:00, Diego Biurrun <diego at biurrun.de> wrote:
> On Sat, Jan 01, 2011 at 05:32:51PM +0100, Reimar Döffinger wrote:
>> 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.
> 
> AFAICT osdep/priority.c is only the occurrence we need to take care of.
> That should be done quickly and even less code than doing it in configure.

Let's cut this short: feel free to implement it any way you like, cygwin is not worth much effort, if it breaks things I'll fix it in a least-effort method whenever I try to compile for cygwin next time, ok? We should end up with a good-enough solution without wasting much time on discussion like that.