[MPlayer-dev-eng] deterministic builds

[Enrico Weigelt]

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

Although I really dont like automake, it brings us some kind of "standard"
while not limiting too much.

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

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

> And yes, those formats wont change. But defines or variables might
> be added or disapear as new options are added or obsolete ones removed.
> Ie you need to keep track of the changes of the ./configure script.
Thats the problem: the manual work is still to much.
If we had an good modeling of software structure (not dozens of rulesets),
we write it down only once and let the machines do evrything.


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/