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

[Diego Biurrun]

On Wed, Jun 18, 2008 at 03:44:18PM +0200, Michael Niedermayer wrote:
> On Wed, Jun 18, 2008 at 02:31:34PM +0200, Diego Biurrun wrote:
> > 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.
> 
> I was speaking about the case with a changed file and not everything in the
> cache. Collecting many small .o files takes longer than few big .a.
> It may very well be that the old build system did other time consuming things.
> I was only considering the current build system with per libmp* .a vs the
> single big linking at the end.

You are wrong.  I ran benchmarks for the very case you are describing.
"Collecting" big files may well be faster in theory, but in practice it
is faster to link all the small files directly.  The latter is also
simpler.

What you may be overlooking is that you get extra linking stages in
between.  First you have to link the .a files, then you have to link the
final binaries.

Anyway, r26339 takes .a files from the subdirectories and a few .o
files from the root directory to link the final binaries.  HEAD
takes all .o files and links them directly.

HEAD is faster.  Period.

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

I'll have to note here that I did *not* rewrite the MPlayer build system
from scratch, I slowly refactored it.  I ended up changing/rewriting it
completely, but I did not expect this when I started.

> > > * 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?
> 
> My problem is that having to comment out lines in a file for normal everyday
> work is a very hackish solution.
> 
> make mplayer_nodep or any other command line based solution would be alot
> cleaner

Now we are talking.  Why not start out constructively in the first
place?  I shall look into it.

Diego