Stable branch, specialized branches

A stable branch is base for a release build of the OpenOffice product. This is where bug fix tracking takes place. The policy on these branches are to fix functional errors only.

The good side is that any patches are more thoroughly vetted before going into a stable release. Therefore you have fewer mystery bugs. The downside is that there are fewer features and some bug fixes are already in the developer release.

Modules

The source code directory contains a lot of folders, each one representing a module. A module provides an application, a function, or simply just a collection of classes. A module is the smallest unit of the office suite that can be built.

Modules correspond to the directories under the top-level directory of the source tree. For example, the Writer project includes the sw, starmath, res modules, etc.

There are many dependencies between the modules, and the modules must build in a particular order. Module prerequisites are described in first line of the file prj/build.lst for example:

Build Styles

Full Builds

Developers typically perform a full build of OpenOffice in order to build their modules. A full build also recompiles all of the source code. It can take up to a few hours to perform a full build of OpenOffice.org even on modern workstations. However using tools such as distcc and ccache can have dramatic time improvements.

Partial Compatible/Incompatible Builds

To avoid the need of a time-expensive complete re-build each time a change in the code is introduced, the developers are asked to introduce only binary compatible changes in the code unless it is agreed with the project owner. This means that the changes made are of such a nature that no recompilation of further dependent modules become necessary (inserting a new, non-virtual method in a C++ class would be an example of such a binary compatible change). The office suite will then be re-compiled as a so-called respin build before the next 'master' s declared. A respin build obeys only weak dependencies, i.e. dependencies within a module. Using weak dependencies allows you to, for example, to modify a base library header file without needing to perform a full build. Since a respin build relies on binary compatible changes, modules can be build in parallel, and the build takes much less time (a few hours) in contrast to a full build.

By contrast, binary incompatible changes require a full build. For reasons of efficiency, this is allowed only with the approval of the project owner.

Snapshots Builds

OpenOffice employs a buildbot for snapshot builds. However, the output of these builds are for developer use/information only. They are not advertised for public consumption -- beta testing.
We follow Apache rules for the announcement of releases.

Source and Output Trees

OpenOffice.org developers work in parallel on all platforms. The source code for all platforms is identical, with the exception of the code for the interface to the operating system and window managers. This allows you to build for the different platforms simultaneously from a single source tree, i.e. the directory structure that stores all of the source code for the office suite.

The solenv tree contains the environment tools that the build process uses, for all supported platforms. Formerly it also included the platform-specific build tools. Now these build tools are created with a bootstrap script created with the configure script.

When building multiple modules, these steps are taken for each module:

The build process generates files from the source tree into the output tree of the module (this is a directory named after the platform, e.g. unxlngi6.pro for 32-bit Linux)

After the module has been build, the results are copied to the solver, a directory sitting next to the top-level modules in the SRC_ROOT. This step is called deliver (there is a tool with the same name). Modules cannot link/compile against the output directory of other modules, they only compile/link against objects in the solver.

When you run bootstrap, the solver directory is created. Initially, the solver directory is empty. The build process populates this directory. The build process delivers all binary files, shared libraries, and dynamic link libraries to solver.

When you want to build a specific project, you only need the sources of the relevant SVN modules and the output tree solver. You do not need the entire source tree, though typically a developer will check out one of the branches and build it from scratch.

For more information on the solenv and solver trees, see the Tools project.