These are the legacy instructuions for builds prior to OpenOffice 1.1 RC.
This includes the OO64x and OOo 1.0.x family and the Openoffice 1.1 beta versions.
This document describes the requirements and actions that you need to build OpenOffice.org on Windows.
Commands you have to type on the keyboard follow this syntax throughout this document:
D:\my\source> winenv.bat
In this example, the script winenv.bat
is executed in the directory
D:\my\source
under a 4NT shell. Unless stated otherwise, all commands
appearing in this document should be entered from a 4NT shell (the exception
is the configure script which has to be run from a cygwin bash shell).
$SRC_ROOT
will denote the directory in which the source code
of OpenOffice.org is stored.
Basically, there is the choice to build OpenOffice.org from two different branches: a stable branch, which results in the 1.0.x releases, or a less stable developer branch (latest release see here). Links to the different sources are given in the document.
This section is meant as a reminder or checklist for those who have some experience in building OpenOffice.org. Everybody else should jump to the Build Requirements section.
Even experienced builders are well advised to check the release notes at download.openoffice.org and the section Build Requirements in this document to inform yourself about changes since the previous releases.
Detailed step-by-step build descriptions are given from the next section on.
You can perform a full build, or you can build an individual project using a prebuilt version.
To perform a full build, you need to follow these steps:
configure
script in a cygwin bash shell to
check all requirements and to create the script winenv.bat
.
winenv.bat
(under 4NT) script to set all environment variables.
Please see the last screen from the configure script for more specific information on setting up for your platform.
dmake
in $SRC_ROOT
, or
build -all
in the instsetoo
module, or
build
followed by deliver
in the individual
modules. You can use a prebuilt version to build an individual project. Having a prebuilt version is necessary because the individual project you want to build could depend on other projects. A project builds a particular component of OpenOffice.org. For example, the Word Processing project builds the Word Processing application. To build an individual project, you must follow these steps:
solver643B_win32intel.tar.gz.
643 is a very old release. Please use the latest version.
res
, check
out this module also. You can, of course, also download the entire source
from the download webpage
(download.openoffice.org).
However, it is not possible to download individual modules there. config_office
. This is always necessary
to create the build environment. solenv
. $SRC_ROOT
directory. configure
script in a cygwin bash shell to
check all requirements and to create the script winenv.bat
.
Note that all paths should NOT contain spaces. This will confuse dmake later.
winenv.bat
to set all environment variables.
solver
using the build
tool, followed by deliver
. Before you start building, you must ensure that your system satisfies the recommended software and hardware requirements for the type of system you are working on. For Windows, these are as follows:
Build Requirements
Important Note 1: Please ensure that the path to the 4NT application
directory doesn't contain one or more spaces. No, not even
c:\Program Files\4NT\
. In this case uninstall and re-install
to a directory without spaces.
Important Note 2: Before you use 4NT, you must ensure that the initialization
file 4nt.ini
is present in the 4NT application directory. The
following code sample shows the content of the 4nt.ini
file:
[4NT] CommandSep = ^ EscapeChar = Ctrl-X ParameterChar = & LocalAliases = Yes
share
subdirectory
of the cygnus-b20 installation has to be replaced by the corresponding file
from the Bison version 1.28. To make things even more complicated, what cygnus-b20
understands as bison.simple is called bison.s1 at gnu.org, and yet other distributions
name that file bison.hai. This means that if you put gnu's bison 1.28 to C:\bison-1.28
and cygwin b-20 resides in C:\cygnus\cygwin-b20
, you have to
do the following copy command: C:\tmp
directory to function properly.
ML.EXE
and ML.ERR
). If not, instructions on
where and how to get a free version can be found at
http://www2.dgsys.com/~raymoon/faq/masm.html#9.
Place ML.EXE
and ML.ERR
somewhere in a directory
and note the path, i.e. C:\ml
zip.exe
Version 2.2 or higher, and unzip.exe
.
If you do not have these already, you can download them from
www.info-zip.org.
Note: The cygwin zip.exe is not working for the build under the 4NT shell.
You have to use the native w32 version.
Make sure that the first zip.exe in your path is the native w32
version, e.g. rename or delete the zip.exe in your cygwin /bin directory and
copy the InfoZip version to this place.
--with-2003-psdk
is used.)
You can download (only the 02/2003 !!! version) this from
http://www.microsoft.com/msdownload/platformsdk/sdkupdate.
AdoCtint.h
and SqlUcode.h
from this SDK into $SRC_ROOT/external/download.
unicows.dll
has to be downloaded and installed in the system or
windows directory (i.e. C:\WINDOWS\SYSTEM
or C:\WINDOWS
, respectively).
A self-extracting binary is available for download at
http://download.microsoft.com/download/platformsdk/Redist/1.0/W9XMe/EN-US/unicows.exe.
For technical details see
http://porting.openoffice.org/servlets/ReadMsg?msgId=116287&listName=dev and
http://porting.openoffice.org/servlets/ProjectDocumentList?dcID=515&action=download.
(This only affects 643 builds.)
$SRC_ROOT/external/gpc
.
Hardware Requirements
The code contains some further external components which are already provided. If you are interested in details about these, look at the External Components webpage at http://tools.openoffice.org/ext_comp.html.
You have two options to get the source code:
oo_643B_src.tar.gz
in case of the 643B release.
Unpack the tarballs as follows (for the example 643B):
> gunzip oo_643B_src.tar.gz > tar -xvf oo_643B_src.tar > cd oo_643B_src
This will be $SRC_ROOT from now on. NB: 643 is a very old release use a current one.
anoncvs
:
> cvs -d:pserver:anoncvs@anoncvs.services.openoffice.org:/cvs loginThe non-bold slash means that the command should be in one line. It is possible to update an already existing older copy to a newer release:Just press enter when prompted for the password.
> cd $SRC_ROOT $SRC_ROOT> cvs / -d:pserver:anoncvs@anoncvs.services.openoffice.org:/cvs / co -r OpenOffice643 OpenOffice
$SRC_ROOT> cvs / -d:pserver:anoncvs@anoncvs.services.openoffice.org:/cvs / update -r OpenOffice643 OpenOffice
$SRC_ROOT> cvs / -d:pserver:anoncvs@anoncvs.services.openoffice.org:/cvs / co -r OpenOffice643 (module-name)
A note on the tags (i.e. the argument to the -r option in the cvs commands listed above): If HEAD is used as a tag, you will get the newest latest source code. This, however, will most likely not build since development is going on there. In general, the code is given a weekly tag like SRC641 (with weekly increasing numbers), and from there a branch tag OO641B (standing for OpenOffice.org 641 Branch) is created. Release engineering builds on this branch, adds eventual fixes, and tags the result as OpenOffice641B. The source tarballs are also created from this, i.e. the code resulting from checking out against OpenOffice641B is identical to the one in the 641 source tarball. After release, some further bug fixes will enter the branch. From then on, the code at OO641B and OpenOffice641B will differ. Finally, changes made on the branch (i.e. the difference between OO641B and SRC641) will be merged back to the main trunk.
Some releases are respins of a previous release. Those are marked 'C' instead of 'B' (for instance OO641C and OO643C. Note that 'B' stands for 'branch' and not for any counting index, even though it is treated like that in case of a respin. Therefore, there is no such tag as OO641A.
This process is currently under change so the above may be outdated when you read it.
Ideally, in keeping with the principles of open source, you would use an open source shell to build on a computer running a Win32 operating system. However, this is still experimental (you chose the safe way). You decided to use a non-open source shell to build on a computer running a Win32 operating system: the 4NT command shell.
On the other hand, the Cygnus bash
shell is needed to run
the configure
script which generates the build environment. The
configure
script checks that all software, hardware, and system
requirements for the build are satisfied, and it creates a configuration file
called winenv.bat
that you then execute to set all necessary
build environment variables. We demonstrate a sample run below.
This configuration file will be moved into the SRC_ROOT
directory.
A top-level makefile script makefile.mk
will be moved into SRC_ROOT
as well. This is due to technical reasons:
The SRC_ROOT
directory in the cvs tree can only hold directories.
On the other hand, the top-level makefile.mk
should logically be
placed in the top-level directory SRC_ROOT
. The cvs tree holds
these files in config_office
and configure
copies
them up.
The following should demonstrate in detail what steps have to be done to set up the environment:
Run the configure script according to the following example. We assume here that
C:\oo643B
C:\jdk1.3.1
C:\PROGRA~1\MICROS~3\VC98
(or C:\program files\microsoft visual studio\vc98
)
C:\PROGRA~1\MICROS~5
(only applies for 643B and later)
C:\ml
C:\unzip
Running the configure script could then look like the following (bold typed text is what you enter):
(open a cygwin bash shell)
cd /cygdrive/c/oo643B/config_office (new cygwin tools) or
cd //c/oo643B/config_office (old cygwin b20 tools, deprecated)
./configure --with-cl-home=/cygdrive/c/PROGRA~1/MICROS~3/VC98 --with-asm-home=/cygdrive/c/ml --with-jdk-home=/cygdrive/c/jdk1.3.1 --with-unzip-home=/cygdrive/c/unzip
.
.
.
(some screen output here)
.
.
.
(more screen output here)
bash-2.02$ exit
winenv.bat
from your 4NT shell.
Note the change in pathname notation. Since the cygwin bash
shell won't accept backslashes, paths have to be typed in a
cygwin bash notation which is //C/path/to/file
or /cygdrive/c/path/to/file
for b-20 or
new cygwin tools, respectively,
instead of C:\path\to\file
. This may appear
confusing at the moment, but sticking to this notation will
work.
There are a number of further options that you can use with the
configure
script. To display these options, type
the following command:
config_office> bash configure --help
After running configure
you have to execute the
configuration file which sets all environment variables. The generated
file is called winenv.bat
.
If you experiment with newest sources from the cvs-tree, mind that updates
to the configure process do not happen via updates of configure
(the script file) but via the files configure.in
and
set_soenv.in
. The configure script itself is created from
configure.in
and set_soenv.in
using the
autoconf
command. In this case, you would run commands
like the following:
$SRC_ROOT> cd config_office config_office> cvs update configure.in get a bash shell config_office>bash autoconf exit the bash shell
To update the configure
script. If you only use code from the
snapshot releases on the web, you don't need to be concerned about this.
$SRC_ROOT> dmake
If you decide to rebuild a module or build each module individually (mind
dependencies!), you will have to use the build
tool. A subsequent
deliver
will copy all created binaries, libraries etc. into the
solver tree:
$SRC_ROOT/(module)> build $SRC_ROOT/(module)> deliver
The following table shows the time required to build on a system with a particular specification. You can use these details to estimate the time required to build on your system.
Architecture | Intel |
Processor | Pentium III |
Processor speed | 600 MHz |
RAM | 256 MB |
Hard Disk | 6 GB SCSI |
Time | ~10 h |
OpenOffice.org is organised 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.org to a
special application, say, for instance, the spreadsheet application. The
program will always consist of 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.
Most modules will depend on other modules to be already built.
In other words, all modules must build in a particular order. To avoid
building all modules which are prerequisites of the module of your
interest, you can make use of a prebuilt solver
tree against
which you can build any module.
For more information on modules and on the sequence that they build in, and on the dependencies, see tools.openoffice.org/modules.html.
You have to download the solver
tree as a tarball. For example
solver643B_win32int.tar.gz
from the Download page at
http://download.openoffice.org,
use a current release 643 is very old,
and unpack it in the $SRC_ROOT
directory, e.g.:
$SRC_ROOT> tar -xvzf solver643B_win32int.tar.gzIn order to create the build environment and build tools, you also have to check out the
config_office
module and solenv
.
To build a project, you build each of its modules individually in their
directory with the build
tool, followed by deliver
to copy the created libraries, binaries etc. into the solver tree:
$SRC_ROOT/(module-name)> build $SRC_ROOT/(module-name)> deliverFiles called
build.lst
in the directories
(module-name)/prj
contain all information about the
subdirectories to be build (each of them containing makefiles
makefile.mk
), about internal dependencies, and also about
modules the current module depends on. The files
(module-name)/prj/d.lst
control the actions done by
deliver
. The last or second to last directory to be build is
usually module-name/util
which is responsible for
linking one or more shared libraries.
To rebuild a complete project with debug information, remove all object
files by removing the
wntmsci7.pro
directory. Then run build
with the debug option set to true:
$SRC_ROOT/(module)> rm -rf wntmsci7.pro $SRC_ROOT/(module)> build debug=true
The build process (started with a top-level dmake
or
build -all
in $SRC_ROOT/instsetoo
) will create
installation sets in english and german.
A simple build
in
$SRC_ROOT/instsetoo
will also create the installation sets,
provided all other modules are already built.
If you have build an installation set earlier and want to re-build it, please delete the local outpath first:
$SRC_ROOT/instsetoo> rm -rf wntmsci7.pro
The English installation set will be located at
$SRC_ROOT/instsetoo/wntmsci7.pro/01/normal
.
Execute the setup
binary to install:
$SRC_ROOT> cd instsetoo/wntmsci7.pro/01/normal normal> setup.exeThe 01 in the path names indicates that the localisation is american english. This number corresponds to the international phone code for the USA. The German installation set will be located in a subdirectory 49. This scheme holds true for all localisations you may have chosen explicitly (see next section Building Localised Versions of OpenOffice.org).
For a network installation, use the -net
option to
setup
. Details on the network installation process
can be found at
http://installation.openoffice.org/proposals/netinstall.html
in the installation project webpage.
For information on creating an automated installation script and create a response file.
Running the configure script with the --with-lang option will introduce the build
of additional language resources. This option will introduce a command in the
environment settings file which in turn after execution sets a variable like, for instance,
RES_FREN
to TRUE
in the case of french (You can also set
this variable by hand in order to introduce another language). It is also possible to
build more than one language at once.
One language resource, however, will not be
introduced that way: the help content! Clicking on 'help' would still open english
help documents.
There is no automatic procedure yet to implement non-english help, but the additional manual effort is rather minimal: After building the source as described above, but before building the installation set, a zip-file with all helpcontent for the language of choice has to be unzipped into the directory
$SRC_ROOT/solver/641/wntmsci7.pro/pck
.
The filenames of these files contain a number code for the language, corresponding to
the international phone code of a country in which that language is mainly spoken.
For instance, the file
helpcontent_34_wnt.zip
contains all helpcontent for the spanish localisation.
The zipfiles themselves are available at
ftp.services.openoffice.org/pub/OpenOffice.org/contrib/helpcontent/.
Having unzipped the helpcontent files in there, building of installation sets can be resumed or repeated (in case you already have build some), as described in the previous chapter. English installation sets will be located in
$SRC_ROOT/instsetoo/wntmsci7.pro/01/normal
,
where 01 corresponds to the international phone code of the USA.
If you have chosen, for instance, French (by configuring with the --with-lang=FREN
option)
you will find an additional directory called 33:
$SRC_ROOT/instsetoo/wntmsci7.pro/33/normal
.
Similarily, you will find 49 for German, 34 for Spanish, etc.
Localised help content is not yet available for all languages. In such cases, the english helpcontent will appear in the installations. For instance, when Danish is set with configure, you will find installation sets under the directory 45, but the help files will appear in english.