Autotools and OpenOffice.org

./configure
make
make install

Checking the prerequistes

• Build tools like compiler, linker
• other development tools like flex, bison
• Software development kits like jdk (Java Development Kit) or minor kits (external libraries and header files like neon, freetype, berkerleydb)

Creating the Configuration

• generation of config.h
• generation of makefiles

• OpenOffice.org is used to work on a firm feature set per platform, that means a Linux build should be on every Linux distribution the same, independent from preinstalled development kits (see above). We see it as critical to have binary distrubtion of a product available, which have a different feature set provided to the user of the product. This is feasable if you are try to adopt some source to your local configuration of your local machine, but it's not feasable for redistribution in binary form. So we decided not to use a dynamic created config.h (long before StarOffice went OpenSource). Also there are not many different Unix flavours available and support at the time the autotools were introduced. Also almost of the platform dependencies should be coved in one Layer (SAL, System Abstraction Layer), most of the other stuff (exception are vcl, bridges) should be system independent and shouldn't contain any "HAVE_bla" or "#ifdef platform" conditions (in theory).
• because OpenOffice.org/StarOffice is an end user product, we support only well defined versions of compiler. We should not use the compiler which we have randomly found on our machine to produce a redistribution of our product. Almost every compiler version has different optimization bugs in it, so that the risk of program failures is simply to high if using a unkown/untested version of a compiler. So the usual testing of a compiler within configure, if it is possible to create object files and so on is simply superflous and too time consuming. This is also valid for other tools like bison, flex etc. Of course a user should be able to choose a compiler of his own.
  
• The creation of makefiles and config.h is also critical because everything has to be recreated due to the dependency of almost every artifact to these files (for this reason compiler cache has been created).
• The configuration for debug, product, profiles, shared, static build method is also hardcoded into the generated makefiles, so a mixture a debug/nondebug, optimized/non optimized object files is not possible but necessary for a product with the size of OpenOffice.org (e.g. it's on almost all machines not possible to run a full debug build in a debugger, because several Gigabytes of RAM are needed).
• autotools implementation relies on complex macro programming (m4) this is just a reason more not to use it. The feature set that is needed for a OpenOffice.org build is/was not available in autotools and there were no resource to reimplement these in autotools (many new rules for resource, idl compiler, own resource format, many other OpenOffice.org specific tagets which are not available in the current automake implementation). 
• current makefile implementions are written for dmake, there were no resources to rewrite it in GNUmake. Are there any advantages in opposite to dmake beside the argument that GNUmake is the "standard make" ?
• configure is too time consuming for just setting up an build environment (e.g. configure for binutils 2.13 lasts several minutes on a 2-3 year old machine). OpenOffice.org developers work on several codelines in parallel, so a long configure time is not acceptable (imagine the worst case: generation of over 1000 makefiles or one gigantic makefile ;) ).
• autotools are using recursive makefiles.
  

Building

• setsolar.pl (alias setsolar.pl 'perl ooo/solenv/bin/setsolar.pl -envroot -sourceroot -file ~/.solar.env.$$.tmp !*; source ~/.solar.env.$$.tmp; rm -f ~/.solar.env.$$.tmp' leeds to commands like "setsolar -pro -srx643 unxsols3" and set solver paths to globally shared copy of solver. An extra switch -ca (copy all) create a local enviroment, that means the solver gets copied on your local hard disk.
• dmake options:
• dmake debug=t build with debug information in the current directory
• dmake nopt=t builds without optimization flags
• dmake depend=t generates new dependencies
• other options like profile=t, lint=t, linkinc=t also available
• build.pl tool: avoid recursive makefile and have some goodies:
• build -all build all dependent modules up to current module
• build -from
• build -since
• build -PPn : parallel building (see also dmake -Pn)
  

References: