[arch-dev-public] Building mplayer

[Jason Chu]

That was me, sorry.

On Tue, Jan 22, 2008 at 06:05:55PM +0100, Thomas Bächler wrote:
> I have been maintaining mplayer for a while now. Unfortunately, during
> my absence mplayer had to be rebuilt by someone else. The x86_64 version
> (built by Eric) is fine, but the i686 (built by someone who doesn't know
> what the "Packager" option in makepkg.conf is for) version is missing
> features (bug #9288).

The Packager option wasn't enabled because I was building in a chroot ;)

> The mplayer build system sucks. Seriously, it is the worst idea people
> have ever had, but the guys who are currently maintaining it are proud
> of it (I had the pleasure of arguing with one of them about autotools
> vs. mplayer during a two hour car trip last summer).
> 
> Here is the thing:
> In autotools, you can use --enable-FOO to force configure to enable a
> feature. However, configure still checks if all libraries and headers
> are present and will add the needed options to gcc, or abort if a check
> fails.
> 
> In mplayer, --enable-FOO forces the build system to enable a feature,
> but also skips all checks and doesn't add any options to the compiler,
> thus making 'make' fail unless you modify Makefiles by hand. This is not
> only unintuitive but also completely inconsistent with the way autotools
> work. The only way to properly enable a feature in mplayer is to put no
> --enable or --disable flag in and hope that configure's autodetection
> detects it properly. And of course you have to check if everything went
> fine after configure finished by reading the output summary. I don't
> have to tell you that this is very distributior-unfriendly.

Eww.

> Since there is no way to force mplayer's configure to abort if something
> we want is missing, we must have the necessary makedepends listed -
> which we don't, as they are not easy to determine. The only way to
> properly build mplayer is to watch everything it does carefully and
> abort if something is wrong.
> 
> For a while, a "we need clean build chroots so that our packages are not
> corrupted" attitude has spread, and this is exactly what broke mplayer
> (I have no idea which makedepend may be missing though).

I hope you didn't say that in a derisive sort of way.  I still think
building in chroots is an excellent idea.

I'm really not trying to be defensive or passive aggressive, but wouldn't
it be great if mplayer did have all the makedepends listed properly?  Then
we could rebuild it in a chroot *and* have all of the features enabled.

> So please, unless you know exactly what you are doing and have much time
> to check everything, don't build mplayer!

I'm very sorry about rebuilding this thing.  Here's my documentation
surrounding it:

http://bugs.archlinux.org/task/8864
http://archlinux.org/pipermail/arch-dev-public/2007-December/003627.html

So, next time I won't update mplayer.  I'll just be part of the crowd
shouting "Rabble rabble rabble rabble".

Jason
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-dev-public/attachments/20080122/72567ac5/attachment.pgp>