[MPlayer-dev-eng] deterministic builds

[D Richard Felker III]

On Sun, Dec 21, 2003 at 06:52:33PM +0100, Enrico Weigelt wrote:
> * Attila Kinali <attila at kinali.ch> [2003-12-20 22:18:34 +0100]:
> 
> <snip>
> > > Okay, its syntactic sugar. But it would be better to have an kind
> > > of "standard" for as many projects as possible.
> > 
> > Not really, people tent to think that their solution is the best.
> > Beside, a standard always restricts people and sometimes these
> > restrictions are too much a burden.
> 
> These "restrictions" are not really worth talking about, if its only
> the question of several names for the same thing. Well, those stuff 
> could/should be handled by machines. (ie. --sysconfdir vs. --confdir)
> But if we're at the point, that several things are really equivalent 
> (as these both options), why evryone goes another way instead of using
> the same name for the same thing and prevent much confusion ?

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

> 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
process so you can't see what's going to get installed where (ever try
"make -n install" with an automake project?), and uses all sorts of
microsoft-esque techniques to hide what's going on from the user.

(This happens to make it exceptionally great for hiding trojans in the
build system, too.)

> <snip>
> > > > > * many feature options are only available as --enable-xxx or --disable-xxx
> > > > >   (the default setting seems not to be supported as explicit parameter)
> > > > 
> > > > It's the default, why do you need an explicit parameter to specify it in
> > > > the first place?  
> > > Can I rely that this standard always remains the same ?
> > 
> > Not really, the default for 99% of the options is autodetect and
> > use if available (only a few options which are highly experimental
> > are disabled by default). 
> 
> Well, that's the problem!
> 
> 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. 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.

But for mplayer, I don't see why you don't just --disable the libs you
definitely don't want linked...

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

Rich