[MPlayer-cvslog] CVS: main configure, 1.1137, 1.1138 Makefile, 1.342, 1.343

[Ivan Kalvachev]

2006/3/6, Diego Biurrun <diego at biurrun.de>:
> On Mon, Mar 06, 2006 at 10:28:14AM +0100, Jindrich Makovicka wrote:
> > On 3/6/06, Diego Biurrun <diego at biurrun.de> wrote:
> > > On Mon, Mar 06, 2006 at 08:06:14AM +0100, Jindrich Makovicka wrote:
> > > > Diego Biurrun wrote:
> > > > > On Sun, Mar 05, 2006 at 11:03:55AM +0100, Jindrich Makovicka CVS wrote:
> > > > >
> > > > >>Modified Files:
> > > > >>    configure Makefile
> > > > >>Log Message:
> > > > >>use relative paths for libav* build
> > > > >>
> > > > >>absolute path in the command line can confuse ccache
> > > > >
> > > > > What were the problems with ccache?
> > > >
> > > > when compiling the same (or almost the same) revision, but in different
> > > > directories, ccache sees it as different compilations, because the
> > > > command line has changed. so libav* gets compiled all the time.
> > >
> > > I'm not sure I understand entirely, please elaborate.  This sounds like
> > > a problem with ccache...
> >
> > (AFAIK) Ccache computes a hash of the compilation from 3 parts:
> >
> > 1) compiler binary
> > 2) compiler command line
> > 3) preprocessed compiler input
> >
> > if you compile mplayer twice in directories with different names, 2)
> > is different for libav*, so ccache doesn't find the result of the
> > previous compilation and runs the compiler again.
>
> You mean if you have two different MPlayer checkouts?  ccache should
> pick this up the second time you compile anyway..

Not if you have the date in the project name.
(e.g. CVS daily checkouts, that seem to be non-operational atm).

Anyway, ccache have option to separate objects from different
directories (needed for source debuging) and sabotaging the default
behaviour is really bad side effect.

> > > Please revert your commit unless you can come up with good arguments
> > > that make me change my mind.
> >
> > I'll be able to revert it when I get back home. Feel free to do it sooner.

BTW Jindrich, even if you workaround MPlayer, then FFMpeg will still
suffer from the same issue. It must be fixed there too.