[MPlayer-dev-eng] deterministic builds

[D Richard Felker III]

On Mon, Dec 22, 2003 at 02:10:27AM +0000, Adam Rice wrote:
> Quoting D Richard Felker III (dalias at aerifal.cx):
> > Forgive me for being upfront about this, but it doesn't sound like you
> > have 1% of the experience needed to make a distribution.
> 
> You never have the experience you need until after you need it... that's life.
> I would never try to do something like this, because I can think of a hundred
> reasons why it wouldn't work. Sometimes it takes someone who doesn't know why
> it shouldn't work to try something and find that it does work. Back when
> MPlayer was started, it was common knowledge that proprietary codecs couldn't
> be reverse engineered.

IHMO not. It was common knowledge that they _could_ be reverse
engineered, just no one had the time or motivation, or the experience
to do it. They didn't get reverse engineered because some naive,
inexperienced newbie said "Hey I bet I can reverse engineer Sorensen!"
They got reverse engineered because having good, free-software movie
players gave a few talented individuals, who were already _experts_,
an immediate target platform for their code, and a great deal of
popular demand for it.

As another example, take MPlayer and G2. Right now I'm working on
making sure G2 has the best possible video processing capabilities.
The reason I'm able to do this with a good deal of success is because
I learned a lot from the limitations of G1, and the poor hacks I
myself made when writing video filters for G1. Understanding the
problem is virtually always the key to solving it.

> > Uhg... Automake is the bane of compile-from-source systems! It makes
> > software take twice as long to build,
> 
> Twice as long compared to what? I've used auto-configure systems that were
> faster, but I wouldn't count mplayer's among them. Obviously nothing is as
> fast as compiling without configuration, but then, nothing is as slow as
> configuring software manually.

The actual compile. automake/libtool wraps every call to gcc in its
horrible shell scripts, and moves files around (hidden .libs dir,
uhg!!) every time. If you have a slow filesystem (think nfs, or even a
slow hd) or an operating system where fork is expensive (think
cygwin), then running gcc with the libtool wrapper takes well over
twice as long as running it straight.

> >                                       completely obfuscates the
> > process so you can't see what's going to get installed where (ever try
> > "make -n install" with an automake project?),
> 
> Fair comment.

This is the first example of "Microsoft-esque". See below for another.

> >                                               and uses all sorts of
> > microsoft-esque techniques to hide what's going on from the user.
> 
> Microsoft-esque? I have to confess I haven't used the latest version of
> automake, does it popup an animated gif saying "configuring" and refuse to
> tell you what it's doing?

Research how libtool's .libs system works. It's a horrible hack! Your
'binaries' are actually shell scripts, with the real binaries hidden
in .libs, until you make install! Also, certain files will get
recompiled at "make install" time, which means compiling as root (very
bad!) and thus root-owned files in your user's source dirs!

Granted libtool and automake are not the same, but they're so
incestuously intertwined they might as well be...

> > (This happens to make it exceptionally great for hiding trojans in the
> > build system, too.)
> 
> As opposed to MPlayer's 6000 line shell script? Hell, anything more
> complicated than gcc *.c could hide a trojan, and I'm not even sure I'd trust
> that.

Every change to MPlayer's configure script is reviewed by each
developer as it's committed to cvs. On the other hand, if you update
configure.ac and generate configure from it, the configure.ac commit
will be human-readable (and will be reviewed), but the configure
commit might as well be a binary file! No one will review it, because
it's so horribly unreadable, so any contributor with cvs access could
put trojan code in it!

Rich