[MPlayer-dev-eng] deterministic builds

[Adam Rice]

Quoting D Richard Felker III (dalias at aerifal.cx):
> 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.

Good answer. Ok, what about DVD menus? Everyone was sitting pretty with their
hands over their ears pretending that DVD menus didn't exist, then Ogle came
along. Man that thing was an ugly hack, it was amazing it worked at all, but
within weeks the inertia was broken and Xine had DVD menu support. Of course,
MPlayer is still pretending that DVD menus don't exist... ;-)

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

But this is a bit of a different kind of development than what I'm talking
about. Incremental evolution invariably is best done with expertise, but
paradigm shifts often require a certain naivety.

And you're also not acknowledging what you've given up in exchange for your
expertise. How much longer is G2 taking to develop than G1? Why do you think
that is? Expertise always brings with it a certain inflexibility, that in the
end can be more crippling than ignorance. Will G2 ever be finished?

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

I see your point, but to me it doesn't really qualify as Microsoft-esque
unless it hides bugs or is actively user-hostile.

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

I'll admit, I had wondered about that, but never took the time to investigate
properly.

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

Everyone I've ever heard express a preference loaths libtool. The same is not
true of automake.

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

I had wondered why most CVS repositories are missing the configure file,
requiring CVS users to run automake themselves. Thanks for clearing that up
for me.

Adam

-- 
Adam Rice -- adamrice at ntlworld.com -- Blackburn, Lancashire, England