[MPlayer-dev-eng] latest mingw network patch

[D Richard Felker III]

On Sat, Jun 07, 2003 at 11:22:16PM -0500, Joey Parrish wrote:
> On Thu, Jun 05, 2003 at 03:56:36PM -0400, D Richard Felker III wrote:
> > > Once the mingw port is complete, then cygwin should be deprecated.
> > > Then cygwin-specific support itself can be removed and -mno-cygwin
> > > (IIRC) can be added to Makefile for cygwin systems to make it mingw
> > > compatible.  Or is it -mmingw?  I forget exactly, but there is a gcc
> > > option or two on cygwin to emulate mingw.  Anyhow, I think this should
> > > be our eventual goal for windows systems.
> > 
> > IMO this is a bad idea. No reason to remove cygwin support if it
> > works. Some people already use cygwin regularly under windows, and
> > want to built a program that will operate properly in their cygwin
> > environment. So as long as it's no extra work to support cygwin
> > (shouldn't be), don't arbitrarily remove support, and PLEASE don't do
> > like the SDL fools and make it force -mno-cygwin on cygwin (which kept
> > people from compiling posix-dependent progs against SDL, e.g.
> > mplayer).
> 
> This should also answer (hopefully) Diego's mail.
> 
> What I'm saying is that since Cygwin is an emulation environment.  If we
> have a working cygwin port, then the cygwin DLL is calling certain
> native windows functions.  If we port to mingw, then we are calling all
> these things ourselves directly.  This leads to greater efficiency IMHO,
> and also more portable code in general by abstracting the
> operating-system specific things.
> 
> Since the cygwin environment can compile code that is independant of the
> cygwin DLL by using the mingw runtime, there's no reason to use anything
> else.  Native windows binaries run fine in cygwin, too.  :)
> 
> As for being like SDL, the problem with SDL lies in the fact that it is
> a library that tries to force -mno-cygwin on it's apps.  That is not at
> all the case for mplayer, so I believe that this will not be a problem.
> 
> Anyone have other thoughts?  Did I miss anything?

Yes. In the future mplayer might want to [optionally] have access to
unix-specific functionality which cygwin could provide, but which
would not be easy to implement in the mingw port. Also some users may
just prefer to have a clean all-cygwin environment, or might want to
use free software (cygwin's dll) rather than non-free (msvcrt).

Whatever the reasons, there is no excuse for shutting out user choice.
MPlayer should build as mingw by default on mingw and as cygwin by
default on cygwin. If the user wants to build a mingw binary using
cygwin, you can have them pass --enable-mingw or something to
configure...

Rich