[MPlayer-dev-eng] Proposal : library for increasing MPlayer portability
Diego Biurrun
diego at biurrun.de
Tue Jan 14 11:05:37 CET 2003
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.
More information about the MPlayer-dev-eng
mailing list