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

[Diego Biurrun]

On Tue, Jan 29, 2008 at 09:16:42AM +0300, Evgeniy Stepanov wrote:
> On Tuesday 29 January 2008 01:44:55 Diego Biurrun wrote:
> > On Mon, Jan 28, 2008 at 07:21:02PM +0300, Evgeniy Stepanov wrote:
> > > On Monday 28 January 2008 18:37:39 Reimar Döffinger wrote:
> > > [...]
> > >
> > > > And is anyone (particularly the maintainer) against using LIBASS_
> > > > instead of ASS_, and consistently use LIBASS_FILENAME as name (if that
> > > > is not already the case)?
> > >
> > > I don't mind.
> >
> > I was not aware that you consider libass a separate project complete
> > with sourceforge homepage and whatnot.
> >
> > I'll gladly give all the headers in libass/ a consistent prefix.  Shall
> > it be LIBASS_ then?
> >
> > It might be a good idea to go ahead and give all our headers a
> > consistent prefix, MPLAYER_ comes to mind.  In loader/ we have a mixture
> > of LOADER_, AVIFILE_ and no prefix.
> 
> No, this is not about separate projects. I think that MPUTILS_H is too short 
> and we are just lucky there is no other mputils.h anywhere in mplayer.

No, this should never happen.  Having two files with the same name in
two different places is a bad idea to begin with and should be avoided.

> I'd suggest using directory names in all inclusion guards:
> LIBASS_MPUTILS_H, LIBMPCODECS_VF_H, so on. Maybe even a full path:
> LIBMPCODECS_NATIVE_MMX_H. Bandwidth is cheap these days :)

I don't think this is a good idea, it would need updating if/when we
moved stuff around.  I think it's better to use a consistent prefix for
everything.  For all MPlayer stuff it should be just MPLAYER_ IMO, if
you consider libass a separate project, then it can be reasonable to
give it its own individual prefix.

Diego