[MPlayer-dev-eng] [HACK] fix compilation for menu and gui

Reimar Döffinger Reimar.Doeffinger at stud.uni-karlsruhe.de
Wed Feb 21 19:17:05 CET 2007

On Wed, Feb 21, 2007 at 07:46:49PM +0200, Uoti Urpala wrote:
> On Wed, 2007-02-21 at 18:24 +0100, Aurelien Jacobs wrote:
> > Before this gets applied, I would like to know if the rule to never
> > #include a header from the inside of another header was still true ?
> > Here it would greatly help to include all the needed headers in
> > mp_core.h. This would avoid adding a dozen of headers in every
> > libmenu file.
> Requiring all the headers (even automatically included) when accessing
> the internals from outside could be avoided in two ways at least:
> 1) Since most of the variables are pointers they could be declared as
> the corresponding struct pointers instead of using the typedef names.
> That wouldn't require the headers containing the full typedefs.
> 2) Create functions in a file which already includes the headers to get
> certain fields from an MPContext.
> I think I'll add 2) for now for the fields required in libmenu and GUI
> as the number of internal fields used isn't too large. Maybe it'll need
> to be changed in the future if more fields are moved to the struct and
> nobody changes the GUI not to use the mplayer.c internals directly so
> much.

I don't see how 2) helps with this patch at all, unless you combine it
with my suggestions.
If you want to invest your time, please invest it in 1), esp. making
struct MPContext available as an opaque struct.
There is really no point in requiring all of stream_t, demuxer_t,
sh_audio_t, sh_video_t, demux_stream_t, mixer_t, vo_functions_t, ... to
be defined just to pass this on to some of the property functions.

Reimar Döffinger

More information about the MPlayer-dev-eng mailing list