[MPlayer-dev-eng] [RFC] Makefile copyrights

Diego Biurrun diego at biurrun.de
Tue Jun 17 14:57:16 CEST 2008


On Sat, Jun 07, 2008 at 04:11:34PM +0200, Michael Niedermayer wrote:
> 
> * Its faster to build a .a per directory and then combine them than collect
>   all .o files if one changed. (simple matter of less collecting
>   recompile one c file collect all .o of one dir collect all .a vs.
>   recompile one c file collect all .o of the whole project)
>   seeks are slow reading lots of files is slower than reading one
>   big one ...

This is not true.

I just did a quick benchmark comparing r26339 with HEAD.  I configured
both trees with the same options and then ran make in them.  After that
I ran 'rm mplayer mencoder' and then 'time make' in both trees in order
to benchmark just the last linking step.  Results vary by 0.1 seconds,
but both are always around 9.8s.

Of course HEAD skips all the separate linking steps in the
subdirectories, so total linking time has gone down.

> Anyway, everyone rewriting something knows his code is better than before
> in every respect. It rarely is though, especially if the old code is the
> result of years of bugfixes.

The old build system is not the result of years of bug fixes, but the
result of years of hacks.  I had to look at the old VIDIX Makefiles
recently, my eyes were bleeding.

Much of the old build system looked like a competition in redundant
programming.  r21275 alone removed 435 lines (of about 2000 IIRC)
without changing one iota of functionality.

There were always a lot of problems and the solution was to recommend to
distclean between every make run.  At some point the build system even
did this automatically.

I would guesstimate that configure could be reduced to 2000-3000 lines
instead of 8947 if it were refactored cleanly, like the FFmpeg
configure.

> (this applies to uotis improvments more than the makefiles heres but
> still)

You are painting a rose-tinted picture of the past.  Arpi gave up on
MPlayer because he thought he had created an unmaintainable monster.
There were longstanding issues that nobody addressed and Arpi himself
said that he did no longer understand the filter layer completely
anymore.

Diego



More information about the MPlayer-dev-eng mailing list