[FFmpeg-devel] Donations and what happens with them

Reimar Döffinger Reimar.Doeffinger
Wed Jan 26 19:25:58 CET 2011


On Wed, Jan 26, 2011 at 07:16:34PM +0100, Diego Biurrun wrote:
> On Wed, Jan 26, 2011 at 06:51:30PM +0100, Reimar D?ffinger wrote:
> > On Wed, Jan 26, 2011 at 06:20:20PM +0100, Diego Biurrun wrote:
> > > On Wed, Jan 26, 2011 at 06:13:09PM +0100, Michael Niedermayer wrote:
> > > > On Wed, Jan 26, 2011 at 03:26:04PM +0100, Diego Biurrun wrote:
> > > > > On Wed, Jan 26, 2011 at 03:12:36PM +0100, Michael Niedermayer wrote:
> > > > > > On Wed, Jan 26, 2011 at 01:48:29PM +0100, Diego Biurrun wrote:
> > > > > > > The impenetrability of the motion estimation code has already hampered
> > > > > > > development of the CAVS encoder in the past, likely other things as
> > > > > > > well.
> > > > > > > 
> > > > > > > Furthermore it slows down parallel builds by an insane amount.  If you
> > > > > > > have a few cores available, compiling motion_est.c takes up more time
> > > > > > > than all of the rest of libavcodec.  Thus all linking stages are
> > > > > > > delayed and precious developer time wasted.
> > > > > > 
> > > > > > Iam thinking the build system recompiles far too much far too often
> > > > > > Its caused by basing its design on "recompile everything that might in some
> > > > > > corner case need it"
> > > > > > a rule like "minimize the average time it takes a developer to build a
> > > > > > working binary" would work better, id much prefer to have it rebuild just 10%
> > > > > > of what it does for a 1% chance that i need to manually do a make distclean; make
> > > > > > to get a fully working binary.
> > > > > 
> > > > > ccache is your friend.
> > > > 
> > > > i guess one could hack ccache to achive that
> > > 
> > > Seriously, have you tried ccache?
> > 
> > ccache solves a problem completely orthogonal. It will not and cannot
> > fix that almost everything will be recompiled just because you changed
> > an "int" to "int32_t" in avcodec.h for example. 
> 
> Correct.  But since ccache preprocesses the code before compiling it will
> skip recompilation in cases like fixing comment typos, adding/removing
> comments, cosmetics, making changes in disabled code and similar stuff.
> I assumed these were some of the scenarios that Michael was complaining
> about.

Well, those do not have a 1% chance of going wrong, so I assumed that
he didn't mean anything that ccache can do.
Though if the issue is a slow disk (e.g. running from a SDHC card), ccache
doesn't help that much anyway.



More information about the ffmpeg-devel mailing list