[MPlayer-dev-eng] Proposal : library for increasing MPlayer portability

[Diego Biurrun]

Hi Eric!

The Windows port you are planning is quite a huge task.  While I would
welcome such a project (I use the Cygwin port sometimes), I am afraid
that this big project might never get finished or - worse - not even
get started because of its sheer size.

So how about splitting this up into several smaller chunks?

A good start IMHO would be helping out the Cygwin port.  Win32 DLLs do
not work ATM, VCDs are not supported (I'm not sure about DVD - I don't
have a DVD drive), OpenGL and SDL have problems (this is probably
secondary).  All of these sound like things that would have to get
tackled for a proper Windows port, too.  And all of these things
should work, so it's just a matter of shaking out the bugs.  Also it
should not be a bad introduction to MPlayer hacking.  You might tackle
a mingw port next or maybe a native GUI or an installer.  Eventually
you might wish to try the VC port, but I suspect this is the hardest
part and the most difficult to contribute back to and sync with the
Unix MPlayer as explained by A'rpi..

Do as you wish, of course.  I just think it would be a shame to see
your efforts go to waste or never come to fruition.

Good luck

Diego

Eric NICOLAS writes:
 > As I'm new to this list and to MPlayer developement, let me introduce myself.
 > I am a 30-year old developer working mainly doing C++ developements for
 > a big financial institution in France. I run Windows and Linux at home, and
 > Windows only at work.
 > 
 > My main interest here (as I explained already in the "users" mailing list)
 > is that I would like to get to a proper windows port of MPlayer, which means:
 > - Be able to compile it with a native windows compiler (Visual C++ 6 oer 7)
 > - Have all major codecs to compile as well, with optimisations
 > - Have the GUI ported
 > - Create a setup program for binary distribution
 > 
 > I started to have a look at the code in order to see what would be the tasks.
 > I've seen several problems with compiling under Visual C++:
 > 
 > - Wide use of "#include <unistd.h>" and "#include <inttypes.h>", both of 
 >   which do not exist in Win32
 > - Wide use of "inline" which is not supported when compiling C with VC++
 >   (__inline is supported, though)
 > - Use of inline assembly with specific GCC syntax
 > 
 > Those may cause problem when trying to port MPlayer to other platforms as
 > well (I mean native ports, not cygwin stuff) (MacOS for instance).
 > 
 > IMPORTANT : I AM NOT ASKING FOR YOU GUYS TO DO ANY WORK IN THAT DIRECTION.
 > I AM OFFERING TO DO THE WORK MYSELF AND TO SUBMIT IT TO THE MAIN MPLAYER
 > TREE.
 > 
 > However, I would like to propose to you how I want to do it, in order to
 > know if you agree and if it goes "in the right direction" for you.
 > 
 > Basically, I would like to introduce a new library "libpl" (for Portability
 > Layer). This library would provide:
 > - An autoconf script for Unix platforms, with proper automatic detection
 >   of some features (inttypes.h, unistd.h, other C library functions)
 > 
 > - Replacement code for missing features (int types definition when inttypes.h
 >   is not there, stubs for missing C library functions, ...)
 > 
 > - Some macro definitions for different features (inline vs __inline, ...)
 > 
 > - A "config-win32.h" file for win32 code configuration
 > 
 > >From there, the main "configure" script in MPlayer (which is not autoconf, right?)
 > would call this sub-configure, and all other modules would rely on this library
 > for portability (i.e. would not #include unistd or inttypes directly, would use
 > the config.h from this library, etc...).
 > 
 > I would do this port one library after the other, but would like to know 
 > whether it would be ok for me to submit patches for those changes after each 
 > library is successfully compiled under Visual C++ rather than a jumbo patch
 > at the end of the project. This way we would all be more assured that we don't
 > loose synch too much.