[FFmpeg-devel] [PATCH] remove disabled code part 1

[Diego Biurrun]

On Tue, Aug 18, 2009 at 10:22:05PM +0200, Michael Niedermayer wrote:
> On Tue, Aug 18, 2009 at 03:20:55PM +0200, Diego Biurrun wrote:
> > On Mon, Aug 10, 2009 at 02:56:49PM +0200, Diego Biurrun wrote:
> > > On Fri, Aug 07, 2009 at 02:23:45PM +0200, Michael Niedermayer wrote:
> > > > On Fri, Aug 07, 2009 at 11:15:19AM +0200, Diego Biurrun wrote:
> > > > > I started looking into disabled code, there is lots of it and probably
> > > > > mostly cruft.  Here is a patch that removes it, starting at the top
> > > > > level and the tests subdirectory.  More patches shall follow later.
> > > > > 
> > > > > I will commit approved hunks only.
> > > > 
> > > > remaining hunks i didnt comment on are "dont know what it does exactly / not
> > > > sure if usefull"
> > > 
> > > The stuff from ffplay.c originates from the first revision of ffplay and
> > > has never been enabled.  Is this proof enough that it is cruft and
> > > should be removed?
> > 
> > .. ping ..
> 
> no, its not proof that its cruft and should be removed.
> Maybe it is cruft but age is no proof, I just like to understand what that
> code did before its droped ...

What could be proof then?  I just tried enabling the code, it does not
even link, since it references a nonexisting macro/function: QERGB.  A
function or macro by that name has *never* existed in FFmpeg, so the
code has *never* worked.  If that is not proof that the code is cruft,
then what can be?

> If you or someone else can guess what it could have been good for? then we
> can make a decission based on that but i dont like throwing unopened boxes
> away ;)

Never heard of the following strategy to get rid of cruft after moving
houses?  Leave everything in boxes, do not unpack anything.  Then get
things out of the boxes strictly as you need them.  After a fixed time,
say a month or six months, you throw away all remaining boxes unopened.

:)

Diego