10/26/02 (corrected lib symlink versions)
OpenOffice.org has recently completed the beta release of an X11 version of OpenOffice.org 1.0, and now it is time to begin working on the native graphics version. The Quartz build on 1.0 is a first step in that direction, allowing a compile to be successful. This is but the first hurdle in our long road, but key for continuing onwards.
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.
To download the CVS distribution:
After you get the CVS distribution you will need to take some steps to set up a build properly. OpenOffice currently 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:
The next set of sources you will need is an opensource polygon clipper library gpc which isn't included with the distribution. The steps below download the appropriate library and extract its contents into /openoffice/external/gpc. The instructions below assume that you have configured Internet Explorer or your other default browser to download directly to your desktop.
At this point, we'll have a full OOo source distribution from the CVS repository with the required external sources. It's time to apply the patches! You can find all the patches you need to apply in the Quartz PORTS column of the build status. They will all need to be applied individually according to the instructions in the relevant bug filing. Alternatively you can try downloading and applying the single mega patch [dashboardbuddha.com] (cd /openoffice-aqua; patch -p0 < /path/to/megapatch), but this method is not supported on the OpenOffice.org mailing lists and the mega patch is not continually maintained as new module patches come in. The official method is to apply patches individually and keep up to date on the dev@porting mailing list!patch -p0 < /path/to/downloaded/
Now that we've got it all patched up, it's time to execute the build!
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.
[bootstrap] UNO_TYPES=applicat.rdb UNO_SERVICES=setup_services.rdb
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.
A 1.0 build is just that, a build. This build still utilizes the QuickDraw based VCL approach which will need to be replaced with a more robust thread-safe approach. It's time to get to the drawing boards and stop fiddling with things that don't compile...ah, I lived to see the day!
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 ; deliverThe 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:
> cd $SRC_ROOT/svtools/unxmacxp.pro/bin $SRC_ROOT/svtools/unxmacxp.pro/bin> svdem
> 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
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
> cd $SRC_ROOT/(module-name) > $SRC_ROOT/(module-name)> build > $SRC_ROOT/(module-name)> deliverFiles called
makefile.rcin each directory with further subdirectories iterate through all directories of the module and executes
dmakein each of them (just like the top-level
makefile.rcdoes when building the entire office suite). The last or second to last directory is usually module-name
/utilwhich is responsible for linking one or more shared libraries.
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
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:
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:
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
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.
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:
If you do not perform this step, you will most likely be unable to build or link out of your build directory any longer.