[MPlayer-dev-eng] deterministic builds

[Enrico Weigelt]

* Adam Rice <adamrice at ntlworld.com> [2003-12-22 02:10:27 +0000]:

<snip>
> >                                               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?

Well, automake tends to "know things better" ... thats makes many people angry.

<snip>
> 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.
Hah, lets try to put a trojan-builder into gcc ;-)

<snip>
> The trouble is repeatability. It's no good if yesterday's MPlayer build
> depends on ALSA 1.0 and today's depends on ALSA 0.9. Clever config scripts
> are great for users, but horrible for autobuilders. It would probably help if
> configure had a standard option
> --disable-everything-i-havent-explicitly-enabled!
or smth like --no-auto ...

I also dont like "checking for header a.h ... checking for foo() in blah.h ..."
Therefore I want clear interface descriptions. If an interface foo.h is installed
on the system, so we can rely that all the functions, defines, whatever it
brings are available. Or do you regularly check the right voltage before 
switching on you coffee machine ? ;-)

<snip>
> >                        Another is to build in some sort of
> > chroot/sandbox environment where you hide extra libs.
> 
> I think this is unavoidable. To get reproducable builds you absolutely have to
> have a santised environment. Even then there's trouble with stuff that builds
> differently depending on installed kernel version.

Thats why I want to have a deterministic build system which always produces the
same with the same parameters (installed libs are not part of them, but included
features which might depend on some libs)

In other words: not checking whether libfoo is available and then include some 
support for it, but instead having a module or feature which can be enabled
and depends on libfoo.

For example in a xml presentation it could look like this:

<PROJECT name="mplayer">
    <FEATURE name="ao-esound">
	<DEPENDS interface="c-binding at libesound" />
    <FEATURE>
    <FEATURE name="vo-directx" />
	<DEPENDS platform="win32"/>
    </FEATURE>

    ...
    
</PROJECT>

> > But for mplayer, I don't see why you don't just --disable the libs you
> > definitely don't want linked...
> 
> And what happens when libcaca support is added in the next release?
And how can I find out it (w/o watching over configure --help manually)


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact at metux.de
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/