Starting development for OpenOffice.org is said to be hard. It's an application with in the order of 10⁷ lines of code, a huge number of third party dependencies and a multi-platform build system. The code base has quite a history and contains decade old stuff right next to brand new state-of-the-art code. Some starting difficulties for new developers are just to be expected.

Most of the difficulties have their origin in the complexity of the code. The OpenOffice.org developers can modularize and document the code base and this will lower the entry barrier for new developers. In fact they are doing this for years. But no amount of work will make the OpenOffice.org code base easy and intuitively understandable for new developers. It's just not reasonable to expect this.

But there other reasons why the entry barrier for starting development on OpenOffice.org is high, and we can do something about them. Kai Backman has pointed out that the long OpenOffice.org build time is also a deterrent for potential new developers. And he went a long way to prove that there is much improvement possible especially on the Windows platform. He was right and so in 2006 much work went into shortening the build time. Some of the changes were:

1. The dependency generator now parses all source and header files only once per directory.
2. Important improvements for our make utility dmake.
3. Removing old cruft from the makefile system, vastly reducing the number of shell outs which are known to be expensive on Windows.
4. Introduction of a pre-compiled header system

Many of these changes are already integrated into the SRC680 main code line, some will follow soon. All the changes together have the potential to reduce the Windows build time to about 1/3rd for a single language build compared to what we used to have at the beginning of 2006. Many thanks to Hans-Joachim Lankenau (ause, hjs), Volker Quetschke (vq), Kai Backmann (kaib) and Martin Kretschmer for this work.

Other platforms with more effective files systems, shells, tools or compilers do not profit as much as the Windows platform, but build times are improved as well. And there is another way to improve build times which works on any platform: remove old cruft from the code base.

The module binfilter is prone for such janitor work and several child workspaces have been dedicated to reducing the amount of unnecessarily compiled  code lines. Here are some statistics for 2006:

	SRC680 m177	hr38
Disk usage (source only)	148 MBytes	75 MBytes
Files	6896	4998
Lines	3.53 million	1.71 million
Compiled files (wntmsci10)	2253	1827
Comp. time (wntmsci10, f. local)	3:58:30	2:35:59

Two child workspaces are still in the queue: bfshrink01 by Caolan McNamara which removes an incredible 900+ unused  methods from binfilter and hr41 which removes another 700+ files. Together they will bring binfilter (the largest code module in OOo) to a somewhat better manageable size.

tags: