Difference between revisions of "Documentation/Building Guide/Building on Linux"

From Apache OpenOffice Wiki
Jump to: navigation, search
 
(57 intermediate revisions by 22 users not shown)
Line 1: Line 1:
 +
{{Documentation/Building Guide TOC
 +
|ShowNextPage=none
 +
|ShowPrevPage=none
 +
}}
 
{{DISPLAYTITLE:Building on Linux}}
 
{{DISPLAYTITLE:Building on Linux}}
[[Category: Development]]
+
 
[[Category:Build_System]]
 
{| style="font-size: 11px; float: right; width: 180px; border: 1px solid #9BC0F5;" cellspacing="0"
 
|-
 
| <div id="doc_toctitle" class="docooo_toctitle docsection" style="text-align: center;"><strong class="selflink">Building Guide</strong></div>
 
|-
 
| [[Development/OpenOffice.org_Building_Guide | Introduction]]<br>
 
[[Development/OpenOffice.org_Building_Guide/Getting the source | Getting the source]]<br>
 
[[Development/OpenOffice.org_Building_Guide/Basic Concepts | Basic Concepts]]<br>
 
[[Development/OpenOffice.org_Building_Guide/Build Requirements | Build Requirements]]<br>
 
[[Development/OpenOffice.org_Building_Guide/Building on Windows | Building on Windows]]<br>
 
[[MacOSXBuildInstructions | Building on Mac OS X]]<br>
 
[[Development/OpenOffice.org_Building_Guide/Building on Linux | Building on Linux]]<br>
 
[[Development/OpenOffice.org_Building_Guide/Building on Solaris | Building on Solaris]]<br>
 
|-
 
|}
 
 
__TOC__
 
__TOC__
= Overview =
+
<!-- insert comment -->= Overview =
{{Template:Documentation/Linux|This document describes building OpenOffice.org on Linux.}}
+
{{Note|<code>$SRC_ROOT</code> will denote the directory in which the source code of OpenOffice.org is stored.}}
{{Template:Documentation/Note|<code>$SRC_ROOT</code> will denote the directory in which the source code of OpenOffice.org is stored.}}
+
{{Tip|You are advised to check the release notes for the release you are building to inform yourself about changes since previous releases.}}
{{Template:Documentation/Tip|You are advised to check the release notes for the release you are building to inform yourself about changes since previous releases.}}
 
  
 
= Requirements =
 
= Requirements =
== Hardware Requirements ==
+
 
 +
== hardware requirements ==
  
 
* 1 or more reasonable fast CPUs, x-way CPU's recommended.
 
* 1 or more reasonable fast CPUs, x-way CPU's recommended.
Line 29: Line 18:
 
* 1 GB Ram ( 2 GB recommended )
 
* 1 GB Ram ( 2 GB recommended )
  
* 10 GB free disk space
+
* at least 10 GB free disk space
 +
 
 +
== Software requirements ==
  
== Software Requirements ==
+
{{Tip|The most recent information for building on specific Linux distributions can be found at:
 +
* [[Documentation/Building Guide AOO/Building on Linux|AOO Building on Linux]]
  
* glibc:
+
Historical (outdated but perhaps useful) information on distribution specific packages can be found from the [[:Category:Distribution-Specific_Build_Instructions|Distribution specific build instructions pages]].  Included distributions are:
** for OOo<=3.1: 2.2.x or higher
+
*[[Fedora_Build_Instructions|Fedora]]
** for OOo>3.1: 2.3.2 or higher
+
*[[Gentoo_build_instructions|Gentoo]]
 +
*[[OpenSUSE_Build_Instructions|OpenSUSE]]
 +
*[[SUSE9.3_Build_Instructions|SUSE9.3]]
 +
*[[Ubuntu_Build_Instructions|Ubuntu]]}}
  
 
* C/C++ Compiler:
 
* C/C++ Compiler:
Line 41: Line 36:
 
** gcc 4.2.3 is the current reference compiler  
 
** gcc 4.2.3 is the current reference compiler  
  
* The X11 development libraries and header files<sup>[[#Foot1|1]]</sup>.
+
* The X11 development libraries and header files<ref name="Foot1">{{Note|Should be in place with most Linux distributions. Note the there are currently some issues with X version 4.3.}}</ref>
  
* PAM including the development headers<sup>[[#Foot2|2]]</sup>.
+
* PAM including the development headers<ref name="Foot2">{{Note|PAM should be installed by default on most linux distributions. You should only need to add the development package.}}</ref>
  
* bash<sup>[[#Foot3|3]]</sup>.
+
* bash.
  
* [http://www.cs.man.ac.uk/aig/staff/alan/software/|gpc general polygon clipper library release 2.31]
+
* gtk2 and libtiff including the development headers<ref name="Foot4">{{Note|The gtk2, jpeg and tiff libraries are not required if you disable the crash-reporter when running <CODE>./configure</CODE>.}}
* gtk2 and libtiff including the development headers<sup>[[#Foot4|4]]</sup>.
+
</ref>
  
 
= Full Builds =
 
= Full Builds =
  
 
To perform a full build, you need to follow these steps:
 
To perform a full build, you need to follow these steps:
 +
 +
== autoconf ==
 +
 +
The first time you have to run <code>autoconf</code> to prepare a valid and up-to-date <code>configure</code> script. And every time you make changes to the <code>configure.in</code> script, the script will remind you to run <code>autoconf</code> again.
 +
 +
autoconf
  
 
== configure ==
 
== configure ==
Line 59: Line 60:
 
  ./configure --help
 
  ./configure --help
  
An example configure command (on Ubuntu 9.04 with as much libraries by the system used as possible):  
+
An example configure command:  
  ./configure --with-use-shell=bash --with-system-libs \
+
  ./configure --without-junit --disable-odk
--without-system-jars --without-system-icu --without-system-agg \
 
--without-system-lpsolve --without-system-mspack --disable-mozilla
 
  
See the last information box in the configure script for more information for your platform.
+
See the last information box in the configure script or [[:Category:Distribution-Specific_Build_Instructions]] for more information for your platform.
  
{{Documentation/Caution| Please check for any warnings emitted by the configure-script.}}
+
{{Warn| Please check for any warnings emitted by the configure-script.  The page [[OpenSolaris Build Instructions/Configure Errors]] may be helpful in debugging all the dependencies.}}
  
 
== bootstrap ==
 
== bootstrap ==
Line 75: Line 74:
 
to create the dmake executable required to build OpenOffice.org.
 
to create the dmake executable required to build OpenOffice.org.
  
== setting the enviroment ==
+
== setting the environment ==
  
When the configure script has been run successfully a file <code>LinuxIntelEnv.Set.sh</code> was created<sup>[[#Foot5|5]]</sup>.
+
When the configure script has been run successfully a file <code>LinuxX86Env.Set.sh</code> or <code>LinuxX86-64Env.Set.sh</code> was created<ref name="Foot5">{{Note|When you want to use tcsh instead of bash, you will need to use the file <code>LinuxX86Env.Set</code> instead:<br>
 +
<pre> source LinuxX86Env.Set
 +
rehash</pre>
 +
If you do not use tcsh, it is better to delete that file, as it will get in the way for tab-completion sooner or later.}}
 +
</ref>.
 
Do this:
 
Do this:
  
 
  source LinuxX86Env.Set.sh
 
  source LinuxX86Env.Set.sh
  
to set up the enviroment for the build.
+
or
 +
 
 +
source LinuxX86-64Env.Set.sh
 +
 
 +
to set up the environment for the build<ref name="Foot6">By default, native packages (.deb/.rpm) will be build.<br>
 +
{{Tip|If you want to have something faster and easier to test:<br>
 +
<pre>export FORCE2ARCHIVE=true</pre>
 +
This will create a tarball that can easily be unpacked and run anywhere. An alternative is to set<br>
 +
<pre>export PKGFORMAT=installed</pre>
 +
which will create a runnable installation in the output directory of instsetoo_native (Dont set LOCALINSTALLDIR on older milestones, see {{issue|111450}}.}}
 +
</ref>.
  
== configure to build a ready-to-run installation (optional) ==
+
{{Note| This step has to be redone in each shell you are going to use for building.}}
To have the build create a ready-to-be-run installation for testing purposes, set the following environment variables<sup>[[#Foot6|6]]</sup>.
 
export LOCALINSTALLDIR="/my/Destination/Dir"
 
export PKGFORMAT="installed"
 
If you do not set PKGFORMAT, native packages (.deb/.rpm) will be build.
 
  
 
== starting the build ==
 
== starting the build ==
Build the software by typing the following in <code>$SRC_ROOT</code><sup>[[#Foot7|7]]</sup>:
+
Build the software by typing the following in <code>$SRC_ROOT</code><ref name="Foot7">{{Note|You can also run:<br>
  dmake
+
<pre>make</pre>
 
+
but GNU make will just start build.pl.
The building procedure will take at least an hour (on a 3 GHz Quad-Core with 8GB RAM).
+
For details run:<br>
 +
<pre>build --help</pre>}}
 +
</ref>:
 +
  cd instsetoo_native && build --all
 +
The building procedure will take at least an hour (on a 3 GHz Quad-Core with 8GB RAM without CCACHE).
  
 
= Partial Builds =
 
= Partial Builds =
Line 101: Line 114:
 
* incompatible
 
* incompatible
 
Only do compatible partial builds if you know exactly what you are doing.
 
Only do compatible partial builds if you know exactly what you are doing.
{{Documentation/Note|For more information, see [[Compatible Builds]].}}
+
{{Note|For more information, see [[Compatible Builds]].}}
 
== rebuilding from a module (incompatible build) ==
 
== rebuilding from a module (incompatible build) ==
  
Line 118: Line 131:
 
  build && deliver
 
  build && deliver
  
A simple <code>build</code> in <code>$SRC_ROOT/instsetoo_native</code> will recreate the installation sets, provided all other modules have already been build.<sup>[[#Foot8|8]]</sup>
+
A simple <code>build</code> in <code>$SRC_ROOT/instsetoo_native</code> will recreate the installation sets, provided all other modules have already been build.<ref name="Foot8">{{Warn|<code>build --all</code> would rebuild changed/missing files. However, it does not check for incompatible modules. If unsure, use <code>build --from --prepare</code>.}}
 +
</ref>
  
  
{{Documentation/Caution|This does '''not''' check for incompatible modules. If unsure, use an incompatible build (see above).}}
+
{{Warn|This does '''not''' check for incompatible modules. If unsure, use an incompatible build (see above).}}
  
  
= Building a module with Debug Information =
+
= Building a Module with Debug Information =
  
 
To rebuild a module with debug information and additional assertions and checks, run:
 
To rebuild a module with debug information and additional assertions and checks, run:
Line 134: Line 148:
 
Drop the newly created binaries into an existing installation. Building an installation set with them will not help, as binaries are stripped on packing by default.
 
Drop the newly created binaries into an existing installation. Building an installation set with them will not help, as binaries are stripped on packing by default.
  
{{Template:Documentation/Tip|For details, see [[Debugging]].}}
+
{{Tip|For details, see [[Debugging]].}}
  
 
= Finding Installation Sets =
 
= Finding Installation Sets =
  
The english installation set will be located at <code>$SRC_ROOT/instsetoo_native/unxlngi6.pro/OpenOffice/{deb,rpm,archive}/install/en-US/</code><sup>[[#Foot9|9]]</sup>.
+
The english installation set will be located at <code>$SRC_ROOT/instsetoo_native/unxlngi6.pro/OpenOffice/{deb,rpm,archive}/install/en-US/</code><ref name="Foot9">The en-US in the path names indicates that the localization is American English. This value corresponds to the language tags defined by RFC 1766 (Tags for the Identification of Languages). The German installation set will be located in a <tt>de</tt> subdirectory. This scheme holds true for all localizations you may have chosen explicitly.
 +
 
 +
{{Tip|Running the configure script with the --with-lang option will introduce the build of additional language resources. This switch accepts one or more RFC 1766 language tags as arguments. Check the value of the <code>completelangiso</code> macro in <code>$SRC_ROOT/solenv/inc/postset.mk</code> for all the currently supported language tags.<br>
 +
Example:<br>
 +
<pre>./configure --with-lang="de fr"</pre>
 +
This enables the build of the localized German and French version. The environment variable <code>WITH_LANG</code> will then contain the language tags of the additional (en-US will always be built) languages.}}
 +
 
 +
{{Note|If you build additional localized languages it is possible to generate Language Packs that contain only the changes needed to add the additional language to an OpenOffice.org of a different language. The following commands will generate language packs languages that were specified with the --with-lang switch during the configure phase. <br>
 +
<pre>cd $SRC_ROOT/instsetoo_native/util
 +
dmake ooolanguagepack</pre>}}
 +
{{Warn|Note that you can only build the language packs '''after''' you have build the complete office with all selected languages.}}
 +
</ref>.
 +
 
 +
{{Note| For 64-bit Linux it is <code>unxlngx6.pro</code> instead of <code>unxlngi6.pro</code>.}}
 +
See also [[Run_OOo_versions_parallel|Run parallel versions]].
 +
 
 +
= Tips And Tricks =
 +
== ccache ==
 +
 
 +
export CCACHE_DIR="some/place/with/space"
 +
ccache -M 2G -F 100000
 +
export CXX="ccache g++"
 +
export CC="ccache gcc"
 +
 
 +
== dependencies ==
 +
 
 +
'''nodep'''
 +
 
 +
If you set the environment variable <code>nodep</code> to <code>TRUE</code>, then dependency information files are not created - the build finishes faster.
  
{{Template:Documentation/Note| For 64-bit Linux it is <code>unxlngx6.pro</code> instead of <code>unxlngi6.pro</code>.}}
+
{{Warn|But only enable that on a clean build. Once you have built OOo and then made modifications, unset the variable again to be on the safe side.}}
  
= See Also =
+
'''NO_HIDS'''
* [[Building OpenOffice.org]] (esp. the Tips and Tricks section for stuff like ccache)
+
 
 +
Similar to the <code>nodep</code> variable, this one prevents the generation of HIDs (Help IDs) that are mainly used for automated testing - if you only want to build OOo, you don't need those.
 +
 
 +
== parallel builds ==
 +
If you have a multiprocessor machine or similar, you can run a parallel build. There are two levels  of parallelism  - one operating on makefile (directory) level, the other one on the global level. The two levels of parallelism result from the two-step build procedure in the OOo build environment. The build script runs through all the directories it reads from the build.lst files in all modules and calls dmake for every directory.
 +
 
 +
'''parallelism on the global level'''
 +
 
 +
For parallelism on the global level, you have to run build from <code>$SRC_ROOT>/instsetoo_native</code> with the <code>-P<number></code> switch, for example:
 +
<pre>
 +
build -P2
 +
</pre>
 +
 
 +
This takes build how many dmake processes it is allowd to start in parallel.
 +
 
 +
'''parallelism on the directory level'''
 +
 
 +
export MAXPROCESS=<numer or processes>
 +
 
 +
This tells dmake how many targets it is allowed to build in parallel. When you don't use build.pl but build a single directory (single makefile), you can achieve the same with
 +
 
 +
<pre>
 +
dmake -P2
 +
</pre>
  
= Footnotes =
+
'''combining both levels'''
<span id="Foot1"><sup>1</sup> {{Template:Documentation/Note|Should be in place with most Linux distributions. Note the there are currently some issues with X version 4.3.}}</span>
 
  
<span id="Foot2"><sup>2</sup> {{Template:Documentation/Note|PAM should be installed by default on most linux distributions. You should only need to add the development package.}}</span>
+
If you want to have parallelism on both levels, you can call
  
<span id="Foot3"><sup>3</sup> {{Template:Documentation/Note|You can also (still?) use tcsh instead of bash, but bash is installed almost everywhere anyway. It is possible to use bash or tcsh as shell. This is switched with the <CODE>--with-use-shell</CODE> configure switch.}}</span>
+
<pre>
 +
build -P2 -- -P2
 +
</pre>
  
<span id="Foot4"><sup>4</sup> {{Template:Documentation/Note|The gtk2, jpeg and tiff libraries are not required if you disable the crash-reporter when running <CODE>./configure</CODE>.}}
+
"--" is a special build.pl parameter that passes every further parameters to the dmake processes it starts.
</span>
 
  
<span id="Foot5"><sup>5</sup> {{Template:Documentation/Note|When you want to use tcsh instead of bash, you will need to use the file <code>LinuxX86Env.Set</code> instead:<br>
+
''' Recommendation '''
<pre> source LinuxX86Env.Set
 
rehash</pre>
 
If you do not use tcsh, it is better to delete that file, as it will get in the way for tab-completion sooner or later.}}
 
</span>
 
  
<span id="Foot6"><sup>6</sup> {{Template:Documentation/Tip|Alternativly you can set:<br>
+
Experience tells that using the doubled number of cores in your machine is a good choice, using more threads does not make a big difference, except if the combined option is chosen. So even on single core machines using two threads will speed up the build considerably.
<pre>export FORCE2ARCHIVE=true</pre>
 
This will create a tarball that can easily be unpacked and run anywhere.}}
 
</span>
 
  
<span id="Foot7"><sup>7</sup> {{Template:Documentation/Note|You can also run:<br>
+
== create prebuilt mozilla ==
<pre>make</pre>
+
For the mozilla-components you have the choice to either build from mozilla sources, to use precompiled packages or to use system-mozilla (the one installed on your buildsystem, not everything might work, depending on the version you got installed).
but GNU/make will just start dmake. You can also run the following in the <code>instetoo_native</code> module:<br>
+
You can easily create your own version of the prepacked binaries if you wish to do so (either because you cannot use the official ones because of mismatch of compiler version used to build them/other technical reasons or because you want to use stuff you didn't build yourself).
<pre>build --all</pre>
+
To do so:
For details run:<br>
 
<pre>build --help</pre>}}
 
</span>
 
  
<span id="Foot8"><sup>8</sup> {{Documentation/Caution|<code>build --all</code> would rebuild changed/missing files. However, it does not check for incompatible modules. If unsure, use <code>build --from --prepare</code>.}}
+
* build the <code>moz</code> module from the mozilla sources
</span>
+
* use <code>--enable-build-mozilla</code> when running configure and put the mozilla-source tarball to <code>moz/download</code>
 +
* in <code>moz</code> run <code>dmake zip</code> to create the zip files
 +
* you'll find the zips in <code>{platform}.pro/zipped</code>
  
<span id="Foot9"><sup>9</sup> The en-US in the path names indicates that the localization is American English. This value corresponds to the language tags defined by RFC 1766 (Tags for the Identification of Languages). The German installation set will be located in a de subdirectory. This scheme holds true for all localizations you may have chosen explicitly.
+
Copy them to a location of your liking.
 +
Now instead of using <code>--enable-build-mozilla</code>, use <code>--disable-build-mozilla</code> and copy the zips you created or downloaded to <code>moz/zipped</code> and these will be used when compiling.
 +
This will greatly reduce build-time (you save the time that would otherwise be spent on compiling mozilla).
 +
= See Also =
 +
* [[:Category:Distribution-Specific Build Instructions]]
 +
* [[Prepared Build Images]]
  
{{Template:Documentation/Tip|Running the configure script with the --with-lang option will introduce the build of additional language resources. This switch accepts one or more RFC 1766 language tags as arguments. Check the value of the <code>completelangiso</code> macro in <code>$SRC_ROOT/solenv/inc/postset.mk</code> for all the currently supported language tags.<br>
+
----
Example:<br>
 
<pre>./configure --with-lang="de fr"</pre>
 
This enables the build of the localized German and French version. The environment variable <code>WITH_LANG</code> will then contain the language tags of the additional (en-US will always be build)
 
languages.}}
 
  
{{Template:Documentation/Note|If you build additional localized languages it is possible to generate Language Packs that contain only the changes needed to add the additional language to an OpenOffice.org of a different language. The following commands will generate language packs languages that were specified with the --with-lang switch during the configure phase. <br>
+
<references/>
<pre>cd $SRC_ROOT/instsetoo_native/util
 
dmake ooolanguagepack</pre>}}
 
{{Template:Documentation/Caution|Note that you can only build the language packs '''after''' you have build the complete office with all selected languages.}}
 
</span>
 
  
 
{{PDL1}}
 
{{PDL1}}
 +
[[Category:Linux]]

Latest revision as of 08:17, 16 July 2018

[[{{{PrevPage}}}|< Previous Page

]]

[[{{{NextPage}}}|Next Page
>]]


Overview

Documentation note.png $SRC_ROOT will denote the directory in which the source code of OpenOffice.org is stored.
Tip.png You are advised to check the release notes for the release you are building to inform yourself about changes since previous releases.


Requirements

hardware requirements

  • 1 or more reasonable fast CPUs, x-way CPU's recommended.
  • 1 GB Ram ( 2 GB recommended )
  • at least 10 GB free disk space

Software requirements

Tip.png The most recent information for building on specific Linux distributions can be found at:

Historical (outdated but perhaps useful) information on distribution specific packages can be found from the Distribution specific build instructions pages. Included distributions are:


  • C/C++ Compiler:
    • gcc >= 3.3
    • gcc 4.2.3 is the current reference compiler
  • The X11 development libraries and header files⧼cite_reference_link⧽
  • PAM including the development headers⧼cite_reference_link⧽
  • bash.
  • gtk2 and libtiff including the development headers⧼cite_reference_link⧽

Full Builds

To perform a full build, you need to follow these steps:

autoconf

The first time you have to run autoconf to prepare a valid and up-to-date configure script. And every time you make changes to the configure.in script, the script will remind you to run autoconf again.

autoconf

configure

  • Run the configure script to check all requirements. Run the following command to view all possible options.
./configure --help

An example configure command:

./configure --without-junit --disable-odk

See the last information box in the configure script or Category:Distribution-Specific_Build_Instructions for more information for your platform.

Documentation caution.png Please check for any warnings emitted by the configure-script. The page OpenSolaris Build Instructions/Configure Errors may be helpful in debugging all the dependencies.

bootstrap

When configure finished successfully, run:

./bootstrap

to create the dmake executable required to build OpenOffice.org.

setting the environment

When the configure script has been run successfully a file LinuxX86Env.Set.sh or LinuxX86-64Env.Set.sh was created⧼cite_reference_link⧽. Do this:

source LinuxX86Env.Set.sh

or

source LinuxX86-64Env.Set.sh

to set up the environment for the build⧼cite_reference_link⧽.

Documentation note.png This step has to be redone in each shell you are going to use for building.

starting the build

Build the software by typing the following in $SRC_ROOT⧼cite_reference_link⧽:

cd instsetoo_native && build --all

The building procedure will take at least an hour (on a 3 GHz Quad-Core with 8GB RAM without CCACHE).

Partial Builds

There are two ways to do partial builds:

  • compatible
  • incompatible

Only do compatible partial builds if you know exactly what you are doing.

Documentation note.png For more information, see Compatible Builds.

rebuilding from a module (incompatible build)

If you decide to change a module in an incompatible way, you will need to rebuild all modules depending on it (directly or indirectly):

cd $SRC_ROOT/instsetoo_native
build --from $INCOMPATIPLEMODULE --prepare
build --from $INCOMPATIBLEMODULE

rebuilding a module (compatible build)

To rebuild a module you can delete all output directories with, rebuild and redeliver into the solver with:

cd $MODULE
build --from $MODULE --prepare
build && deliver

A simple build in $SRC_ROOT/instsetoo_native will recreate the installation sets, provided all other modules have already been build.⧼cite_reference_link⧽


Documentation caution.png This does not check for incompatible modules. If unsure, use an incompatible build (see above).


Building a Module with Debug Information

To rebuild a module with debug information and additional assertions and checks, run:

cd $MODULE
build --from $MODULE --prepare # removes old output trees and solver
build debug=true --from $MODULE

Drop the newly created binaries into an existing installation. Building an installation set with them will not help, as binaries are stripped on packing by default.

Tip.png For details, see Debugging.


Finding Installation Sets

The english installation set will be located at $SRC_ROOT/instsetoo_native/unxlngi6.pro/OpenOffice/{deb,rpm,archive}/install/en-US/⧼cite_reference_link⧽.

Documentation note.png For 64-bit Linux it is unxlngx6.pro instead of unxlngi6.pro.

See also Run parallel versions.

Tips And Tricks

ccache

export CCACHE_DIR="some/place/with/space"
ccache -M 2G -F 100000
export CXX="ccache g++"
export CC="ccache gcc"

dependencies

nodep

If you set the environment variable nodep to TRUE, then dependency information files are not created - the build finishes faster.

Documentation caution.png But only enable that on a clean build. Once you have built OOo and then made modifications, unset the variable again to be on the safe side.

NO_HIDS

Similar to the nodep variable, this one prevents the generation of HIDs (Help IDs) that are mainly used for automated testing - if you only want to build OOo, you don't need those.

parallel builds

If you have a multiprocessor machine or similar, you can run a parallel build. There are two levels of parallelism - one operating on makefile (directory) level, the other one on the global level. The two levels of parallelism result from the two-step build procedure in the OOo build environment. The build script runs through all the directories it reads from the build.lst files in all modules and calls dmake for every directory.

parallelism on the global level

For parallelism on the global level, you have to run build from $SRC_ROOT>/instsetoo_native with the -P<number> switch, for example:

build -P2

This takes build how many dmake processes it is allowd to start in parallel.

parallelism on the directory level

export MAXPROCESS=<numer or processes> 

This tells dmake how many targets it is allowed to build in parallel. When you don't use build.pl but build a single directory (single makefile), you can achieve the same with

dmake -P2

combining both levels

If you want to have parallelism on both levels, you can call

build -P2 -- -P2

"--" is a special build.pl parameter that passes every further parameters to the dmake processes it starts.

Recommendation

Experience tells that using the doubled number of cores in your machine is a good choice, using more threads does not make a big difference, except if the combined option is chosen. So even on single core machines using two threads will speed up the build considerably.

create prebuilt mozilla

For the mozilla-components you have the choice to either build from mozilla sources, to use precompiled packages or to use system-mozilla (the one installed on your buildsystem, not everything might work, depending on the version you got installed). You can easily create your own version of the prepacked binaries if you wish to do so (either because you cannot use the official ones because of mismatch of compiler version used to build them/other technical reasons or because you want to use stuff you didn't build yourself). To do so:

  • build the moz module from the mozilla sources
  • use --enable-build-mozilla when running configure and put the mozilla-source tarball to moz/download
  • in moz run dmake zip to create the zip files
  • you'll find the zips in {platform}.pro/zipped

Copy them to a location of your liking. Now instead of using --enable-build-mozilla, use --disable-build-mozilla and copy the zips you created or downloaded to moz/zipped and these will be used when compiling. This will greatly reduce build-time (you save the time that would otherwise be spent on compiling mozilla).

See Also


⧼cite_references_prefix⧽ ⧼cite_references_link_one⧽ ⧼cite_references_link_one⧽ ⧼cite_references_link_one⧽ ⧼cite_references_link_one⧽ ⧼cite_references_link_one⧽ ⧼cite_references_link_one⧽ ⧼cite_references_link_one⧽ ⧼cite_references_link_one⧽ ⧼cite_references_suffix⧽

Content on this page is licensed under the Public Documentation License (PDL).
Personal tools