<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title>Choosing the right build system</title>
                       
  <meta http-equiv="content-type"
 content="text/html; charset=ISO-8859-1">
</head>
<body>
<h1>Autotools and OpenOffice.org</h1>
draft 0.1 <a href="mailto:mh@openoffice.org">mh@openoffice.org </a>09/18/2002<br>
<br>
autoconf 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:<br>
<blockquote>./configure<br>
make<br>
make install<br>
</blockquote>
is 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.<br>
<br>
<h2>Checking the prerequistes</h2>
one of the major tasks for a build system is to check the prerequites for
the build. Typical candidates are <br>
<ul>
  <li>Build tools like compiler, linker</li>
  <li>other development tools like flex, bison</li>
  <li>Software development kits like jdk (Java Development Kit) or minor kits
(external libraries and header files like neon, freetype, berkerleydb)</li>
</ul>
<h2>Creating the Configuration</h2>
After all the prerequisites have been checked and validated the configuation
can be created. In the autotools environment this happens through:<br>
<ul>
  <li>generation of config.h</li>
  <li>generation of makefiles</li>
</ul>
In the OpenOffice.org this is done through the generation of a script file
which describes environment variables to be set after source/executing this
script file. This is a big difference and has some reasons:<br>
<ul>
  <li>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).</li>
  <li>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.<br>
  </li>
  <li>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).</li>
  <li>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).</li>
  <li>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).&nbsp;</li>
  <li>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" ?</li>
  <li>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 ;) ).</li>
  <li>autotools are using <a
 href="http://www.tip.net.au/%7Emillerp/rmch/recu-make-cons-harm.html">recursive
makefiles</a>.<br>
  </li>
</ul>
<br>
<h2>Building</h2>
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:<br>
<ul>
  <li><a
 href="http://porting.openoffice.org/source/browse/tools/solenv/bin/setsolar.pl">setsolar.pl</a>
(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.</li>
  <li>dmake options:</li>
  <ul>
    <li>dmake debug=t build with debug information in the current directory</li>
    <li>dmake nopt=t builds without optimization flags</li>
    <li>dmake depend=t generates new dependencies</li>
    <li>other options like profile=t, lint=t, linkinc=t also available</li>
  </ul>
  <li><a
 href="http://porting.openoffice.org/source/browse/tools/solenv/bin/build.pl">build.pl
    </a>tool: avoid recursive makefile and have some goodies:</li>
  <ul>
    <li>build -all build all dependent modules up to current module</li>
    <li>build -from</li>
    <li>build -since</li>
    <li>build -PPn : parallel building (see also dmake -Pn)<br>
    </li>
  </ul>
</ul>
<br>
<h4>References:</h4>
autoconf: <a
 href="http://www.gnu.org/manual/autoconf/html_mono/autoconf.html">http://www.gnu.org/manual/autoconf/html_mono/autoconf.html</a><br>
automake: <a
 href="http://www.gnu.org/manual/automake/html_mono/automake.html">http://www.gnu.org/manual/automake/html_mono/automake.html<br>
</a>make: <a href="http://www.gnu.org/manual/make/html_mono/make.html">http://www.gnu.org/manual/make/html_mono/make.html</a><br>
<br>
<br>
</body>
</html>