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

[Diego Biurrun]

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.

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

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

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

Diego