[MPlayer-dev-eng] .developer cruft

Attila Kinali attila at kinali.ch
Sun Apr 2 11:04:08 CEST 2006


On Sat, 1 Apr 2006 03:51:01 -0500
Rich Felker <dalias at aerifal.cx> wrote:

> On Sat, Apr 01, 2006 at 09:55:24AM +0200, Diego Biurrun wrote:
> > I say go for unconditional recursing.  It takes 1s on my machine when
> > nothing has changed, I see no need to improve this "extremely bad
> > performance".
> 
> I can guarantee it's a LOT worse on my system. Probably 10s or more.
> This is unacceptable.

That higly depends on the disks you have and the amount of RAM,
whether you compiled MPlayer just a few minutes ago or not, etc pp.
But i agree, unconditional recursing is bad[tm]

> > Another downside of .libdeps is that it needs to be
> > updated every time things get added, shuffled around etc in the source
> > tree.  So far this has always been overlooked, just look at the cvs log
> > of etc/.libdeps.  And it's documented nowhere, few devs understand it
> > and/or use it.  IMO it is an obscure mechanism with questionable
> > benefit.  You'll need some pretty good arguments to sway my opinion.
> 
> My proposal now is eliminating all makesfiles except in the top-level
> dir and eliminating recursive make. This will solve all the dependency
> problems with no performance penalty.

I have a counter proposal: How about a top makefile that includes
the additional makefiles per directory. This way we have the files
that declare the dependency local (which is imho a good thing)
but still can build the dependency tree globaly. If you provide
a "Makefile" in every subdirectory you can even make a build of
a subtree the normal way.

 
> Until then, if no one objects my first step will be to fix things so
> that the current system works like having .developer and .libdeps.
> This will make things better in some cases, no worse in others, and
> performance will be no worse.

Go ahead.

			Attila Kinali

-- 
心をこめて聞け心をこめて話せ




More information about the MPlayer-dev-eng mailing list