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

Diego Biurrun diego at biurrun.de
Wed Jun 18 14:31:34 CEST 2008


On Wed, Jun 18, 2008 at 02:56:37AM +0200, Michael Niedermayer wrote:
> On Wed, Jun 18, 2008 at 01:27:37AM +0200, Diego Biurrun wrote:
> > On Tue, Jun 17, 2008 at 07:39:31PM +0200, Michael Niedermayer wrote:
> > > 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)
> > 
> > Once more, this time with ccache disabled.  I do
> > 
> > touch libmpdemux/demuxer.c libmpcodecs/vd.c && time make
> > 
> > and the results are that HEAD with dependency generation disabled takes
> > 14s, r26339 takes 15.4s.  Accept it, link times have decreased.
> 
> A normal development cycle is to edit a c file run make
> perform some tests & benchmarks (maybe the regression tests in ffmpeg)
> these will flush the cache if it hasnt been flushed by the time due to
> other things running, then goto 1.
> 
> Besides, "HEAD with dependency generation disabled"? so you compare the
> unchanged old build system against the new + some hacks to make it faster?

I am comparing apples to apples.  Your first claim was that link times
would increase with the new system.  This is false.

For libmpdemux dependency generation takes 11.4s in r26339 against 2.8s
in HEAD, libmpcodecs is 24.9s vs. 2.8s.

If you want to compare total build times (which is of course different
from build times), then just

touch libmpdemux/demuxer.c libmpcodecs/vd.c && time make

takes 17.6s on the first run and 15.4s on subsequent runs with r26339
while HEAD takes 17.2s on the first run and 16.6s on subsequent runs.

The first run should not be using the disc cache.  To make doubly sure,
I ran a grep for a random string through some Linux kernel sources I had
lying around.

After that, r26339 took 16s on the first run and 15.4s on the second
while HEAD took 16.8s on the first run and 16.6s on the second run.

BTW, this is a K6-III 500 with 512MB RAM and 3 4GB SCSI discs running
as RAID 0, probably the slowest machine of any current MPlayer developer.

> > > > > 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.
> > 
> > Just comment out the last line in the MPlayer Makefile or the last line
> > of common.mak in FFmpeg, much more effective.
> > 
> > > 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.
> > 
> > Then comment out a line if you do not like it.  This is hardly asking
> > much.
> > 
> > Anyway, this has no relation to what I said and no relation to linking
> > once or linking (more or less) per directory.  Automatic dependency
> > generation is a completely separate issue.
> 
> * How to use the new shiny build system?
> -  comment out the last line in the MPlayer Makefile or the last line
>    of common.mak in FFmpeg
> 
> Glad, its not as hackish anymore as it was in the past.

It is working correctly now, which it did most definitely *not* do in
the past.  Also, it now automatically generates dependency information.
You know, some people do find this useful and this was a requested
feature.  auto* does it as well.  If you dislike automatic dependency
information generation, disable it.

What's your problem?  I don't think commenting out one line is asking
too much of you, is it?

> > > > > (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.
> > 
> > Wow, now he was being "pushed out" of the project and Gabu, too...
> > 
> > Next time we talk, I'm sure you will have the feeling that I was the
> > one that led the mob with a pitchfork ...
> 
> I did not know you had a pitchfork

Just bought one yesterday.  You know, tar and feathers are no good if
you cannot prod your victims with a pitchfork ;)

> > > > 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.
> > 
> > No contradiction to what I said.
> > 
> > > Besides what did uoti improve on the filter layer?
> > 
> > I said nothing about Uoti and the filter layer.
> 
> so your reply had nothing to do with what i said and the occurance of 
> "filter layer" in your reply was a typo?

I replied to what you said.  Why you started talking about Uoti and the
filter layer when I only mentioned Arpis statement about the filter
layer - I do not know...

Diego



More information about the MPlayer-dev-eng mailing list