[FFmpeg-devel] Donations and what happens with them

Reimar Döffinger Reimar.Doeffinger
Wed Jan 26 18:51:30 CET 2011


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. 



More information about the ffmpeg-devel mailing list