[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

[Evgeniy Stepanov]

On Jan 29, 2008 12:11 PM, Diego Biurrun <diego at biurrun.de> wrote:
> 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.

The same files are used in standalone library version, so it would be
better to use LIBASS_ prefix.