Since we dramatically simplified the build process, we didn't need all this cruft; but we thought we'd keep it around.
There are at least 3 important streams of development in the OO.o world, see here for a map.
The active development branch (currently HEAD) is the most buildable tree, however the OOO_STABLE_1 branch has the most stable code. Thus there we have a quandary. This document deals only with HEAD, but section 11 has some hints on building OOO_STABLE_1.
For a complete list of tags and their current status see the Build tags page.
The CVS root is structured differently from other projects. There is an OpenOffice CVS alias that checks out a whole bunch of modules. These get checked out into the current directory, and to perform a CVS update it is necessary to change into each directory and do "cvs update" manually, or you can set $CVSROOT beforehand.
Thus you should create a directory and then checkout inside it:
mkdir HEAD cd HEAD export CVSROOT=:pserver:anoncvs@anoncvs.services.openoffice.org:/cvs cvs login You can just press Enter when it prompts you for the password cvs -z3 checkout OpenOffice
Note: The checkout size is ~250Mb these days, (for reasons unknown this has increased sharply recently).
Note: The repository in the openoffice.org CVS machine lives in a "/cvs" directory. CVS has a misfeature whereby it will prevent you from checking out stuff into a directory with the same prefix as the one the CVS repository uses. So if you try to do this:
cd /cvs mkdir HEAD cd HEAD export CVSROOT=:pserver:anoncvs@anoncvs.services.openoffice.org:/cvs cvs login You can just press Enter when it prompts you for the password cvs -z3 checkout OpenOffice
It will not work. You should check out under /opt/OpenOffice/HEAD or something like that, or alternatively create a /cvsoo directory instead of your "normal" /cvs one.
Your base HEAD directory does not have a "CVS" subdirectory inside it, so you cannot just cd into it and do "cvs update". You have to set $CVSROOT beforehand.
To build OO.o you really need:
Unpack them all joyfully somewhere; and copy the gpc231/gpc.[ch] source files into into the HEAD/external/gpc directory. These do not come with the base checkout because of dubious licensing — this will be resolved shortly.
Note: for the too clever by half people among you who have noticed your distribution (eg. RedHat9) ships versions as good as this; you will get away with an older binutils; but Red Hat have done odd things to their gcc/libstdc++ combo - such that the 'product' packaging phase will not work. This can be tweaked (with some evilness) in solenv/inc/tg_compv.mk - but it's easiest for beginners to install their own gcc-3.2.2.
Screen lets you run a shell, and detach from it at will. Use it!, when X crashes, and the build keeps on running you'll thank. First you need to insert:
deflog on logflush 5 escape ``
into your ~/.screenrc. This will log to the current directory when you start screen. To detach use ` d (<backtick> d), and reattach use screen -r. The log of the build will appear as screenlog.0 in the directory you start it in.
The primary build tool is dmake. There is a good overview of how it works here. Essentially, the rules are much like normal make rules, most rules are included from solenv/inc, and the rules are informed by environment variables setup by the configure process.
Other build tools are in solenv/bin particularly build, which ensures that dependencies are built for any given sub-project, and deliver which copies built source into the solver
Make sure you have all the source, especially the Java bits, which are required by the build for all manner of XML work, and while the configure may let you get away without it — the build will not — perhaps several hours in (just as you go to bed).
You did read point 1.4 yes ? you'll also need to snarf any random patches, and apply them at this point.
By now you will have chosen a prefix; here referred to as /opt/OpenOffice, so unpack binutils there and:
./configure --prefix=/opt/OpenOffice make && make install
Unpack the Jdk into your prefix /opt/OpenOffice/jdk-1.4.N, and symlink it to 'jdk' for easy updates in future.
Ensure that /opt/OpenOffice is at the head of your path, followed by the JDK binary path, say /opt/OpenOffice/jdk/bin. Also you'll need the gcc bindir, if it's different from /opt/OpenOffice
export PATH="/opt/OpenOffice/bin:/opt/OpenOffice/jdk/bin:$PATH"; export LD_LIBRARY_PATH="/opt/OpenOffice/lib:/opt/OpenOffice/jdk/lib:$LD_LIBRARY_PATH"
It's perhaps worth creating a script to do that. NB. to execute such a thing you need to use the invocation
. scriptname # under bash or source scriptname # under broken shells
If you try and run such a script normally, it'll run in it's own shell, which will have it's environment beautifully setup, before exiting back to the calling shell.
Unpack gcc and:
./configure --prefix=/opt/OpenOffice make && make install
This should work flawlessly the first time.
While you don't need ccache, it's use will speed up re-compilation dramatically, cutting build times by more than half.
Ccache can work in two ways, first by sym-linking ccache to g++, gcc etc. and having these elsewhere in your path. And secondly by invoking 'ccache gcc' instead of plain gcc. Since HEAD currently has nasty path mangling mess it's advisable to use the latter approach. To do this:
export CC='ccache gcc' export CXX='ccache g++'
This (along with all environment setup) has to be done before configure time. If you are going to be hacking OpenOffice and going round development iterations, you should probably read 6.1 first, since re-building with different flags will invalidate the cache.
Pop into config_office/ and do:
./configure --with-gcc-home=/opt/OpenOffice
This process takes a snapshot of your environment, merges it with the necessary flags, makes several mistakes and sets up LinuxIntelEnv.Set.sh [or similar] in the base directory. It's worth a read, particularly to check the PATH, LD_LIBRARY_PATH if things go wrong.
In places in this document, we use the target specific string 'unxlngi4.pro'. On other architectures this will be different, inspect the value of $INPATH in FooPlatform.Set.sh in your base dir.
Recent versions of OO.o allow you to build with an sh derived shell: bash, dash, ksh, zsh etc. ( which is excellent ), just:
source LinuxIntelEnv.Set.sh ./bootstrap
Alternatively you can let the pain start here; switch to your base directory and run tcsh (an improved csh). Import the environment, then run the bootstrap process to build the build tools. This habitually fails, and needs re-running - don't be daunted:
tcsh # abandon all hope of sane tab completion, redirection etc. source LinuxIntelEnv.Set # NB. no .sh ./bootstrap # watch it die sometimes for no really good reason ./bootstrap # repeat until it succeeds
Now you're ready to make everything; ultimately, unless you have a solver you get to build everything first time, so just type dmake — you did read 2.1 first didn't you?
Unless you're building on RH 6.2 - you will need to hack this first. Then, make a cup of tea, sleep, wake up — and it's built.
A marginal improvement in performance can be had by building several non-dependant toplevel modules in parallel — this is much safer than trying to dispatch multiple compiles simultaneously, and uses the 'build' tool's dependency mechanism. Try build -PP.
Commonly, depending on gcc version the connectivity/mozab project will not build. Disable this by removing 2 lines in connectivity/prj/build.lst.
Will Lachance reports: Don't checkout your source-tree to any path with "stl" (e.g.: apostle, castle, etc.) in it. OpenOffice will do a substitution called "dont_use" to any path containing that sub-string.
The result of a perfect build is a set of binaries in the solver, these however are useless for running; indeed — go no-where near them. A 2nd result of the build is that the instsetoo directory contains an install set.
Run a new terminal; ensure that you are running bash; breathe a sigh of relief. Ensure that the $HOME environment variable is set.
Go into instsetoo/unxlngi4.pro/01/normal, run the setup program. Assuming all is well, this will execute a loader shim that unzips all the f0_XYZ* files into /tmp/sv001.tmp. These files contain the setup program, which is then executed, which proceeds to unzip the remaining f_XYZ* files. Install OO.o into some sensible prefix.
Watch the installer ignore the JDK you built with, tell it the path, and watch it ignore that too. Resign yourself to no Java support. Or hack setup2/source/custom/jvmsetup/unx somehow to fix it.
The installer will refuse to re-install if you have already installed OO.o, even if (eg.) you delete the old version. To remedy this attack ~/.sversionrc, however removing this file will break everything, be careful.