Autotools and OpenOffice.org
draft 0.1 mh@openoffice.org 09/18/2002autoconf is the most standard build system in the OpenSource world. It automatically configure software source code packages. These scripts can adapt the packages to many kinds of UNIX-like systems without manual user intervention. Autoconf creates a configuration script for a package from a template file that lists the operating system features that the package can use, in the form of m4 macro calls. The sequence:
./configureis well known for many Open Source software packages. Many times the question come up, why OpenOffice.org is not or only partly using this standard build system.
make
make install
Checking the prerequistes
one of the major tasks for a build system is to check the prerequites for the build. Typical candidates are- 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
After all the prerequisites have been checked and validated the configuation can be created. In the autotools environment this happens through:- 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
After configuration is done, the build of the product is coming. On a quite modern machine (1.8 GHz Linux) the build last about 6 hours. On older machines a build will last up to one day. For this reason no StarOffice or OpenOffice.org developer will build a complete Office on his own. There are centralized builds available, and a developer will only grab part of the solver and the source of the modules he is interested in. He changes some files and only the effected (object-) files have to be recreated. This speeds up development cycle at lot. To set up environment we use:- 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:
autoconf: http://www.gnu.org/manual/autoconf/html_mono/autoconf.htmlautomake: http://www.gnu.org/manual/automake/html_mono/automake.html
make: http://www.gnu.org/manual/make/html_mono/make.html