[MPlayer-dev-eng] deterministic builds

[Enrico Weigelt]

* Dominik 'Rathann' Mierzejewski <dominik at rangers.eu.org> [2003-12-29 15:35:05 +0100]:

<snip>
> Why should I care about every single source file? That's the author's
> problem, not the packager's. I (as a packager) should only need to know
> what development packages are required to build a given package and what
> build options are there.

Still, you did not really understand what I want.
The packager as such then obsolete. It is all done by the machine with
a small list of enabled features. All is done by machine, from compiling
to packaging and installing 'til removing.

<snip>
> > Now the computer can build several things out of this (as they're needed):
> >     -> dynamic library (for several platforms and architectures)
> >     -> static libraries (several formats and architectures)
> >     -> include file package
> >     -> detailed descriptors for all these sub-packages.
> 
> This is(can be) done with RPM. You just build both dynamic and static library
> and split it into subpackages. You can also package the headers separately.
> And you can build the same package for several platforms.
No, rpm itself does not have enough information for this. You must supply
build scripts, which are called from rpm - so in fact these features of 
rpm you're talking about are just a frontend to the developer/packager-
supplied scripts.

<snip>
> > Of course we have a database (maybe plain textfiles) on a global point of
> > the systems which tell evrybody, which packages/modules are installed
> > in which version and where they reside.
> 
> This is done in RPM.
Also wrong. rpm is i.e. not able to track installed _variants_, nor is it
able to have multiple concurrent variants/builds on one systems - you have
to put them into different packages to make it work.

> > MVC also can be handled out of this information. You can simply tell the
> > build system to install another version (or variant) of a library somewhere
> > else and tell some other packages to use this variant (i.e. not to use
> > glib at default, instead glib at specialneeds)
> 
> This can be done with RPM.
No, rpm does not know how to build the things for several locations
and put the right ones together. 


If rpm could do all these things, please tell me, why do we need make,
automake and all the other build systems out there ?!

<snip>
> "every package brings its own build system"? I'm not sure what you mean
> here... I've seen only a couple of build systems. Plain Makefile,
> autoconf/automake, xmkmf or some custom configure. 
Well, mplayer also has its own buildsystem - which is in fact yet another
makefile generator. Such makefile generators (one of the ugliest ones is 
automake) tend to produce unreadable and undebuggable code. Especially 
automake is really a punishment - it does what it likes to do and doesnt
give the user _real_ control.

> And RPM/dpkg/whatever
> on top of that. That's not much to cope with IMHO.

rpm is not a build system. 
It is a package manager, which can install/uninstall and track fixed
packages, check some dependencies, etc. But it is not able to build
software! Therefore it may execute developer supplied scripts, but it 
still acts as a wrapper and it cant really see, whats going on inside.

> > Also such a modeling could be used for a very wide range of automatic
> > systems (buildfarm, quality checks, ...), and also for IDEs.
> > Some IDEs already go small steps in this direction and provide an own
> > project description format, but this doesnt go far enough.
> 
> This may be useful for big software projects, but remember that OSS
> consists mostly of small projects. 
Ah ? 
So you consider mplayer as 'small' ? 
And what's about apache or the linux kernel ? 

> Nobody in their right frame of mind would apply CASE (-like) methodology 
> to a project of several thousands lines of code.
I dont talk about case tools. My build system has absolutely nothing todo
with case tools. Sorry, but it sounds like you're just flaming because
you dont really see the point.


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/