[MPlayer-dev-eng] [PATCH] factorize print_version()

[Uoti Urpala]

On Mon, 2009-01-12 at 23:51 +0100, Diego Biurrun wrote:
> On Tue, Jan 13, 2009 at 12:37:06AM +0200, Uoti Urpala wrote:
> > The code can be moved back later reasonably easily, but is it really
> > beneficial even in the short term? MEncoder is quite rotten already. As
> > long as MEncoder is not really maintained MPlayer quality is what
> > matters, and IMO it's worsened by changes like this.
> 
> I think the change is worth the trouble.
> 
> It will make my life easier when I fix bug 1378 and it will make my
> life easier when I update the copyright notice next year.  So I think
> it's beneficial in the short term and not a big deal in the long run.

That sounds like less benefit than even just the work needed to do the
change itself...

> If you think print_version() should be put in a different place, I'm
> all ears.  But basically anything that makes mplayer.c smaller cannot
> hurt IMO.

I do intend to split mplayer.c further at some point. But I have not yet
decided what the best way would be. Doing an arbitrary split completely
at random or based on whether the code has something in common with
mencoder.c is not an improvement.

> > MEncoder has lots of duplicated functionality, much of it an inferior
> > version of the MPlayer code. That's exactly why encoding should be
> > implemented on top of MPlayer's frame generation if MEncoder is to be
> > developed further. Splitting random pieces of MPlayer between "common"
> > and "non-common" files and using those in some individual parts of
> > MEncoder isn't really getting any closer to that goal.
> 
> Maybe, but at least MEncoder will get the bug fixes applied to the
> common parts.

And will make those bug fixes and improvements much harder to do if
MEncoder relies on the code working the old way. That's already a
problem in some of the code in the subdirectories. As long as MEncoder
remains fundamentally broken, tying MPlayer more tightly to it via
additional shared code is a bad thing.