From Apache OpenOffice Wiki
< User:Dyrcona
Revision as of 21:39, 9 December 2008 by Dyrcona (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

File Organization is a large project. A fresh checkout of a recent development milestone (DEV300_m3) comprises 98,117 files in 13,307 directories that occupy about 1.8 GB of space on disk. Those 13,307 directories are themselves split among 179 modules, each module being a top-level directory. Good file organization is necessary to work effectively with such a large project.

If you work on several different projects, not just OO.o, you might like to keep your code files neatly organized and separate from your other files. To that end, I suggest creating a subdirectory, called Sources, in your home directory. In this directory, you could create a subdirectory for each of your major projects. Thus, the code for each project is neatly organized and distinct from the others.

In the case of OO.o, a further subdivision of the project directory helps to organize the various builds and other files. First, one has the main OO.o project directory, ${HOME}/Sources/, where all of the code and build files may be kept. Under this main project directory, a bin subdirectory is a useful place to keep some scripts and environment files. Side by side with this bin subdirectory sits another called prebuild. It stores the various pre-built binaries that are recommended to speed up the total OO.o build process. If you work on more than one release at a time, or if you try different milestones, then you will likely want a subdirectory name for each milestone CVS tag that you checkout. You might also want to incorporate the name of any CWS that you integrate into that build. Finally, once you begin actually making changes to the code, or if you receive any patches from another developer, you will want a directory to store these. I call this directory diff in my setup.

The structure of this layout looks something like the following:



In addition to XCode 3.0, you will want the following software.


If you are a serious f/oss programmer, then you will definitely want to install MacPorts on your development computer. It contains easy to install ports of many free software packages. All of the packages listed below are available in MacPorts and have proved indispensable to me in my programming.

It is beyond the scope of this document to tell you how to install and work with MacPorts. Those topics are already covered by their ample documentation.


Since has switched to using subversion (svn) for source code control, you will need to use svn rather than cvs to get code.

The version (1.4.4) that ships with Xcode 3.x is sufficient for doing simple checkouts. However, if you wish to switch revisions on a working copy or you have checkin access to the repository, then you will need to install a more recent version (1.5.4) from MacPorts.


The ccache program is highly recommended on the AquaBuild#ccache page. My scripts and environment files listed below assume that you have installed this package. I find it very useful when changing build options or trying out various patches. It greatly speeds up build times in those cases. You can install this from MacPorts.


The flex that comes with Leopard is not useful for building OO.o. Specifically, the SQL syntax checker in Base ends up broken and you have a very hard time working with databases. If you want a functional Base, you will need to install an alternate version of flex. I highly recommend installing whatever the latest version is in MacPorts (2.5.35 as of this writing).

If you install flex from MacPorts, you will want to make sure that /opt/local/bin is in your path before /usr/bin or you will end up using the flex that came with Leopard. You could achieve this on a temporary basis by adding export PATH=/opt/local/bin:$PATH to the file (described below).


Leopard comes with an acceptable version of gperf in /usr/bin. However, you might want to install the one from MacPorts, or it may have been installed by another package along the way.

Getting Pre-built Binaries

You can get pre-built binaries for a couple of things that OO.o relies on to speed up your build. Otherwise, you will have to build these yourself.


You should follow the instructions in the main AquaBuild#prebuilt_Mozilla_archives page if you want to get pre-built Mozilla binaries.


The unowinreg.dll is only required if you plan to build and use the OO.o SDK with Java. (My instructions and build script posted here assume that you do.) You can find the latest unowinreg.dll binary as of this writing at the tools website. (NOTE: This is a MS Windows DLL, and you cannot actually build this file on Mac OS X at this time. You do actually have the source for it in your checkout, though.)

Scripts and Environment Files

The following are useful snippets to store in files under your $HOME/Sources/ subdirectory.

This file sets up some useful environment settings before doing a build. It is best run in the subdirectory named for the CVS tag that you are building.

export CCACHE_DIR="$(pwd)/.ccache"
export CC="ccache gcc"
export CXX="ccache g++"
export TMP=/tmp

This script will setup a new build directory based on a CVS tag. It does everything to create the new directory, download the files via read-only svn, and copy pre-built binary files into the appropriate places in the build directory. You generally run this one in $HOME/Sources/



if [ "${where}" != "${HOME}/Sources/" ]; then
    cd ${HOME}/Sources/

if [ -e ${cvsTag} ]; then
    if [ -d ${cvsTag} ]; then
        echo "${cvsTag} already exists and is a directory"
        read -p "Do you wish to continue (y|n)? " readContinue
        case "${readContinue}" in
                echo "Doing update instead of checkout"
                cd "${cvsTag}"
                svn update
                exit 1
        echo "${cvsTag} is not a directory"
        exit 1;
    svn checkout svn://${cvsTag}
    cd ${cvsTag}
    # Copy the Mozilla and unowinreg.dll pre-builts to the proper place.
    cp ${HOME}/Sources/*.zip ./moz/zipped/
    cp ${HOME}/Sources/ ./external/unowinreg/

    # Link the pre-existing build script
    cd config_office/
    ln -s ../../bin/

The following is the build script that I use to configure builds. It is copied from the one provided on the AquaBuild page, but it also builds the SDK.

export BASE=`pwd|sed 's/\/config_office//'`
export OOVERSION=`echo $BASE|sed 's/^\/.*\///'`
echo Building from     : $BASE
echo OpenOffice Version: $OOVERSION
./configure \
--with-lang="en-US" \
--disable-pasf \
--disable-gtk \
--disable-build-mozilla \
--with-build-version=$OOVERSION-`date +%d-%m-%y` \
--disable-fontconfig \
--disable-headless \
--without-nas \
--with-use-shell=bash \
--with-jdk-home=/System/Library/Frameworks/JavaVM.framework/Home \
--with-stlport=no \

The Build

The following steps when executed in a Terminal window under the default bash shell will get you a build directory checked out and then start a build of Hopefully, you are a patient person as the below can take over 6 hours depending on the speed of your computer's CPU, how much RAM it has, and just what else you're doing on the computer. I often do the build just before going to bed, so it is usually ready when I wake up in the morning.

cd ~/Sources/
bin/ {CVSTAG}
source ../bin/
cd config_office/
cd ..
cd instsetoo_native
build --all -P4 --dlv_switch -link  

You will, of course, want to replace {CVSTAG} in the above example with the actual CVS tag of the milestone or snapshot that you wish to build, DEV300_m3 for example.

More advanced users might also wish to insert some steps to apply patches or to checkout code from various CWS before doing the build. Such advanced topics are best left for another discussion.

Installing/Using the Result

You will find .dmg images files with installable apps in the following two directories under your main build directory, the one named for the CVS tag that you checked out earlier. The exact names of the dmg files will vary as they will include the date of the build, but there should be only 1 dmg file per directory unless you've done multiple builds.


You can install the from the dmg to almost anywhere on your system and it should work just fine. I usually place it in my Applications folder. You can also drag the icon to the dock, and that works. If you have a previous installation of in your Applications folder, I highly recommend dragging it to the Trash before installing the new OO.o in the Applicaitons folder. If you wish to have multiple versions of OO.o installed for testing or whatever reason, then it is best to install the OO.o that you just built some place other than the Applications folder.

Inside the OpenOffice_SDK dmg file is a folder that you can drag to wherever you want to put it on your disk. (I'd suggest somewhere under $HOME/Sources/.) It is beyond the scope this document to tell you how to use the SDK, but there is a whole site dedicated to that very thing.

Hacking OO.o

If, like me, you use GNU Emacs to edit your source code files, then you might want to add the following line to your .emacs file so that .mm files will be treated as Objective-C++ source code and not nroff code:

(add-to-list 'auto-mode-alist '("\\.mm" . objc-mode))

Once I've had some more time for code changes of my own, I'll add a subpage about hacking OO.o on Mac OS X, managing patches, etc. I have an idea for an example hack, too.

Personal tools