[MPlayer-cvslog] r25897 - in trunk: libass/mputils.h libmpcodecs/ae.h libmpcodecs/ae_faac.h libmpcodecs/ae_toolame.h libmpcodecs/ae_twolame.h libmpcodecs/mpc_info.h libmpcodecs/native/mmx.h libmpcodecs/vqf.h libmpdemux/demux_xmms_plugin.h libvo/f

[Ivan Kalvachev]

On Jan 28, 2008 3:55 AM, Ivan Kalvachev <ikalvachev at gmail.com> wrote:
> On Jan 28, 2008 3:32 AM, diego <subversion at mplayerhq.hu> wrote:
> > Author: diego
> > Date: Mon Jan 28 02:32:52 2008
> > New Revision: 25897
> >
> > Log:
> > Consistently use uppercase filename as multiple inclusion guard.

Ok, it seems that I need to clarify what the problem is.

Diego where have you read that the definition used in multiple
inclusion guard must follow the filename excactly? Is that rule you
made up by yourself using common sense or you read it somewhere? Have
you asked some skilled developer about this change or you just went
away and did what you wanted?

The obvious problem here is that until this change the guards were
formed in manner <PROJECT>_<FILE> .
The idea is that filenames are somehow common among projects. What
would happen if you enforce your coding style to FFmpeg too?  For
example:
/usr/include/pnm.h defines guard _PNM_H_,  you define guard PNM_H,
FFmpeg defines FFMPEG_PNM_H.
And there are more short and common names around: ae.h;mmx.h;fifo.h etc...

If two files define same guards then including one of them would
silently break the other. This is why guards are as much descriptive
as possible.
This is also one of the reasons I'm against spawning guards mindlessly.

I'm not saying that your commit broke something, but shortening these
guards made it more likely to break something in future.
If you don't like stuff like "ASS_SOMETHING","MPSTUFF" then change it
to "LIBASS_SOMETHING","MPLAYER_STUFF".