[MPlayer-dev-eng] [PATCH] MinGW compile fix, header order policy suggestion

[Rich Felker]

On Tue, May 31, 2005 at 12:27:25PM +0200, Reimar Döffinger wrote:
> Hi,
> On Tue, May 31, 2005 at 12:26:55PM +0300, Ivan Kalvachev wrote:
> > I don't think this needs to be enforced because it is an good
> > programer writing style.
> 
> Well, that probably means we have very few good programmers? The order
> is often different - which isn't so bad, except for the fact that even
> in cases where there is a good reason for it it is not explained...
> 
> > As for the current situation, fixing this way is even worse than not
> > fixing it. The right way is to avoid all possible collisions and
> > change STREAM_SEEK to MP_STREAM_SEEK. Otherwise the assigned value may
> 
> But for consistency all STREAM_* defines would have to be renamed...
> That would be a gigantic patch!
> 
> > be same as another defined STREAM_* label that would be produce an
> > VERY hard to track bugs. The only clue we may find for this bug, is an
> > warning that is hidden in the 200k warnings mplayer emits. There could
> > be an even worse situation as STREAM_SEEK may not be defined as value
> > or constant...
> 
> As I said, in this case STREAM_SEEK is a typedef'ed struct in the
> windows headers, so this can only lead to compile errors, so it's not
> quite as bad...

Windows is incredibly broken for naming structures so stupid, and
polluting the namespace from required headers. I suggest we wrap the
windows includes with some #define/#undef crap to fix this, or (imo
much better) drop use of the windows includes altogether, and make our
own mingw includes for mplayer just just define the minimal number of
types/protos/etc needed to compile. Obfuscating MPlayer source to work
around namespace pollution on a shitty os is not acceptable as far as
I'm concerned.

Rich