|
|
Building OpenOffice.org 1.1.x under Windows with 4NTBeware! The build instructions for OpenOffice.org 2.x are different! 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 Basically, there is the choice to build OpenOffice.org from two different branches: a stable branch, which results in the release version, or a less stable developer branch (latest release see here). Links to the different sources are given in the document. Table of Contents
OverviewThis 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 http://download.openoffice.org/index.html 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. Overview of Performing a Full BuildTo perform a full build, you need to follow these steps:
Overview of Building an Individual ProjectYou 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:
Build RequirementsBefore 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 6: Within the Cygwin Toolkit, three executables might be realised as symlinks, namely awk.exe, gunzip.exe and tar.exe. This might lead to a break of the build later, and the symlinks should be replaced with copies of the command they link to. Check, in a cygwin shell, with ls -l /bin/awk.exe whether awk.exe is a symlink. For instance, awk.exe could be a link to gawk.exe, in which case you should copy gawk.exe to awk.exe: cd /bin; cp gawk.exe awk.exe. Take similar action for unzip.exe and tar.exe. Important Note 7:
If your cygwin installation includes the XFree86 packages make sure to
remove/change the Important Note 8: Don't use Cygwin 1.5.7, there were some problems with this version. Upgrade to a newer release. Perl - Optional requirementsFor committers who want to use the CWS tooling. Install them like this.
Hardware Requirements
External ComponentsThe 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. Get the source codeYou have two options to get the source code:
Generating the Build Environment and Build ToolsIdeally, 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, 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
This configuration file will be moved into the The following should demonstrate in detail what steps have to be done to set up the environment: As 4nt is not the only possible shell, you should enable the use of 4NT with--with-use-shell=4nt
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
There are a number of further options that you can use with the
config_office> bash configure --help
After running
If you experiment with newest sources from the cvs-tree, mind that updates
to the configure process may not happen via updates of If you need to modify or create a correct configure 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 Build InstructionsBuilding a Full Build of the Office SuiteNow you are ready to build OpenOffice.org. To build the entire suite, all you have to do (after having created the environment as described above) is to run dmake from the top-level directory. This may take several hours.$SRC_ROOT> dmake
If you decide to rebuild a module or build each module individually (mind
dependencies!), you will have to use the $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.
Building Individual Projects with a PrebuiltOpenOffice.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 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 $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 $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.
Building a Project with Debug Information
To rebuild a complete project with debug information, remove all object
files by removing the
$SRC_ROOT/(module)> rm -rf wntmsci9.pro $SRC_ROOT/(module)> build debug=true Instructions to Build an Installation Set
The build process (started with a top-level If you have built an installation set earlier and want to re-build it, please delete the local outpath first: $SRC_ROOT/instsetoo> rm -rf wntmsci9.pro
The English installation set will be located at
$SRC_ROOT> cd instsetoo/wntmsci9.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 For information on creating an automated installation script and create a response file. Building Localised Versions of OpenOffice.org
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,
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 help-content for the language of choice has to be unzipped into the directory
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 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
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:
Similarly, 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. |


