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

[Rich Felker]

On Thu, Jun 02, 2005 at 11:31:18AM -0500, Joey Parrish wrote:
> On Tue, May 31, 2005 at 08:30:21PM -0400, Rich Felker wrote:
> > 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.
> 
> Windows may be a pain, but you're saying "Windows pollutes namespace" when
> we are doing the same.

False. You inherently cannot pollute the namespace in your own
program; it belongs to you. System headers and libraries meant to be
used by other programs are the ones capable of polluting.

In addition, STREAM_SEEK is not defined all over MPlayer, only in the
files that need it (demux/stream related). So this is certainly not
pollution.

> from us.)  Renaming to MP_STREAM_SEEK is a better idea, IMHO, because
> then we aren't fighting a namespace war against an OS who cares nothing
> for open source devs.

And should we obfuscate every single symbol in MPlayer like this? NO!
There is no war unless we use broken mingw headers. Just remove them
and prototype the 5 or 10 functions you need manually.

>  We _could_ play a game of adding countless
> #define/#undef around each MingW include, but what's the point?  It'll
> just happen again later, and then we'll have a huge unmanagable mess
> around every file that needs a windows header on MingW.  Any fix other
> than renaming to MP_STREAM_SEEK (or something similar) simply does not
> scale.  I think it would be foolish to wrap the windows headers.

Well it will not be renamed. We will not have our symbol names
dictated by windows crap. MPlayer policy has always been to work
around broken systems individually, not change our code to suit them.

Rich