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

[Michael Niedermayer]

On Tue, Jun 17, 2008 at 02:57:16PM +0200, Diego Biurrun wrote:
> 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.

Not sure about you, but i do change some c files between running make.
Also not everything might be in the disk cache like it is in your 
make; rm mplayer; make
Id be more interrested in the results with a changed c file and a flushed
cache. (and changed means not a change that has been compiled in the past
and is in ccache)


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

Well whatever you say, fact is that to do development in ffmpeg & mplayer
i had to 
-	$(DEPEND_CMD) > $@
+	touch $@

Because it otherwise rebuilds litterally everything when any header is
changed, even with ccache that is rather slow.
For testing a patch and for the end user what the makefiles do currently
is fine. For doing actual development it is not.
If i change a header a dozen times and know that it will only need rebuilding
of one file iam really a few hours quicker if i rebuild that file instead
of the distclean equivalent that is done in svn currently.


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

I had the feeling he was togeter with gabu pushed out of the project
similarly to how i and others are now.


> and Arpi himself
> said that he did no longer understand the filter layer completely
> anymore.

The filter layer is one thing of many, it is complex, one can rewrite it
to make it simpler but it means loosing features and performance.
Besides what did uoti improve on the filter layer? I remember rich, ivan
and me in the distant past working and flaming about it but uoti?
Besides the filter layer doesnt need a rewrite it needs someone better
documenting it and fixing the existing issues. Of course one day it
might be droped in favor of libavfilter but that will need some time
as well, for working on the remaining issues in lavfi and porting all
filters ...
lavfi can do a few thing the mplayer layer can not like arbitrary filter
graphs, but then lavfi does not yet support everything the mplayer filter
system supports ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20080617/3f846a5b/attachment.pgp>