[MPlayer-cvslog] r32724 - trunk/configure

[Diego Biurrun]

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.

Diego