Hi .. On Wed, Mar 06, 2002 at 01:44:15PM +0100, mh@openoffice.org wrote: >> 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. hmmm .. but Linux is defined as well isn't it? I remember, that I thought includes-lines, which I don't ever seen before and I think, all system includes are at the same place on linux, for example ... >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: right. >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). But with autotools, you are able to get one binary for the most of mashines. >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). I will say .. the differences of the buildsystem and autotools are not so much .. they are similar except, the openoffice has one, own enviroment and autotools are bind to the OS and Enviroment. >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 ;). This will be the idal way of developing :))) >> 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 hope, we can get it better! Regards Jan -- One time, you all will be emulated by linux! ---- Jan- Hendrik Palic Url:"http://www.billgotchy.de"; E-Mail: "palic@billgotchy.de" -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d- s: a-- C++ UL++ P+++ L+++ E W++ N+ o+ K- w--- O- M- V- PS++ PE Y+ PGP++ t--- 5- X+++ R-- tv- b++ DI-- D+++ G+++ e+++ h+ r++ z+ ------END GEEK CODE BLOCK------
Attachment:
pgpZ9u3Bq2oGy.pgp
Description: PGP signature