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

[Eric NICOLAS]

Hi,

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.

Thanks !