[MPlayer-dev-eng] deterministic builds

[Enrico Weigelt]

* Arpi <arpi at thot.banki.hu> [2003-12-19 21:19:14 +0100]:

Hi,

<snip>
> > While playing a while with ./configure i've noticed some things:
> > (version 1.0.0.2)
> 
> wtf? there is no such version.
> the latest is 1.0-pre3, which is <1.0
oh, yeah, you're confused because of my "normalized versioning" system.
in this case 1.0.0.x means 1.0.pre-x.

I need such mappings to an uniformed version number for my buildfarm, 
so it can always clearly compare versions by numerical operations.

> > * some common automake parameters like --sysconfdir are not supported
> > * many feature options are only available as --enable-xxx or --disable-xxx
> >   (the default setting seems not to be supported as explicit parameter)
> > * there seems to be no way for finding out what build configuration 
> >   configure is in fact using.
> 
> mplayer doesnt use autoshit (auto* tools).
> it has own, custom, unique hand-written configure script.

Ohah. That's a good step into the right direction :)

BTW: (sorry, for the little OT)
I'm also working on another build system, which does not work as frontend
to make anylonger, but goes into an new direction:

Evrything is modeled into a tree of nodes which describe what components
the software consists of, i.e.
    
    --> project test
	--> executable foo
	    --> source foo.c
	    --> source blah.c
	    --> import gtk>=1.0
	    --> import @misc>=2.0
	--> library misc = 2.0
	    --> source misc.c
	    --> header misc.h	
    ...
    
This should describe the software's structure on the highest possible level,
so many many tools, can work on it, i.e. for completely automated builds
and constraint tests, etc.
(The tree-like modeling perhaps reminds a little bit on borland's 
C++ builder UI)

No code written yet, but a heap of painted paper ;-)
Perhaps some of you 'd like to work on such a build system.


> > Those things are a nightmare for distributors.
> 
> mplayer is not designed for binary distribution. some time ago it was
> even disallowed, now it's allowed but not recommended by us.
> users should do customized builds for their cpu, libs and video hardware.
I do not want to do this on my own every time, but instead let the 
computer do it alone.

Perhaps I have to tell you a little bit more about the stuff I'm working on.
Its not yet another distro, but instead a huge meta-distribution which
virtually contains all build variants of a package from which the computer
automatically chooses the best one.

You can see binary packages as a kind of cachefiles at this point. The 
buildfarm knows what variants and options a packages provides and what
platform, hardware, etc the package should be built for. I.e. in a networked
setup the workstation's package manager checks out tries to find the best
matching package and if its cant get one, it asks the buildfarm to 
create one with desired paramters. Some of these parameters (i.e. CPU type,
bindings to other installed software, ...) are normally found out 
automatically, others (ie. codecs, ...) are chosen by the user.

As you can see, I'll try to bring all steps from the developer to the
end user into one deterministic process. For packages ported or adapted 
to this system, it would also be quite easy to do automated integrity
or constraint checks and several other tests.


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/