Building NeoOffice

OpenOffice.org has recently reached a crucial milestone, the beta build for Darwin. The project has now entered the next major phase, migration to a Quartz implementation and Aquafication. This undertaking will probably take a significant amount of time and a large expenditure of resources. As such, it makes sense to take some time to explore some of the potential paths for execution so a year from now we don't find we made the wrong choice of strategies.

OpenOffice is an exploration of the strategy of executing an OS X native port on top of the existing Cocoa+QuickDraw VCL implementation. It is a complete hack job, is unstable, rails the processor, leaks memory, has drawing glithces, is mostly unmaintainable code, and does not integrate well with the potentially changing VCL of OpenOffice.org in future versions. It does, however, illustrate that the existing infrastructure can be pushed to create results that are fairly desirable.

Through this prototyping process we discovered several bugs and issues that make this approach undesirable:

Requirements

Getting OpenOffice and External Sources

Once you have the requirements for building OpenOffice met by performing a small contract job or assuming a decent amount of credit card debt for a new hard drive, it's time to get the OpenOffice sources and other external sources. If you've built OpenOffice from previous sources and have applied other patches, you will need to start either with a source tarball, or with the CVS sources.

After you get the CVS distribution you will need to take some steps to set up a build properly. OpenOffice is derived from OO638C_MacOSX and requires gcc2 to build. The first step is to therefore configure your build box to use gcc2:

Next we build the STLPort code. This is a compiler-agnostic STL implementation used with the OOo sources. To obtain the source:

After getting stlport built you will need to get the dlcompat library for linking convienence. This is needed to properly build the patches for the Darwin port.

Important Note: If you've installed dlcompat from a different source location, you must be sure that it's properly linked to /usr/local/lib or else the OS X build will fail.

Building OpenOffice

Assembling the Setup Executable

After all of OpenOffice is built, the next step is to construct the appropriate directory so we can run setup and install the binaries we've just built. From what I know, it's not possible to run them straight out of the build directory.

Installing OpenOffice Binaries

Now setup has all the necessary libraries and files it needs to run. The setup process will exhibit several failures, but does properly register the recognized components if it's run correctly.

Once setup has exited, we need to move some files manually. Setup hasn't been fixed to work without a hitch on OS X:

What More Needs to be Done?

This patch is just a first step towards getting a fully functional build. There are a number of things which still need to be addressed before we can claim absolute victory.

Integration with Mainline Sources: This patch is incredibly unstable in its current incarnatin, but we should begin migrating it to OO641/OOO_STABLE_1 sources. This patch contains several places where code may need to be ifdefed MACOSX out or commented out in the build files. Currently the patches may break other ports. If someone is working on two different ports, this may be the ideal project to start off with after the first build is done :)
Integration and Evolution: We need to get this patch in a state safe for other ports, move to OO641 in preparation for OO1_STABLE, finish up all of the missing parts, etc. etc. etc. In other words, this patch represents the completion of the OO638C build step in our project roadmap and it's time to take up the ball and start heading for the endzone.

Building Test Programs

OpenOffice contains a number of test programs that can be used to exercise various parts of OpenOffice. These test programs are very useful for trying to find problems in the source code that may cause errors while running OpenOffice. The vcl test programs are incredibly useful for debugging problems when building Aqua graphics.

Once you have built the modules in the Abstraction and Infrastructure Layers, you are now ready to build the test programs for these layers. To build the test programs, execute the following commands:

> cd $SRC_ROOT/svtools/workben ; dmake ; deliver
> cd $SRC_ROOT/stoc/test/testsmgr_cpnt ; dmake ; deliver
> cd $SRC_ROOT/stoc/test ; dmake ; deliver
> cd $SRC_ROOT/bridges/test/java_uno ; dmake ; deliver

The commands listed above will build the following test programs. As these test programs are meant to provide a means for developers to debug the modules that are in the Abstraction and Infrastructure Layers, developers are highly encouraged to run these test programs on a platform such as Windows, Linux, or Solaris to determine what additional porting development effort is needed:

Graphic System Layer Project test program - This test program contains code that exercises OpenOffice's VCL library. To run this test program, execute the following command:
```
> cd $SRC_ROOT/svtools/unxmacxp.pro/bin
$SRC_ROOT/svtools/unxmacxp.pro/bin> svdem
```

UNO Development Kit Project test programs - These test programs contain code that exercises OpenOffice's UNO libraries. To run these test programs, execute any of the following commands:

> cd $SRC_ROOT/stoc/unxmacxp.pro/bin
$SRC_ROOT/stoc/unxmacxp.pro/bin> testconv
$SRC_ROOT/stoc/unxmacxp.pro/bin> testcorefl
$SRC_ROOT/stoc/unxmacxp.pro/bin> testintrosp
$SRC_ROOT/stoc/unxmacxp.pro/bin> testinvocation
$SRC_ROOT/stoc/unxmacxp.pro/bin> testloader
$SRC_ROOT/stoc/unxmacxp.pro/bin> testproxyfac
$SRC_ROOT/stoc/unxmacxp.pro/bin> testregistry
$SRC_ROOT/stoc/unxmacxp.pro/bin> testsmgr
> cd $SRC_ROOT/bridges/unxmacxp.pro/bin
$SRC_ROOT/bridges/unxmacxp.pro/bin> test ../misc/interfaces.rdb

Building Individual Projects

OpenOffice is organized in several projects. For example, the Word Processing Project. These in turn consist of several modules, organised in separate directories. The source contains approximately 90 modules.

You can build any project or module individually. Building modules individually should not be misunderstood as reducing OpenOffice to a special application, say, for instance, the spreadsheet application. The program will always consist in the entire office suite: text processor, spreadsheet, drawing application etc. Building individual modules comes in handy if you want to develop on a certain module or port a module that has not yet been ported for this plaform. Most modules will depend on other modules to be already built. In other words, all modules must build in a particular order. Accordingly, you must build all of the modules in the Abstraction and Infrastructure Layers before you trying building any projects or modules individually.

For more information on modules and on the sequence that they build in, and on the dependencies, see tools.openoffice.org/modules.html.

To build a project, you build each of its modules individually in their directory with the build tool.

> cd $SRC_ROOT/(module-name)
> $SRC_ROOT/(module-name)> build
> $SRC_ROOT/(module-name)> deliver

Files called makefile.rc in each directory with further subdirectories iterate through all directories of the module and executes dmake in each of them (just like the top-level makefile.rc does when building the entire office suite). The last or second to last directory is usually module-name/util which is responsible for linking one or more shared libraries.

Building a Project with Debug Information

To rebuild a complete project with debug information, remove all object files by removing the unxmacxp.pro directory. Then run dmake with the debug option set to true:

> cd $SRC_ROOT/(module-name)
> $SRC_ROOT/(module-name)> rm -Rf unxmacxp.pro
> $SRC_ROOT/(module-name)> build debug=true
> $SRC_ROOT/(module-name)> deliver

Re-running Setup to Reinstall OpenOffice

After you've built a module with debug symbols, chances are you'll want to reinstall OpenOffice in order to run OpenOffice with debugging information. The first thing you'll need to do is remove setup, the install directory, and some config files. If you installed to the paths suggested above, this can be accomplished with the following set of commands:

rm -rf /ooo-install
rm -rf /ooo-setup
rm ~/.sversionrc

After getting rid of the setup directory, install directory, and the .sversionrc file we need to recreate the setup executable. First we need to reconstruct the zip files in instsetoo:

cd /openoffice
source MacosxEnv.Set
cd instsetoo
build

Now you can resume the instructions in Assembling the Setup Executable and complete with the installation. You can then get debug symbols by gdb sh and then issuing r /path/to/soffice

Deleting a Build Directory

When you're deleting a directory containing a checkout of the OpenOffice sources, you should rm -rf it from a terminal. If you are trying to delete your checkout using the Finder, you'll run into a fun little feature of the OS X Finder that doesn't allow you to delete folders named desktop. OpenOffice has a folder with this name in it, and this folder will need to be deleted from the terminal.

Moving or Renaming a Build Directory

The build process for OpenOffice utilizes hardcoded paths to STLPort and other components of the source tree. If you rename your OpenOffice build directory or if you move it to a new location, you should delete all binaries and start from scratch by runnint config_office/configure again. To erase all your object files:

cd $SRCROOT
find . -name unxmacxp.pro -print0 | xargs -n 1 -0 rm -rf

If you do not perform this step, you will most likely be unable to build or link out of your build directory any longer.

Installing and Building the OpenOffice Prototype

Contents

Introduction