[MPlayer-dev-eng] deterministic builds

[Enrico Weigelt]

* D Richard Felker III <dalias at aerifal.cx> [2003-12-21 13:33:13 -0500]:

<snip>
> Forgive me for being upfront about this, but it doesn't sound like you
> have 1% of the experience needed to make a distribution. Why not spend
> a while learning about this stuff first and just build your own
> homebrew system for your own use, then come back and make a distro a
> few years down the line...

Well, I'm building custom distributions for dozens of machines (very 
heterogenous environments) for years ...
I'm really sure I now what I'm talking about.

> > Although I really dont like automake, it brings us some kind of "standard"
> > while not limiting too much.
> 
> Uhg... Automake is the bane of compile-from-source systems! It makes
> software take twice as long to build, completely obfuscates the
Yes. You're right. I also dont like it.
I just wanted to say that many projects using this bullshit automake is still
better then evryone is doing completely different, since it brings just an
minimal point of "standard". Of course I evrything but happy with this.

I'm the last person who encourages people to use automake, but it would be 
nice to reduce the amount of different configure / build syntaxes.
(yes, its really just syntactic sugar - but it eats up time of the maintainers)

If we get enough manpower (I've tried it alone, but one person cannot cope with
such huge projects), we really should build a completely different build system, 
which has the right modeling of project's structure to do evrything alone and 
let the developers the flexibility he needs (but not more).

<snip>
> > If you want to build greater distributions w/o having to do evrything
> > by hand, its really necessary, that you can rely the computer does exactly
> > what you want. I get a headache when build systems tend to use dozens
> > of libs found on my system without asking me. This is okay, if you just
> > install one package after another, but you get into big trouble when 
> > you're using an package manager which doesn get informed about those
> > dependencies.
> 
> Then your package manager is broken. 

What kind of package manager you're talking about ? If you think about
rpm oder apt - they're available at this stage - evryting they can is 
installing and tracking files and checking dependency information
(which must be supplied by the developer)

This still needs much hand-work by package maintainers. But I want to 
create a build system, which is able to do it alone. (This is possible!)


> You have several solutions available. One way is to ldd the binaries that get 
> built and track dependencies that way. Another is to build in some sort of
> chroot/sandbox environment where you hide extra libs.
This is just an ugly workaround. Better to let the project description tell
you evryting you need (or let the builder compute it based on the package
description)

But this requires a completely different approach for build systems - not 
describing the build process (like make & friends does), but instead the 
software structure.


<snip>
> But for mplayer, I don't see why you don't just --disable the libs you
> definitely don't want linked...
It comes from the wrong side. I want to enable what i _want_.
The build system may tell me, whats available, if I ask it.

<snip>
> > > > Is this output machine readable (parsable with acceptable work) ?
> > > > Can I rely on the consistence of the format over newer versions ?
> > > 
> > > config.h and config.mak are both machine readable, infact they have
> > > to be read by machines, by the c compiler resp. make.
> > Yes, of course.
> > But can I use it without knowing too much internals of the build system ?
> > Here we're at the point where a standard (also the sucking automake)
> > would be nice.
> 
> You're not going to make yourself any friends on this list by
> continuing to praise automake.

Where am I praising automake ?! Did you really read (and understand) 
my postings properly ?!

Evrything I want is some _relyable_ point to get all information needed
for packaging w/o doing evrything by hand.



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/