[MPlayer-dev-eng] deterministic builds

[Attila Kinali]

On Sat, 20 Dec 2003 00:12:34 +0100
Enrico Weigelt <weigelt at metux.de> wrote:

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

Ugh... you know what you are doing ?
if you treat preX as 1.0.0.X then you actualy make 1.0 (the release)
an earlier release than any pre version.

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

Dunno... but it sounds quite complicated to use.




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

Oh.. good luck then. The work which you want to do requires >20 different
mplayer packages, maybe even more than 100. I once tried to write a build
script for debian packages and grouped the options one was most likely to
choose together and ended up with iirc 10 different packages, not taking
into account the various CPU dependent packages (which multiplies the
number of packages by 10+ only for x86) and also leaving out all special
libs one would hardly use.


			Attila Kinali

-- 
egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger
			-- reeler in +kaosu