Re: Building systems

[mh@openoffice.org]

On Wed, Mar 06, 2002 at 11:34:19AM +0100, Bernhard R. Link wrote:
> 
> Before we start a flamewar here about building scripts, I want to
> say that I'm not of the opinion that the upstream OO.o scripts
> are totally flawed. 
> 
> In comparision with the state of the other OO.o code is it quite good
> and useable, it just has goals total away from what building packages
> for Debian has. 
> 
> Their system does quite an good job to comapile an huge pice of code,
> build around the compiler errors of dozens of architectures trying 
> not to interfer with strange environments to get an office suite
> in one piece and doing on their own.

I cant say it better.
> 
> Theese goals make an smooth and nice build mostly impossible. If
> the Right Way[tm] won't work on some hpux OS and windows, it has to
> work around. As it has to cope with systems were resonable things fail,
> it tend to hide important errors. 

Yes, if working in a company where you a working on a standardized
environment things are easier. We have well defined developer and build
machines, tools and compilers are on fixed network volumes.
So in our build environment we are sure that everybody uses a well defined
tools in a certain version on the same location. This is essential
for building reproceable products( Just imagine you compile some object files
with 2.95.2 and some other 2.95.3 Compiler; it will work in most case,
but if you get a problem in this scenario, then you have a serious 
problem to reproduce this. And this is a main difference to autotools
and other build systems:
autotools are trying to get out the best (n given versions of tools)
of the given Enviroment and will produce a good binary for the local 
machine or an (1) distribution like debian (n -> 1 direction).
In our "commercial" build environment we fight with the problem, that the
generated binaries have to run on as many platforms as possible, so we
decided to go the other way: use (1) a well defined environment to support
many (m) platforms ( 1 -> m direction).

Now we have to find out how we can find a way to the ( n -> m ) approach,
this may be just a matter of complexity ;).

> 
> And it uses the OO.o codebase, which is in my eyes still an Windows 
> program, which is (ad be for the next at least 5 years) still be in 
> the process of beeing ported to unix-like systems.
> 
most of the dependencies of the build tools to OOo codebase has been
eliminate in 641, so this argument is not that strong.

I think you're right that OOo UI is to Windows centric (most of OOo/SO 
Users are using Windows), but I don't see that OOo buildenvironment 
is a windows like environment. But yes, it is not like the typical
Unix (autotools) environment.

> Hochachtungsvoll,
> 	Bernhard R. Link
> -- 
> The man who trades freedom for security does not deserve 
> nor will he ever receive either. (Benjamin Franklin)
Martin Hollmichel