[MPlayer-dev-eng] .developer cruft

[Rich Felker]

On Sat, Apr 01, 2006 at 09:55:24AM +0200, Diego Biurrun wrote:
> On Fri, Mar 31, 2006 at 03:16:26AM -0500, Rich Felker wrote:
> > On Fri, Mar 31, 2006 at 09:30:09AM +0200, Diego Biurrun wrote:
> > > 
> > > While we're at it, why is .libdeps needed at all?
> > 
> > It's just a set of rules to make the main makefile recurse into
> > subdirectories if any files in the subdirs have changed.
> > Unconditionally recursing into them is also possible but would make
> > performance extremely bad in the common case where nothing has
> > changed.
> 
> 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.

> 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.

> > Of course I'd be happiest if we could eliminate recursive make
> > altogether...
> > http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html
> 
> I've read that paper as well, but while the rant is completely right in
> theory, the practical instructions for implementing non-recursive make
> are missing from it.  Where are the examples of non-recursive make
> usage?  The whole world seems to happily use it recursively...

The whole world does a lot of stupid things. :)))))

Look at my libc for a good example -- a single 69-line makefile drives
the whole build with multiple levels of directories. Naturally a bit
more is needed to manage all the different imported libs and stuff
that MPlayer uses, but I don't think it will be particularly bad.
Let's see if I can do it...

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.

Rich