[MPlayer-dev-eng] deterministic builds

[Dominik 'Rathann' Mierzejewski]

On Monday, 29 December 2004 at 13:45, Enrico Weigelt wrote:
> * Dominik 'Rathann' Mierzejewski <dominik at rangers.eu.org> [2003-12-29 11:25:31 +0100]:
> 
> <snip>
> > This is autodetection. I don't see what you're harping at. What RPM does
> > is something like this:
> > ...
> > ld: tell me what libraries this thing is linked against
> > put that information into package headers along with any
> > packager-specified deps
> 
> No, you misunderstood me.
> 
> I'll tell the computer: 
> okay, we have a library foo, which may be built as dll or linked statically,
> it consists of a list of c-sources and a list of c-headers. some selected
> header files are meant as public interface and have to be installed on
> devkit builds.

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.

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

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

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

> This approach makes the whole build system much clearar, which is better
> for correcting errors and reduces the possibility of errors and problems
> in the build system dramatically (having one buildsystem for almost all
> packages on a system has dramatically less code than if every package
> brings its own build system - each line of code is a possible point of
> error!)

"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. And RPM/dpkg/whatever
on top of that. That's not much to cope with IMHO.

> 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. Nobody in their right frame of mind
would apply CASE (-like) methodology to a project of several thousands
lines of code.

I still can't see the advantages of what you propose. And why we are even
discussing it here, for that matter.

-- 
MPlayer RPMs maintainer: http://greysector.rangers.eu.org/mplayer.html
"The Universe doesn't give you any points for doing things that are easy."
        -- Sheridan to Garibaldi in Babylon 5:"The Geometry of Shadows"