Apache OpenOffice Wiki - User contributions [en]

Category:Distribution-Specific Build Instructions

2008-12-31T18:37:21Z

DavidRoss: added Category:Build_System

Yes, [[ooo-build]] has distribution-specific behavior. Most of the differences lie in package naming (e.g. '''''xxx''-devel''' on Fedora/SuSE vs '''lib''xxx''-dev''' on Debian/Ubuntu) and availability.

You may be safest going with SuSE, since that's where most of the development seems to be happening, but everyone has their favorite distro.

[[Category: Development]]
[[Category:Build_System]]

DE/Building OpenOffice.org de

2008-12-29T04:16:31Z

DavidRoss: added Category:Build_System

[[Category:Development]]
[[Category:Build_System]]

Dies sind die Anweisungen, wie man ein "einfaches" ("vanilla") (oder "Up-Stream") OpenOffice.org erstellt. Einfach bedeutet: ohne Werkzeuge wie ooo-build, das den Build-Prozeß übernimmt. Falls Sie ooo-build verwenden, schauen Sie stattdessen auf [[Erstellen_mit_ooobuild]].

= Kompilieren von OpenOffice.org : das Verfahren =
== Bekommen der Quellen ==
Um diese Anweisungen nicht länger als nötig zu machen, gibt es eine spezielle Seite hierzu unter [[Getting_It | Wie man die Quellen bekommt]].

== Abhängigkeiten ==
Sie benötigen natürlich einige installierte Entwicklungs-Bibliotheken (development libraries), um OpenOffice.org zu erstellen.
Das Skript configure wird es beanstanden, wenn etwas fehlt.
Bis dieser Leitfaden die Voraussetzungen auflistet, schauen Sie auf http://tools.openoffice.org/

==Unterschiedliche Plattformen==
Einige Informationen für bestimmte Plattformen werden unter [http://tools.openoffice.org#Build tools] zur Verfügung gestellt.

Sehen Sie sich für OS X auch [[AquaBuild]] ( experimentale Aqua-Version von OpenOffice.org) oder [[MacOSXBuildInstructions]] ( X11-Version ), für GNU/Linux Sparc [[GNULinuxSparcPorting]] und für Windows [[Windows]] an.

= Einen Meilenstein (Milestone) erstellen =
== Configure laufen lassen ==
Der erste Schritt nach dem Erhalten der Quellen (und hoffentlich aller Voraussetzungen) ist das laufen lassen von configure:

<pre>
cd <SRC_ROOT>
cd config_office
./configure
</pre>

Sie werden höchst wahrscheinlich configure mitteilen müssen, wo es einige Pakete wie beispielsweise Ant findet und welches Java es benutzen soll. Verwenden Sie
<pre>
./configure --help
</pre>
, um eine Liste der gültigen Optionen zu erhalten, die Sie verwenden können.

Falls Sie vergessen haben sollten, einige Abhängigkeiten zu installieren, wird Sie das Skript configure daran erinnern, welche fehlen.

Besonderer Tipp in Bezug auf Ant: Stellen Sie sicher, dass Sie einen absoluten Pfad verwenden.

== Bootstrappen ==
Falls configure sauber durchläuft (d.h., es endet ohne irgendeinen Fehler oder eine Warnung), können Sie mit dem Erstellen fortfahren.
Configure erstellt eine Umgebungsdatei, die Sie in Ihre Shell einlesen müssen.
Falls Sie eine Bash laufen haben, benutzen Sie
<pre>
cd <SRC_ROOT>
source LinuxX86Env.Set.sh
</pre>
Falls Sie eine tcsh oder etwas ähnliches laufen haben, verwenden Sie
<pre>
cd <SRC_ROOT>
source LinuxX86Env.Set
rehash
</pre>

Beachten Sie: der Dateiname des Umgebungsskriptes könnte auf einer anderen Systemarchitektur anders lauten. Ersetzen Sie 'X86' durch etwas, das adäquat ist. Beachten Sie auch, dass es bei älteren Versionen 'Intel' und nicht 'X86' ist.

Der letzte Schritt vor dem realen Erstellen besteht darin, die Erstellungswerkzeuge (buildtools) zu kreieren, die OOo verwendet. Um dies zu tun, lassen Sie einfach folgendes laufen:
<pre>
./bootstrap
</pre>
in <SRC_ROOT>

== Das eigentliche Erstellen starten ==
Nun ist es an der Zeit für das eigentliche Erstellen
Tippen Sie einfach
<pre>
dmake
</pre>
in <SRC_ROOT> ein und entspannen Sie sich dann.
Das Erstellen von OOo erfordert einige Zeit (circa 10-12 Stunden auf einem Standard-Schreibtisch-PC), weshalb Sie in der Zwischenzeit andere Dinge tun können.

= Erstellen eines [[CWS]] =
Um einen Child Workspace (CWS) zu erstellen, müssen Sie zuerst den Meilenstein (milestone) auschecken, auf dem der CWS basiert (sehen Sie oben das Erhalten der Quellen). Danach müssen Sie die Module, die in den CWS einbezogen sind, mit den CVS-Markierungen (cvs tag) des CWS aktualisieren.

Sie können entweder [[EIS]] verwenden, um Informationen darüber zu erhalten, welcher Meilenstein die Basis für den CWS ist (sehen Sie sich hierzu das Feld "Milestone (current)" an) und welche Module in ihn einbezogen sind (sehen Sie sich hierzu die Tabelle "Modules & Files" an). Oder Sie können [http://go-oo.org/tinderbox/tags/tag-list Tinderbox's tag-list] benutzen, um diese Information zu erhalten.

Sobald Sie alle benötigten Informationen gesammelt haben, können Sie folgendes ausführen:

<pre>
cd <SRC_ROOT>
setenv CVSROOT ":pserver:anoncvs@anoncvs.services.openoffice.org:/cvs"
cvs [optional cvs flags such as -z #] update -dP -r <cwstag> <module1> <module2> <moduleN>
</pre>

Wobei
* SRC_ROOT das Verzeichnis auf der obersten Ebene Ihres Meilenstein-Checkouts ist.
* cwstag die CVS-Markierung (cvs tag) des CWS ist. Die Markierung ist in der Form cws_<main codeline>_<name of cws>, zum Beispiel cws_src680_chart2mst3

Beachten Sie: Falls Sie CVS verwenden, das einen SSH-Tunnel benutzt, verwenden Sie SSH-Kompression eher als CVS-Kompression - dies ergibt bessere Resultate

Zum Beispiel können Sie eingeben:

<pre>
cd src680-m172
setenv CVSROOT ":pserver:anoncvs@anoncvs.services.openoffice.org:/cvs"
cvs -z3 update -dP -r cws_src680_chart2mst3 chart2/ offuh/
</pre>

= Tips and Tricks =

Hier einige Tipps, die Ihnen das Leben leichter machen oder das Erstellen beschleunigen können.

== ccache ==
Falls es möglich ist, ist es stärksten empfohlen, [http://ccache.samba.org/ ccache] zu installieren (und zu konfigurieren) - dies wird die Build-Zeit für anschließende Builds sehr stark reduzieren. Geben Sie die Erlaubnis für einen großen Cache und eine Menge von Dateien für den kompletten OOo-Build-Baum. Falls Sie an mehreren [[CWS]]s gleichzeitig arbeiten, zahlt es sich aus, seperate Cache zu haben wie auch seperate Cache für Nichtproduktive-/Produktiv-Builds innerhalb eines CWS, z.B. führen Sie, nachdem Sie die Umgebung gesourced haben, folgende Kommandos aus:

export CCACHE_DIR="${YOUR_SOURCES}/$CWS_WORK_STAMP/.ccache_$INPATH"
ccache -M 2G -F 100000
export CC="ccache gcc"
export CXX="ccache g++"

in der Bash beziehungsweise in der Tcsh

setenv CCACHE_DIR "${YOUR_SOURCES}/$CWS_WORK_STAMP/.ccache_$INPATH"
ccache -M 2G -F 100000
setenv CC "ccache gcc"
setenv CXX "ccache g++"

Für Windows: Laden Sie von [http://artax.karlin.mff.cuni.cz/~kendy/ccache/ hier] herunter und machen Sie das Folgende:

export CCACHE_DIR="some/place/with/space"
ccache -M 2G -F 10000
export CCACHE_CPP2=TRUE
export CXX="guw.pl ccache cl"
# export USE_PCH= if you experience trouble with precompiled headers

in der Bash beziehungsweise in 4NT:

set CCACHE_DIR="some/place/with/space"
ccache -M 2G -F 10000
set CXX=ccache cl
unset USE_PCH
# if you want to experient with precompiled headers (not recommended):
set CCACHE_CPP2=TRUE and keep USE_PCH=TRUE

Sehen Sie sich auch dies [http://www.nabble.com/ccache-for-MSVC-t4013218.html thread] an als Hintergrundinformation über Windows-CCache-Spezifikationen.

== set nodep=TRUE ==
Falls Sie die Umgebungsvariable nodep auf TRUE setzen, werden keine Dateien mit Informationen zu den Abhängigkeiten erstellt - das Build wird damit schneller fertiggestellt.

Allerdings sollten Sie dies nur in einem sauberen Build aktivieren. Sobald Sie OOo erstellt und danach Veränderungen vorgenommen haben, setzen Sie diese Variable wieder zurück um auf der sicheren Seite zu sein.

== set NO_HIDS=TRUE ==
Ähnlich der Variable nodeps unterdrückt diese das Erstellen von (Hilfe-IDs), die hauptsächlich für das automatische Testen verwendet werden - falls Sie nur OOo erstellen wollen, brauchen Sie diese nicht.

== Verwenden von parallelen Builds ==
Falls Sie eine Mehrprozessormaschine oder etwas ähnliches haben, können Sie parallele Builds starten. Es gibt zwei Ebenen von Parallelisierung - eine, die auf der Ebene des Makefiles arbeitet und eine andere auf Modulebene.

=== set MAXPROCESS=<Anzahl oder Prozesse> ===
Dies ist die Makefile-Parallelisierung. Dies teilt dmake mit, wieviele Vorgaben ihm für das Parallele Erstellen erlaubt sind.

=== starten von parallelen build.pl ===
Für Parallelisierung auf Modulebene müssen Sie build aus dem Verzeichnis <SRC_ROOT>/instsetoo_native starten mit dem Schalter -P<number>, zum Beispiel:
<pre>
build -P2
</pre>

== Erstellen eines prebuilt Mozilla und Verwendung dieses anstelle eines jedesmal neukompilierten ==
Für die Mozilla-Komponenten haben Sie die Möglichkeit, diese entweder aus den Mozillaquellen zu erstellen, vorkompilierte Pakete ([http://tools.openoffice.org/moz_prebuild/680/ die "offiziellen" können Sie von tools.openoffice.org erhalten]) oder das System-Mozilla (dasjenige, das auf Ihrem Buildsystem installiert ist; nicht alles mag funktionieren, abhängig von der Version, die Sie installiert haben) benutzen.
Sie können einfach Ihre eigene Version von vorkonfigurierten Binärdateien erstellen, wenn Sie dies tun wollen (entweder weil Sie die offiziellen nicht benutzen können aufgrund einer nicht passenden Kompilerversion, die zu ihrem Erstellen benutzt wurde, oder aus anderen technischen Gründen oder weil Sie nicht Sachen benutzen wollen, die Sie nicht selbst erstellt haben).
Um dies zu tun,

* erstellen Sie das Modul <code>moz</code> aus den Mozillaquellen (verwenden Sie hierzu <code>--enable-build-mozilla</code>, wenn Sie configure starten und legen Sie den Mozillaquellen-Tarball in das Verzeichnis <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>{unxlngi#,wntmsci#}.pro/zipped</code>

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)

== Sparen von Plattenplatz allein durch das Verknüpfen zum Solver ==
Verwenden Sie "--dlv_switch -link", wenn Sie build starten, um deliver mitzuteilen, dass es die Dateien nur verknüpfen soll, anstatt sie zu kopieren:
<pre>
build --dlv_switch -link
</pre>

== Reparieren des EPM-4-Produktnamenfehlers ==
Falls Sie folgende Fehlermeldung erhalten "epm: Product names can only contain letters and numbers!", müssen Sie epm patchen und die Namensprüfung auskommentieren:
<pre>
/*
* for (i = 0; prodname[i]; i ++)
* if (!isalnum(prodname[i] & 255))
* {
* puts("epm: Product names can only contain letters and numbers!");
* usage();
* }
*/
</pre>

[[Category:Build_System]]

Building de

2008-12-29T04:16:03Z

DavidRoss: added Category:Build_System

[[Category: Development]]
Es gibt zumindest zwei Wege, um OOo zu erstellen (build):
* Up-Stream - benuten Sie einfach die Quellen und das enthaltene Buildsystem direkt (dies wird erklärt in [[Building OpenOffice.org_de]])
* ooo-build - ein System, das den Prozess einkapselt und einige ergänzende Patchsets verwaltet (mehr dazu in [[Erstellen mit ooobuild]])

Es gibt auch einige [[:Category:Distribution-Specific_Build_Instructions | Distributionsspezifische Anleitungen ]].

== Sehen Sie sich auch an ==

* [[Installing]]
* [http://tools.openoffice.org/ tools] Project für Build-Anleitungen für verschiedene Plattformen

[[Category:Build_System]]

Documentation/DevGuide/WritingUNO/C++/Building and Testing C++ Components

2008-12-29T04:15:42Z

DavidRoss: added Category:Build_System

{{Documentation/DevGuide/WritingUNOTOC
|WritingUNO2d=block
|ShowPrevNext=block
|PrevPage=Documentation/DevGuide/WritingUNO/C++/Multiple Components in One Dynamic Link Library
|NextPage=Documentation/DevGuide/WritingUNO/Integrating Components into OpenOffice.org
}}
[[zh:Zh/Documentation/DevGuide/WritingUNO/C++/Building and Testing C++ Components]]
{{DISPLAYTITLE:Building and Testing C++ Components}}
=== Build Process ===

For details about building component code, see the gnu makefile. It uses a number of platform dependent variables used in the SDK that are included from ''<SDK>/settings/settings.mk''. For simplicity, details are omitted here, and the build process is just sketched in eight steps:

# The UNOIDL compiler compiles the ''.idl'' file ''some.idl'' into an urd file.
# The resulting binary ''.urd'' files are merged into a new ''simple_component.rdb''.
# The tool ''xml2cmp'' parses the xml component description ''simple_component.xml'' for types needed for compiling. This file describes the service implementation(s) for deployment, such as the purpose of the implementation(s) and used types. Visit [http://udk.openoffice.org/common/man/module_description.html http://udk.openoffice.org/common/man/module_description.html] for details about the syntax of these XML files.
# The types parsed in step 3 are passed to ''cppumaker'', which generates the appropriate header pairs into the output include directory using ''simple_component.rdb'' and the {{PRODUCTNAME}} type library ''types.rdb'' that is stored in the program directory of your {{PRODUCTNAME}} installation.

{{Documentation/Tip|For your own component you can simplify step 3 and 4, and pass the types used by your component to ''cppumaker'' using the -T option.}}

<ol start=5>
<li>The source files ''service1_impl.cxx'' and ''service2_impl.cxx'' are compiled.</li>
<li>The shared library is linked out of object files, linking dynamically to the UNO base libraries sal, cppu and cppuhelper. The shared library's name is ''libsimple_component.so'' on Unix and ''simple_component.dll'' on Windows.</li>
</ol>

{{Documentation/Caution|In general, the shared library component should limit its exports to only the above mentioned functions (prefixed with <tt>component_</tt>) to avoid symbol clashes on Unix. In addition, for the gnu gcc3 C++ compiler, it is necessary to export the RTTI symbols of exceptions, too.}}

<ol start=7>
<li>The shared library component is registered into ''simple_component.rdb''. This can also be done manually running</li>
</ol>

$ regcomp -register -r simple_component.rdb -c simple_component.dll

=== Test Registration and Use ===

The component's registry ''simple_component.rdb'' has entries for the registered service implementations. If the library is registered successfully, run:

$ regview simple_component.rdb

The result should look similar to the following:

/
/ UCR
/ my_module
/ XSomething

... interface information ...

/ IMPLEMENTATIONS
/ my_module.my_sc_impl.MyService2
/ UNO
/ ACTIVATOR
Value: Type = RG_VALUETYPE_STRING
Size = 34
Data = "com.sun.star.loader.SharedLibrary"

/ SERVICES
/ my_module.MyService2
/ LOCATION
Value: Type = RG_VALUETYPE_STRING
Size = 21
Data = "simple_component.dll"

/ my_module.my_sc_impl.MyService1
/ UNO
/ ACTIVATOR
Value: Type = RG_VALUETYPE_STRING
Size = 34
Data = "com.sun.star.loader.SharedLibrary"

/ SERVICES
/ my_module.MyService1
/ LOCATION
Value: Type = RG_VALUETYPE_STRING
Size = 21
Data = "simple_component.dll"

/ SERVICES
/ my_module.MyService1
Value: Type = RG_VALUETYPE_STRINGLIST
Size = 40
Len = 1
Data = 0 = "my_module.my_sc_impl.MyService1"

/ my_module.MyService2
Value: Type = RG_VALUETYPE_STRINGLIST
Size = 40
Len = 1
Data = 0 = "my_module.my_sc_impl.MyService2"

{{PRODUCTNAME}} recognizes registry files being inserted into the ''unorc'' file (on Unix, ''uno.ini'' on Windows) in the program directory of your {{PRODUCTNAME}} installation. Extend the types and services in that file by ''simple_component.rdb''. The given file has to be an absolute file URL, but if the rdb is copied to the {{PRODUCTNAME}} program directory, a $ORIGIN macro can be used, as shown in the following ''unorc'' file:

[Bootstrap]
UNO_TYPES=$ORIGIN/types.rdb $ORIGIN/simple_component.rdb
UNO_SERVICES=$ORIGIN/services.rdb $ORIGIN/simple_component.rdb

Second, when running {{PRODUCTNAME}}, extend the PATH (Windows) or LD_LIBRARY_PATH (Unix), including the output path of the build, so that the loader finds the component. If the shared library is copied to the program directory or a link is created inside the program directory (Unix only), do not extend the path.

Launching the test component inside a {{PRODUCTNAME}} Basic script is simple to do, as shown in the following code:

Sub Main

REM calling service1 impl
mgr = getProcessServiceManager()
o = mgr.createInstance("my_module.MyService1")
MsgBox o.methodOne("foo")
MsgBox o.dbg_supportedInterfaces

REM calling service2 impl
dim args( 0 )
args( 0 ) = "foo"
o = mgr.createInstanceWithArguments("my_module.MyService2", args())
MsgBox o.methodOne("bar")
MsgBox o.dbg_supportedInterfaces

End Sub

This procedure instantiates the service implementations and performs calls on their interfaces. The return value of the <code>methodOne()</code> call is brought up in message boxes. The Basic object property <code>dbg_supportedInterfaces</code> retrieves its information through the <idl>com.sun.star.lang.XTypeProvider</idl> interfaces of the objects.

{{PDL1}}

[[Category:Documentation/Developer's Guide/Writing UNO Components]]
[[Category:Build_System]]

Quick and Fast Building

2008-12-29T04:15:07Z

DavidRoss: added Category:Build_System

[[Category:Development]]

The ability to provide bug fixes to users/customers in a reasonable short time frame, typically within one week. To get this done, the Sun development process provides the following:

* fast qa access to every release build for bug confirmation

* fast developer access to all supported platforms to be able to debug natively on every platform, thus almost identical development environment on every platform.

* ready to build environment on every platform and easy access to prebuilt/preinstalled enviroment

* fast qa access to every release build for bugfix verification

most of these issues can be mapped to OOo requirements:

* provide access to milestone builds (now already done for some localized versions (fr, de, ja, etc.)

* provide access to main development platform for developers (partly done through tinderboxing, up to the contributor to take care of this)

* access to cws build for verification of bugs (work in progress in the tinderbox environment)

[[Category:Build_System]]

Building cli ure remotely

2008-12-29T04:12:04Z

DavidRoss: added Category:Build_System

==Building cli_ure remotely==

When building cli_ure on a remote machine, that is, the project is accessed through a mapped hard drive (Windows), then one may encounter a messages such as this:

<pre>
..\wntmsci10.pro\bin\climaker.exe \
--out ..\wntmsci10.pro\bin\cli_types.dll \
--keyfile ..\wntmsci10.pro\bin\cliuno.snk \
--assembly-version 1.1.7.0 \
--assembly-description "This assembly contains metadata for the StarOffice/OpenOffice.org API." \
--assembly-company "OpenOffice.org" \
x:\SRC680\wntmsci10.pro\bin.m198\types_doc.rdb

Unhandled Exception: System.Security.Policy.PolicyException: Unverifiable assembly 'X:\SRC680\src.m198\cli_ure\wntmsci10.pro\bin\climaker.exe' failed policy check.
</pre>
The reason is that build tools, such as the climaker.exe, which is a .NET application, reside on a different machine but require access to the local .NET Framework. Therefore the security settings must be adapted to allow the program access to the local machine.

To make security settings one uses .NET Framework x.y Configuration (x.y stands for 1.1, 2.0) etc. The configuration panel can be found in the Administrative Tools. Please note, that the configuration was part of the .NET Framework 1.1 but it is not part of the .NET Framework 2.0. Instead it is contained in the .NET SDK 2.0.

===NFS mounted disk===
Log on as administrator.
Open Control Panel -> Administrative Tools -> Microsoft .NET Framework x.y Configuration.
In the tree view on the left side select " Runtime Security Policies ". Then select "Adjust Zone Security" on the right side. In the dialog that appears select "Make changes to this computer" and press the "Next" button. In the following dialog select the zone "Trusted Sites" and choose the level of trust to "Full Trust" and press the "Next" button. In the following dialog press "Finish".

Log on as normal user and make the same settings for the current user in the .NET Framework x.y Configuration.

Add the machine where the executable is located to the trusted sites:
From the Start menu open
Control Panel -> Internet options -> Security -> Trusted Sites -> Sites
Uncheck "Require server verification ... "
Add the machine where the executable is located, for example \\machine_ooo_build, etc.

===Samba mounted disk===
Log on as administrator and open the .NET Framwork x.y Configuration. In the tree view on the left side select " Runtime Security Policies ". Then select "Adjust Zone Security" on the right side. In the dialog that appears select "Make changes to this computer" and press the "Next" button. In the following dialog select the zone "Local Intranet" and choose the level of trust to "Full Trust" and press the "Next" button. In the following dialog press "Finish".

Log on as normal user and repeat these step but this time select 'Current User'
[[Category:Build_System]]

Buildbot Steps

2008-12-29T04:11:10Z

DavidRoss: added Category:Build_System

Come join the collective! Bots for new platforms or adding bots for for existing platforms will increase the build capabilities available, and are therefore much appreciated.

What you need is a reasonably fast machine, with decent RAM and disk, and of course a stable internet connection. It might be easier to first set up the openoffice build environment on this machine.

Please see http://code.google.com/p/ootermite/wiki/AddNewBuildBot for more information.
[[Category:Build_System]]

Buildbot Development

2008-12-29T04:10:37Z

DavidRoss: added Category:Build_System

Steps to create buildbot development setup.

== Buildbot Requirements ==
The Buildbot requires:
* Python 2.4 or later: http://www.python.org
* Twisted: http://twistedmatrix.com - most recent version is recommended. You'll need at least "Twisted" (the core package), and you'll also want TwistedMail, TwistedWeb, and TwistedWords.
** Note: For Twisted, you first need to install Zope.

== Getting the OpenOffice Buildbot ==
The Buildbot has been customized for Openoffice.org builds. Please checkout buildbot-0.7.3 from [http://cvs.gnome.org/viewcvs/ooo-build/scratch/buildbot/ Gnome CVS].
<pre>
cvs -z3 -d :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome login
no password
cvs -z3 -d :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome co ooo-build/scratch/buildbot/buildbot-0.7.3
</pre>

== Installing the Buildbot ==
* Note:
** Detailed instuctions are at http://buildbot.sourceforge.net/manual-0.7.3.html#Requirements
** The install may need to be to run as root (su).
After all requirements are met, install buildbot by running following commands in buildbot directory.
<pre>
python setup.py build
python setup.py install
</pre>
Test installation is proper by running the command
<pre>"buildbot --version"</pre>
* Install is OK if you see the version information for Buildbot and Twisted.
* Errors such as 'no such command' or "ImportError" means something went wrong.
* Note: For more detailed instuctions see http://buildbot.sourceforge.net/manual-0.7.3.html#Installing-the-code

== Setting up the Buildmaster ==
*Make a buildmaster directory on the machine at an appropriate place.
** The full path name for this directory is hereinafter referred to as ''masterdir''.
<pre>mkdir ''masterdir''</pre>
*Run the buildbot command to create a buildmaster:
<pre>
buildbot master ''masterdir''
</pre>
* For more detailed instuctions see http://buildbot.sourceforge.net/manual-0.7.3.html#Creating-a-buildmaster

*Checkout some OO build specific scripts from http://cvs.gnome.org/viewcvs/ooo-build/scratch/buildbot/master_config_files/
<pre>
cvs -z3 -d :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome login
no password
cvs -z3 -d :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome co ooo-build/scratch/buildbot/master_config_files
</pre>
* You will see the following files:
** master.cfg - sample buildmaster configuration file. You need to edit this as required.
** create_logs.pl - perl script for creating summary logs
** modules - perl modules needed for summary logs
** buildbot.css - cascaded style sheet which handles look and feel of buildmaster status page.
Please copy these files to ''masterdir''

== Setting up the Buildslave ==
If you are setting up buildslave on different machine than buildmaster, then you need to install buildbot on this machine also. So follow the steps given above to install buildbot.
Make a buildslave directory on the machine at an appropriate place.
* The full path name for this directory is hereinafter referred to as ''slavedir''.
<pre>mkdir ''slavedir''</pre>
Run the buildbot command to create a build slave:
<pre>
buildbot slave ''slavedir'' MASTERHOST:9989 ''SLAVENAME'' ''PASSWORD''
</pre>
where,
* BUILDMASTER may be localhost if master and slave are on same machine.
* Choose a ''SLAVENAME'' and ''PASSWORD'' and enter the same in buildmaster's master.cfg file.
* For more detailed instuctions see http://buildbot.sourceforge.net/manual-0.7.3.html#Creating-a-buildslave
* For additional creation options see http://buildbot.sourceforge.net/manual-0.7.3.html#Buildslave-Options

Fill in the hostinfo files
* ''slavedir''/info/admin should contain your name and email address. This is the '''buildslave admin address'''
* ''slavedir''/info/host should be filled with a brief description of the host. For example: OS, version, memory size, CPU speed, versions of relevant libraries installed, and finally the version of the buildbot code which is running on the machine.

Checkout some OO build specific scripts from http://cvs.gnome.org/viewcvs/ooo-build/scratch/buildbot/slave/
<pre>
cvs -z3 -d :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome login
no password
cvs -z3 -d :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome co ooo-build/scratch/buildbot/slave
</pre>
You will see the following files:
* buildbotget.pl - perl script for checking out OO source code from CVS
* buildoo - script to start OO build process. Note: You need to properly edit this file to meet your plateform requirement.
* smoketestoo - script to start OO smoke test after successful compliation. Note: You need to properly edit this file to meet your plateform requirement.
Please copy these files to ''slavedir''

== Edit buildmaster's master.cfg file ==
Please edit master.cfg file as needed.
<pre>
e.g. If you are adding a new slave then you need to modify master.cfg to make following entries
1. Make an entry of slavename and password in c['bots']
2. Create a new scheduler and builder for buildslave
3. Create a buildfactory of steps that buildslave should follow.
4. Add newly created builder and buildfactory to builderlist c['builders'].
</pre>

== Start the buildmaster and buildslave ==
Once buildmaster is configured for new buildslave then you can start buildmaster and buildslave by running following command.
<pre>
buildbot start ''masterdir''
buildbot start ''slavedir''
</pre>
To stop buildmaster/buildslave anytime, please run
<pre>
buildbot stop ''masterdir''
buildbot stop ''slavedir''
</pre>

== Commit your changes ==
If you add any new feature, commit your changes to cvs and notify ooo-staging buildmaster administrator.
[[Category:Build_System]]

Buildd

2008-12-29T04:01:56Z

DavidRoss: added Category:Build_System

A build-daemon/bot/tinderbox is desired that provides the following:
* Abiltity to build CWS/SVN branch on demand
* Ability to generate and make available install sets for multiple platforms
* Ability to run and make reports available of tests, including performance tests

KaiB and Mikeleib are working/soon to be working on this. Volunteers are also welcome.
[[Category:Build_System]]

PL/ooo-build

2008-12-29T04:01:26Z

DavidRoss: added Category:Build_System

* powrót do [[Pl.openoffice.org|Wiki pl.openoffice.org]]
* przejdź do [[PL/spistresci|spisu treści]]
* przejdź do [http://pl.openoffice.org Polskiego Projektu Językowego]
----

Ta kolekcja łatek, grafik i struktury kompilacji istnieje jedynie jako odzwierciedlenie wielu problemów napotykanych w wersji up-stream źródeł. Proces zmian jest bolesny dla każdej organizacji, im większa tym bardziej bolesny. Jednak - rozmiar zmian nie jest żadnym wytłumaczeniem na brak ich wprowadzania, a głównym przeznaczeniem ooo-build jest jego zmniejszanie poprzez wprowadzanie zmian w nim zawartych.

== Na temat ooo-build ==

ooo-build wyrósł na frustracji ze schematu tworzenia OOo zanim został wynaleziona i wprowadzona w życie koncepcja [[PL/CWS|Child Workspace]]. Na jego powstanie ma również wpływ infrastruktura [[PL/Problemy_infrastruktury#CVS|Serwera CVS]].

* [[PL/ooo-build/bin|/ooo-build/bin]] - Opis narzędzi katalogu bin/ w CVS

== przykładowe proste poprawki ==

=== Win32 / configure auto-detection ===

Mamy ładny skrypt perl, 'oowintool', który lepiej sprawuje się w wykrywaniu narzędzi systemowych niż up-stream, powinniśmy zintegrować go tam - to uczyni pracę nad naszą wspólną sprawą dużo prostszą. Porównaj też ostatni punkt.

=== branding / artwork / splash bits ===

Wiele łatek ooo-build to zwykłe grafiki dla różnych dystrybucji. Wprowadzenie tego up-stream wraz z kilkoma 'experymentalnymi' dodatkami uczyniłoby tworzenie ooo-build bezużytecznym dla niektórych. Dobra dokumentacja i <code>--with-splash=/tmp/foo.png --with-logo=/tmp/baa.bmp</code> mogłyby się sprawować świetnie jako dystrybucja.

=== faster 1st time (packagers/developers) build ===

Tworzenie powiązań zajmuje procesorowi ogromną ilość czasu - wykrycie podstawowej kompilacji i eksport 'nodep=1' znacznie skraca cały proces - powinno się to znaleźć up-stream.

=== easier developer experience ===

Prosty, wbudowany, zautomatyzowany system malloc allocator checker (przez linkoo & source ooenv), także - domyślne wyłączenie (strasznie denerwującego) okienka 'recover from crash' przez ten sam patch environment variable patch: i#54275.

== łatki do zrobienia ==

Ponieważ nie ma sensu, żeby tworzyć tutaj (tłumaczyć na język polski) listę poprawek do zrobienia dla ooo-build, która za kilka dni zaowocuje łatkami, najlepiej będzie jeśli chętny programista odwiedzi zawsze aktualny spis tematów w dziale [http://wiki.services.openoffice.org/wiki/Ooo-build ooo-build] po angielsku.

[[Category:Build_System]]
[[Category:Build_System]]

Autopackage distribution

2008-12-29T04:01:02Z

DavidRoss: added Category:Build_System

[[Wikipedia:Autopackage|Autopackage]] is a new package management system intended to be usable across multiple Linux distributions. Unlike traditional package formats such as [[Wikipedia:RPM_Package_Manager|RPM]] and [[Wikipedia:Deb (file_format)|DEB]], autopackage checks for the presence of dependencies ''on the actual system files'', rather than querying a database of package information.

This reduces compatibility issues with different package naming conventions, relaxes package version dependency and allows users to install the application without worrying about what package format is being used on their Linux distributions.

The '''Linux version of OpenOffice.org''' released [http://www.openoffice.org/ by the Offical OOo homepage], as a third-party binary (when viewed from the point of view of Linux vendors) for download with frequent updates, highly matches the software delivery requirement being served and addressed by autopackage.

By providing OpenOffice.org in autopackage format, it will go a long way to simplify the Linux installation process without end users needing to consult [http://documentation.openoffice.org/setup_guide2/index.html the OpenOffice.org 2.x Setup guide] (for setup procedures on various Linux distros out there).

It will also provide the foundation for incremental update mechanism similiar to the auto-updater implemented in Firefox 1.5.

== OpenOffice.org in autopackage format discussion ==

=== Issue reported ===
* [http://qa.openoffice.org/issues/show_bug.cgi?id=46333 Issue 46333]: Native Linux install package using autopackage
* [http://qa.openoffice.org/issues/show_bug.cgi?id=58158 Issue 58158]: Small Patch Update system[http://www.oooforum.org/forum/viewtopic.phtml?p=132194], is now practical to implement under Linux using autopackage

=== Preparation phrase ===

# Find out the dependency information
# Prepare the autopackage script
# Repackage the official binary in autopackage format
# Testing and feedback

Optional (to do later)
* Check the compilation environment
* Compiling a different build if necessary

== Autopackage information for users and developers ==

To see how easy it is to install software in autopackage format, check out this how-to page:
* [http://www.autopackage.org/docs/howto-install/ Install Linux autopackages in 4 easy steps]

=== General information ===

* [http://www.autopackage.org/ Autopackage Official page]
* [http://www.autopackage.org/faq.html Autopackage FAQ]

=== Developer documenation ===

* [http://www.autopackage.org/docs.html Packagers Documentation] With quickstart, tutorials, packager guides, API documentation and many other resources
* [http://www.autopackage.org/download-tools.html Developer Tools]
* [http://plan99.net/autopackage/ Autopackage Wiki]
* [http://planet.autopackage.org/ Planet Autopackge]: Developers' blog

== Related articles ==

* [http://www.osnews.com/story.php?news_id=10155 Autopackage 1.0, the now and the next]
* [http://www.linux.com/article.pl?sid=05/11/22/2021228 Autopackage: Toward a universal package manager for the desktop]
* [http://www.ubuntuforums.org/showthread.php?t=97504 Ubuntu Forum]: 35 pages long (wow!) discussion of the autopackage format and its integration with Ubuntu Dapper Drake

[[Category:User Experience]]
[[Category:Development]]
[[Category:Build_System]]

Compiler versions used by port maintainers and release engineers

2008-12-29T04:00:00Z

DavidRoss: added Category:Build_System

Port maintainers: please state your current compiler needs on this page. This helps us to decide when we are able to deprecate an old version of a compiler without leaving a port behind.

{| border="1" cellspacing="0" cellpadding="5"
! Platform
! Distribution
! Maintainer
! C++/C-Compiler
! Java-Compiler/JRE
! Notes
|-
| Solaris Sparc
| Solaris 8 and newer
| OOo/SO RE (Sun Hamburg) hr@openoffice.org
| Sun Studio 8 / C++-5.5
| build: Sun JDK 1.4.1_03, ship: Sun JRE-1.6u4
| plan to migrate to C++-5.8/SunStudio12 later for OOo-3.0
|-
| Solaris x86
| Solaris 8 and newer
| OOo/SO RE (Sun Hamburg) hr@openoffice.org
| Sun Studio 8 / C++-5.5
| build: Sun JDK 1.4.1_03, ship: Sun JRE-1.6u4
| plan to migrate to C++-5.8/SunStudio11 later for OOo-3.0
|-
| Linux x86
| all distributions with glibc-2.2.4 or newer
| OOo/SO RE (Sun Hamburg) hr@openoffice.org
| GCC 3.4.1 + enum patch + visibility patch
| build: Sun JDK 1.4.1_03, ship: Sun JRE-1.6u4
| plan to migrate to current gcc for OOo-3.0
|-
| Linux x86-64 (OOo-3.x)
| all distributions with glibc-2.3.6 or newer
| OOo/SO RE (Sun Hamburg) hr@openoffice.org
| GCC 4.2.3
| build: Sun JDK 1.5_15, ship: Sun JRE-1.6u4
|
|-
| Linux PowerPC
| Baseline for build : all distributions with glibc-2.3.x or newer
| OOo only (Community builds)
| GCC 4.0.1
|
| Depending on the distributions, some values can change
|-
| GNU/Linux SPARC
| Baseline for build : sparc
| OOo only (Community builds) sparcmoz@openoffice.org
| GCC 4.1.2 preview
| Eclipse Java Compiler v_677_R32x 3.2.1 per Debian java-gcj-compat
| For building vanilla SRC680 sources with gcc4.1, some minor [http://wiki.services.openoffice.org/wiki/GNULinuxSparcPorting#Building_with_GCC_4.1 issues are described here.]
|-
| Mac OS X ( version 2.1 maxi )
| Baseline for build : Mac OS X 10.3 compatibility
| OOo only (Community builds)
| GCC 3.3 (version provided with Mac OS X 10.3 tools)
| build: Apple JDK 1.4
| plan to migrate to gcc-4.0.1 if cross-compiling allows to build from Mac OS X 10.4 for Mac OS X 10.3
|-
| Mac OS X ( 2.2 and later)
| Baseline for build : Mac OS X 10.4 compatibility
| OOo only (Community builds)
| GCC 4.0.x (version provided with XCode 2.4 (and superior)
| build: Apple JDK 1.5
|
|-
| Mac OS X
| Baseline for build : Mac OS X Tiger and later
| OOo/SO RE (Sun Hamburg) obo@openoffice.org
| GCC 4.0.1, Mac SDK 10.4uSDK
| build: Apple JDK 1.5.0_07
|
|-
| Windows
| Windows 2000 - Windows Vista
| OOo/SO RE (Sun Hamburg) obo@openoffice.org
| Microsoft Visual Studio 2008
| build: Sun JDK 1.5.0.06, ship: Sun JRE-1.6u4
| Platform SDK: 2008 Server SDK, 6.0.6001.18000.367-KRMSDK_EN.iso, Date: 06.03.2008
|-
| OS/2
| eComStation
| OOo only (SSI build)
| GCC 3.3.5
|
| no current plans to migrate to a newer version
|-
| FreeBSD
| Baseline for build : FreeBSD 5.3-RELEASE
| maho@openoffice.org
| GCC 3.4.1 + enum patch + visibility patch
| build: unofficially ported SUN JDK 1.4.2
| Usually ports take care of everything we need. A patch for ld.so is needed for prior than 5.2.1. http://porting.openoffice.org/freebsd/
|-
| Linux x86/ppc/ppc64/x86_64/arm-eabi/ia64/s390/s390x/m68k
| Fedora Core 10
| caolanm@redhat.com
| GCC 4.3.2
| eclipse-ecj-3.4.1/gij-4.3.2
|
|-
| Linux x86/ppc/sparc
| Ubuntu 5.10
| doko@ubuntu.com
| GCC 4.0.2
| gcj-4.0.2/gij-4.0.2
|
|-
| Linux x86/ppc/sparc
| Ubuntu 6.06
| doko@ubuntu.com
| GCC 4.0.3
| gcj-4.1.0/gij-4.1.0
|
|-
| Linux mipsel
| Slackware 12.0
| sjanki@openoffice.org
| GCC 4.1.2
| gcj-4.1.2/gij-4.1.2 or jdk 1.5/1.6
|
|}

== See also ==
* [[Using Cpp with the OOo SDK|Using C++ with OOo SDK]]
* Writing a Program to Control OpenOffice.org, by Franco Pingiori — [http://www.linuxjournal.com/article/8550 Part 1] and [http://www.linuxjournal.com/article/8608 Part 2], Linux Journal

[[Category:Development]]
[[Category:Cpp]]
[[Category:Uno]]
[[Category:Porting]]
[[Category:Build_System]]

Extensions development

2008-12-29T03:59:09Z

DavidRoss: added Category:Build_System

{{Extensions}}
Developing extensions is an efficient way to bring value to OpenOffice.org without diving into core sources. Obviously all developers willing to [[Main_Page|develop at OpenOffice.org sources level]] are welcomed.

OpenOffice.org enables third party tools creation through UNO bridges, allowing using many languages.

The principle is to create UNO packages that can be listed in the OpenOffice.org [[Extensions_repository|Extensions repository]] and installed by end-users easily.

This section gives newcomers as well as experienced developers some hints for developing Extensions in various languages and provides tools and frameworks to facilitate that development.

Finally, popular Extensions may be integrated into OpenOffice.org, so it is important to follow common policies from beginning to ease this merging.

==== Starting in a language ====
Addons can be written in various languages. Each section gives starting information to help you create your addon. Each section is dedicated to a language. It deals with specific points concerning the Extensions aspect. Resources regarding the OpenOffice.org API can be found on the [http://api.openoffice.org API project] and the UNO bridge language issues are at [http://udk.openoffice.org UDK project]. The [http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/OpenOffice.org_Developers_Guide OpenOffice.org Developer's Guide] is a valuable source of information as well.

The translations of these pages are welcomed and [[Extensions#Translating_these_pages|guidelines are available]].

* [[Extensions_development_python|Starting in Python]]
* [[Extensions_development_basic|Starting in Basic]] and [[Documentation/BASIC_Guide|Documentation BASIC Guide]]
* [[Extensions_development_java|Starting in Java]]
* [[Uno/Cpp/Tutorials/Introduction_to_Cpp_Uno|Introduction to C++ and UNO]] and [[Using_Cpp_with_the_OOo_SDK|Using C++ with OOoSDK]]
* [[Extensions_development_vfp|Starting in Visual FoxPro (French)]]
* [[Non-code_extensions|Non programmatic Extensions]]
* [[Extensions_packaging|Extensions packaging]]
* [[Extensions_Integration_into_Installation_Set|Extensions Integration into Installation Set]]
* [[Spellchecker_Integration_into_Installation_Set|Adding Spellchecker Extensions into Installation Set]]
* [[Filter_extensions|Import and Export filter extensions using code or xslt]]

==== Articles & Tutorials ====

* [[Framework/Article/Generic_UNO_Interfaces_for_complex_toolbar_controls|Generic UNO Interfaces for complex toolbar controls]]

* [[Framework/Article/Addon_Menu_Toolbar_Merging|Addon Menu Toolbar Merging]]

* [[Framework/Tutorial/Popup_Menu_Controller|Popup Menu Controller]]

* [[Framework/Tutorial/Statusbar_Controller|Statusbar Controller]]

==== Books on OpenOffice.org Basic Programming ====

* [http://www.amazon.com/OpenOffice-org-Macros-Explained-Andrew-Pitonyak/dp/1930919514/ OpenOffice.org Macros Explained] by Andrew Pitonyak
* [http://www.lulu.com/content/2905912 OpenOffice.org Basic Crash Course] by Dmitri Popov
* [http://www.amazon.com/Learn-OpenOffice-org-Spreadsheet-Macro-Programming/dp/1847190979/ Learn OpenOffice.org Spreadsheet Macro Programming] by Mark, Alexander Bain
* [http://www.amazon.de/Makros-OpenOffice-org-2-3-StarBasic-OpenOffice/dp/3836211114/ Makros in OpenOffice.org 2.3] von Thomas Krumbein (in German)
* [http://www.amazon.fr/Programmation-OpenOffice-org-Macros-OOoBasic-API/dp/2212117639/ Programmation OpenOffice.org 2] de Bernard Marcelly, Laurent Godard (in French)

==== Tools & Frameworks ====

* [http://codesnippets.services.openoffice.org Code snippets available in many languages]
* [[API/Samples|Code snippets in the Wiki]]
* [[Extensions_development_translation|Translation framework]]
* [[Extensions_Packager|Extensions Packager]] - BasicAddonBuilder - Extension Compiler
* Predefined wizards
* [[Extensions_introspection|Introspection Tools]]: discover the API
* [[OpenOffice_Eclipse_Integration|OpenOffice.org Eclipse Integration]] - OpenOffice.org development with Eclipse
* [[OpenOffice_NetBeans_Integration|OpenOffice.org NetBeans Integration]] - plug-in for NetBeans providing some nice features to simplify the development with and for OpenOffice.org (highlevel wizards, UNOIDL and xcu syntax highlighting, code completion, integrated API reference, ...)
* [[Extension_Development_with_IntelliJ_IDEA|Extension Development with IntelliJ IDEA]]: simple introduction how you can use the IntelliJ IDEA to develop OpenOffice.org extensions.
* [[OpenOffice_Maven2_Integration|OpenOffice.org Maven 2 integration]] - Maven plugin to build OpenOffice.org extensions.

==== Best Practices ====
* [[Extensions_best_practices|How to write OO.o GUI Extensions today]]

==== Project: Enhancing the Extensions Infrastructure of OpenOffice.org ====
* [[Extensions_improvements_proposal|Project Proposal (agreed by the Community June 2006)]]
* [[Extensions_improvements_plan_and_status|Project Status]]

==== Improving the Extension Manager ====
* [[Extensions_feature_ideas|Feature ideas]]
[[Category:Extensions]]
[[Category:Build_System]]

Termite

2008-12-29T03:56:59Z

DavidRoss: added Category:Build_System

http://code.google.com/p/ootermite/ is the new project pages for this page.

[[Category:Build_System]]

Buildbot

2008-12-29T03:56:37Z

DavidRoss: added Category:Build_System

A buildbot is now deployed for OpenOffice.org.
'''http://buildbot.go-oo.org/'''

From the Buildbot README: http://buildbot.sourceforge.net/

This project has now moved to google code http://code.google.com/p/ootermite/

The BuildBot is a system to automate the compile/test cycle required by most software projects to validate code changes. By automatically rebuilding and testing the tree each time something has changed, build problems are pinpointed quickly, before other developers are inconvenienced by the failure. The guilty developer can be identified and harassed without human intervention. By running the builds on a variety of platforms, developers who do not have the facilities to test their changes everywhere before checkin will at least know shortly afterwards whether they have broken the build or not. Warning counts, lint checks, image size, compile time, and other build parameters can be tracked over time, are more visible, and are therefore easier to improve.

== How to start a build ==

* Visit http://buildbot.go-oo.org/buildbot/
* Choose a machine you want to build on, and click on it
* Fill in the ''Your name'', ''Reason for build'', ''Branch to build'' (just the CWS name)
* If you want to have the resulting installation sets, check ''Install Set''
* Press ''Force Build''
* Wait until the installation sets appear in http://buildbot.go-oo.org/install_sets/ (if you wanted them)

If your build breaks it ''may'' be the Buildbot's fault as they are not perfect. If you are unsure feel free to contact the Buildslave's maintainer (contact address on the Builder's overview page).

[[Category:Build_System]]

Tinderbox

2008-12-29T03:55:00Z

DavidRoss: added Category:Build_System

[[Category:Tinderbox]]
''Welcome to the OpenOffice.org Tinderbox page!''

This Tinderbox Wiki page is designed to be used to inform about the OpenOffice.org tinderbox and coordinate ideas and resources about the further development of the tinderbox. See also: [[Buildbot]] and the successor called [[Termite]].

A Wiki is a type of website that anybody can edit but radical changes should be discussed on the tinderbox mailing list first.

= What is a Tinderbox =

A tinderbox allows developers to test their [[CWS]]s (Childworkspaces) on several architectures without the need of having access to all those architectures.

Setting up tinderbox builds with the standard toolchain and maybe the newest toolchain for all of the main platforms (x86 Linux, Solaris Sparc, and Windows) and allowing volunteer developers to see the build error logs and progress will finally make developers less afraid to commit anything (fixes or advancements) for fear of breaking something for other platforms.

In essence a tinderbox is a perl script that processes mail, and turns it into HTML. It expects to be mailed build logs from separate and de-coupled build machines. Tinderbox has a few elaborations over the most simple 'status' web-page, inasmuch that it integrates with bonsai - to correlate builds against commits, and it has some nice built in error-parsers to allow huge build logs to be condensed to just a few (possible) tricky sections.

Our tinderbox uses the [http://www.mozilla.org/tinderbox.html Tinderbox 2] from the mozilla project plus some small cosmetic changes. Additional documentation can be found there.

= Last Tinderbox results =
Click the [http://go-ooo.org/tinderbox/all_trees.express.html result overview] link to get the latest build results, or check the [http://go-oo.org/tinderbox/ tinderbox] link to get a list of the currently open tinderbox trees (CWSs and MWSs).

= Tinderbox integration into EIS =
The [[TinderboxAndEISStatus]] page explains the technical details of Tinderbox integration into [[EIS]]. A page explaining how to act on [[CWS]]s with red tinderbox status is currently being worked on ([[RedTinderboxStatusInEIS]]).

= Set up a Tinderbox client =
Follow the [[Tinderbox_Setup]] link to get information how to set up a tinderbox client.

== Expected (New) Tinderbox Clients ==
* Windows - Volker
* Suse 10 - Tor
* Red Hat - Fridrich
* Debian - OSUOSL/
* OpenSuse - OSUOSL/

= Tinderbox mailing list =

Topics related to the tinderbox should be discussed on the tinderbox@tools.openoffice.org [http://tools.openoffice.org/servlets/SummarizeList?listName=tinderbox mailing list] (Send a completely blank e-mail to tinderbox-subscribe@tools.openoffice.org address to subscribe).

= OpenOffice Tinderbox ToDo list =

* Improve this page
* Create <code>tools.openoffice.org/tinderbox.html</code> linking to this page
* Discuss/create [[buildd|framework]] to allow developers to request tinderbox builds for their CWSs
* Advertise the tinderbox and attract more tinderbox clients
* Define specifications which <code>configure</code> parameters have to be used, which languages should be enabled, etc.
* Provide a means to upload installation sets from a tinderbox build to a place that allows QA of these builds. See [http://qa.openoffice.org/issues/show_bug.cgi?id=38096 issue 38096].

[[Category:Build_System]]

JavaEclipseTuto

2008-12-29T03:51:35Z

DavidRoss: added Category:Build_System

=How to create a Java component with Eclipse=

==Introduction==
This paper is a tutorial to guide UNO newcomers through creating their first Java component. This tutorial will use Eclipse and its plugin for the OpenOffice.org development, and every step will be detailed. If you are an experienced UNO programmer, you can still follow this tutorial to have a better view of how to use the Eclipse plugin.

===UNO Components===
This section will explain some very basic things about UNO components. You can skip it if you already know it. First I will explain what a component is and its main parts. Afterwards, I will explain what is needed to create a UNO component to help you to fully understand the different tools and their use during the tutorial.

====Components anatomy====
''"A component is a system element offering a predefined service and able to communicate with other components"'' explains [http://fr.wikipedia.org/wiki/composant Wikipedia (Fr)] (Even thought there is a definition on the English wikipedia article, I prefer the French one because of its completeness). In UNOs case a component will generally be delivered as a package containing a library (share library in C++ or jar in Java). For UNO, a component is made of two distinct parts: specifications and an implementation.

*'''Specification: '''definition in a common language of what the component should do. For UNO, this language is called UNO-IDL and is more or less similar to [http://en.wikipedia.org/wiki/Corba Corba] IDL. The documented part that will be provided as an API to use the component is the specification. Thus, it should be complete and implementation independent.
*'''Implementation: '''is the code that will realize what is described in the component specifications. This programming language can either be C++, Java, Python or others. This is the internal part of the component and will not be accessible from another component.
In order that UNO knows which implementation corresponds to which specification, the component will use registries. There are two of them: the first one describes all the component specifications (<tt>types.rdb</tt>) and the second translates the implementation into specifications (<tt>services.rdb</tt>) and is generated from the implementation.

====Components creation process====
The following diagram will help you better understand what should be done to get a component from its specification and sources. As shown by the diagram, the specifications are compiled and merged into one <tt>types.rdb</tt> registry. <tt>Class</tt> files are generated from that file to translate the specifications into a Java class definition file which is built with the implementation into a class using the <tt>java</tt> compiler. All the classes are delivered as a <tt>jar</tt> file with a specific manifest as we will see further in this tutorial. This doesn't make a usable OpenOffice.org: the <tt>types.rdb</tt> and <tt>jar</tt> file will have to be zipped into a <tt>.uno.pkg</tt> file described with another manifest.

[[Image:CompilationChain.png|center|UNO component build chain]]

As I will explain later, the Eclipse plugin will hide some of these operations, however you will need to know how they work to fully understand the build process and what we will do in the following steps.

===Installing the development platform===
Now that you know what to do, we will install and configure the development tools. This is quite simple, but you can run into some problems if you do not read the following information carefully. I will now assume that you have none of the development tools. The minimum requirements for OpenOffice.org Eclipse integration are:

*OpenOffice.org 2.0
*OpenOffice.org SDK 2.0.4
*Eclipse 3.2
*Java 1.5 (the GNU Java does not work with the Eclipse integration)

====OpenOffice.org====
First of all, you will need to have a working OpenOffice.org 2.0 and its Software Development Kit (SDK). The latest versions are available on the [http://download.openoffice.org/ OpenOffice.org download pages] for the most current platforms. The OpenOffice.org SDK version 2.0.4 is mandatory to use the plugin correctly. It includes a new tool used by the plugin: the <tt>uno-skeletonmaker</tt>. This tool will generate the implementation skeleton to help you to concentrate only on your code.

'''This tutorial assumes that you used the "Official" OpenOffice.org distribution''' from the project's website. Other distributions may not work with the Eclipse integration (see the trouble shooting section at the end of this page).

====Eclipse and the plugin====
To get Eclipse, just go to their download pages and download the latest Eclipse SDK. You will have Eclipse and its SDK. Of course, you might want to download only the binary runtime, but you will have to follow more links. Once you have Eclipse, unzip it on your computer and that's it: Eclipse has a Java plugin to help you program in Java.

Now we will install the OpenOffice.org development plugin for Eclipse using the Eclipse software update system. '''Do not try to download an archive from somewhere. Eclipse will do it for you when you do the following steps.''' Select the '''Help > Software updates > Find and install''' menu to get the window shown in the following illustration. Check the second option on this window and click on the '''Next''' button.

[[Image:InstallWindow.png|center|"Find & Install" window]]

On the following page, you will see a list of "''update sites''". These are URLs pointing to directories containing plugins informations and archives. Now click on the '''Add remote site''' button to get a small window asking for a name that will be displayed in the list and an URL. The URL of OpenOffice.org plugin update site is http://cedric.bosdonnat.free.fr/ooeclipseintegration.

'''Do not try to download an archive from this URL. This is the plugin update site for Eclipse.'''

You can also download the source code and build your own update site using ant and the contained ant build files.
The source code can be downloaded from the CVS repository: http://api.openoffice.org/source/browse/api/ooeclipseintegration/

Validate the new update site parameters and be sure that the OpenOffice.org site is checked before clicking on the '''Finish''' button. You should now see a window like the one in the following illustration. '''Select the OpenOffice.org plugin Core and Java plugins''', click Next and let the wizard guide you through the end of the process. You will be asked to accept the plugin license and validate the installation archives which are not signed.

[[Image:PluginUpdates.png|center|OpenOffice.org update site contents]]

Congratulations, you have installed the OpenOffice.org plugin successfully. Now you must configure it. The following steps will guide you through this task. Go to the Eclipse options via the '''Window > Preferences...''' menu. In the list on the left, select the '''OpenOffice.org plugin > SDK Configuration''' item to get a window like the one shown in the following illustration.

[[Image:UnoProperties.png|center|SDK configuration window]]

In this window you will have to configure the path to your OpenOffice.org and to its SDK. So, let us begin with the SDK path: click on the '''Add''' button next to the SDKs list. You will have a window like the one shown in following illustration. Browse to your OpenOffice.org 2.0 SDK and validate. Then you will have to do the same for the OpenOffice.org path using the other '''Add''' button.

Note that a URE installation can be selected instead of a complete OpenOffice.org installation. Please refer to the Java URE application tutorial for more details on the plugin's URE support.

'''If you are using Windows, please make sure that the path to the SDK does not contains any spaces. Spaces in the path can cause problems when you build your UNO projects.'''

[[Image:SdkConfig.png|center|New SDK path window]]

Now your OpenOffice.org plugin is ready to work. You can begin to create your new component. If there was any problem during the plugin installation, please report it to the dev@api.openoffice.org [http://api.openoffice.org/servlets/ProjectMailingListList mailing-list].

==Creating a new component==
For the Eclipse plugin, a UNO component is a UNO project. This tutorial will explain how to easily create a new UNO component using the Eclipse plugin. We will now assume that you have very simple needs. The component that will be created is a "Hello world" service and its implementation. Creating a component that defines and implements more services is a bit more complex and requires advanced Java UNO knowledge.

'''Note: The plugin needs to open a connection to Open Office in order for it to obtain lists of components. The plugin will try to bootstrap OO if it is not running. If it fails, starting Open Office after running the wizard will not succeed. You will have to restart the wizard.'''

There are several ways to create a UNO component project using the plugin:

*The first one is the '''File > New > Project''' menu entry and choose the '''UNO > UNO-IDL Project''' item as shown by the following illustration.

[[Image:NewUnoProjectsItems.png|center|New UNO-IDL project item]]

*The second one is the icon in the toolbar representing a blue folder with a star as shown by the following illustration.

[[Image:NewUnoProjectIcon.png|center|New UNO-IDL project icon]]

Then you only have to follow the wizard to create your UNO component project, its specification and a skeleton of the implementation. This wizard is composed of several pages:

*The main configuration page to define the general project properties.
*The implementation language configuration page.
*The service configuration page.
*The interface configuration page.
After all these steps you will have a running component... doing nothing. The following sections will describe the different wizard pages and where to place your code.

===The project configuration page===
The first page in the project wizard is the only page containing fields that must be filled in. All the others have default values to help you through the component creation. In our case, we will cover all the pages in the wizard to explain them all and define some new methods and attributes in our component.

[[Image:NewUnoProject.jpg|center|New UNO-IDL project wizard page]]

*'''Project name:''' is the component name, in our case, it will be "''Helloworld''"
*'''Location:''' is the directory on your computer where the project will be created. You can change the default one by deselecting the '''Use default''' check box. The default location of each Eclipse project is a directory with your project name in the current Eclipse workspace. '''Please do not use spaces in this path on Windows. Spaces in the path can prevent your component from being built.'''
*'''Root package:''' is the name of the first module of your component. It is generally composed of two parts: the vendor name (here <tt>org.openoffice</tt>) and the project name (here <tt>helloworld</tt>).
*'''Used SDK:''' selects the OpenOffice.org SDK which will be used to develop the component. You generally will have only one SDK in the list, but you can add others in the preferences or by clicking on the '''Configure SDKs''' button.
*'''Used OOo:''' selects the version of OpenOffice.org to use to develop the component. Just as with the SDK, you will generally have only one entry in the list, but you can add others in the preferences or by clicking on the OOo Installations button.
*'''Programming language:''' selects the programming language for the component implementation. For the moment, there is only Java available, however C++ and python are planned.

===The implementation language configuration page===
This page depends on the chosen language. For Java, the default values should be kept: they define which class is the main class of the component. The component's main class contains some code mapping the services to their implementation.

===The service configuration page===

[[Image:Eclipse_Service_Page.png|center|Service configuration page]]

*'''Module:''' corresponds to the UNO-IDL module where to add the interface. If the text field is left empty, the interface will be added in the root module of the component (filled in the project wizard).
*'''Service name:''' is the service name. By keeping the default value, you will be able to define your own interface using the interface configuration page. Otherwise, you can reuse an existing interface.
*'''Published''': specifies if the interface is published or not. The published notion is translated into a keyword in UNO-IDL language. Declaring a UNO-IDL type as published means that it will not change in future releases. We will keep it unchecked because our component is really far from being a stable API.

===The interface configuration page===

[[Image:NewInterfacePage.png|center|Interface configuration page]]

*'''Module:''' corresponds to the UNO-IDL module where the interface is added. If the text field is left empty, the interface will be added in the root module of the component (filled in the project wizard).
*'''Interface name:''' is the interface name. By convention, we generally name an interface beginning with an "X". In this tutorial, the interface will be named <tt>XHelloworld</tt>.
*'''Inherited interfaces:''' is a list of all the interfaces from which the one that is about to be created will inherit. This is one of the changes in UNO-IDL between OpenOffice.org 1.1.x and 2.0, and why the plugin does not support OpenOffice.org versions prior to 2.0. All the UNO-IDL interfaces are inheriting more or less directly from the <tt>com::sun::star::uno::XInterface</tt> type. As the <tt>XHelloworld</tt> interface is very easy, no super interface will be added. This will implicitly define <tt>XInterface</tt> as the only parent for the new interface.
**'''"?" column:''' specifies if the interface inheritance is mandatory or not. If the box is checked, the interface inheritance is optional and may not be implemented.
**'''"Add" and "Del" buttons:''' allows you to add an interface to the inherited ones or remove the selected interface. Iff a connection to OpenOffice (already running or bootstrapped by the plugin) was succesfully made, you will see: [[Image:UNO_Types_Selector.PNG|center|UNO Types Selector option sheet]]It may take up to a minute to appear depending on your machine.
*'''Members:''' is a list of all the methods and properties of the interface. See below for explanations about the members. In this tutorial, just create one <tt>string sayHello([in] boolean isBadBoy)</tt> method and a <tt>LadyName</tt> property.
*'''Published:''' specifies if the interface is published or not. The published notion is translated into a keyword in UNO-IDL language. Declaring a UNO-IDL type as published means that it will not change in future releases. We will keep it unchecked because our component is really far from being a stable API.
A UNO interface can contain two kind of members: methods and properties. When clicking on the '''Add''' button near the members' list, the following window will be shown. When double-clicking on a line in the members' list, you will edit the corresponding member through the same window.

When the window is opened to create a new member, you can choose whether the member will be a property or a method. The name and returned type fields are always present, but the lower part of the dialog is different for a method and a property.

[[Image:Eclipse_Interface_Members_Dialog.png|center|Interface member creation dialog]]

*'''The arguments list:''' defines the name, type and direction of the parameters of the method. Simply click on the cell to edit it.
*'''Read-only and Bound check boxes:''' selecting these boxes sets the corresponding IDL flag on the property.

'''Tip:''' you can use ''<tt>''Ctrl+Space''</tt>'' to complete the type name in the '''Return type''' field and '''Type''' column.

===Writing the implementation===
After having completed the wizard, you need to write the component implementation. Hopefully a skeleton has been generated and opened. You need to complete the code where there are some TODOS. The generated project contains the following directories and files:

*'''source:''' directory containing your Java implementation classes.
*'''build:''' directory containing all the generated temporary files, such as the results of the specification files (<tt>.idl</tt> files) compilation (<tt>.urd</tt> files) or the class files corresponding to the specifications (<tt>.class</tt> files).
*'''idl:''' directory containing the specifications of the component.
*'''types.rdb:''' generated UNO types registry from which the classes files will be generated.
*'''JRE and the jars:''' describe the classpath of the component. They are visible only in the Java package explorer. The OpenOffice.org jars are changed if the OpenOffice.org version associated to the project is changed. ''In a future version, they will be packed in a user library to take less space in the tree.''
The generated skeleton already contains the methods for the implementation registration. The only things to modify are:

*Change the code of the setters and getters for the defined properties.
*Change the code of the defined methods.
The Eclipse integration even manages the libraries needed by your implementation. Let us imagine that we want to use the <tt>Fraction</tt> class from the Apache <tt>common-math</tt> jar. Download this jar from the Apache website, and import the <tt>common-math-1.1.jar</tt> file into your component project, for example in a <tt>lib</tt> directory. Add the jar to the project build path in the same way than in any other Eclipse Java project and use it:

<source lang="java">
// org.openoffice.helloworld.XHelloworld:
private String mLadyName = "";

public String getLadyName()
{
return mLadyName;
}

public void setLadyName(String the_value)
{
mLadyName = the_value;
}

public String sayHello(boolean isBadBoy)
{
String hello = "Hello Mrs. " + getLadyName();
if (isBadBoy) {
Fraction f = new Fraction(1, 3);
hello = "A third is " + f.doubleValue();
}
return hello;
}
</source>
The above code shows you what could be an implementation of our component. Now, there is only to package it properly and test it.

==Packaging and testing the component==
Now we will show you how to export your component into an OpenOffice.org package. There is little to do apart from following these steps:

*Select the '''File > Export''' menu. Then choose the '''UNO > OpenOffice.org''' package export type.
*The next page of the wizard asks for the UNO project to export (already selected), the directory where to export the package and the OpenOffice.org minimum compatibility version for the package. Depending of the selected OpenOffice.org version, the package will get a different name and a different structure.
*Click on the Finish button. The wizard will ask you whether to deploy to package or not and asks for the old package removal if needed.
Then we will suppose that the package is deployed on the OpenOffice.org installation and we will test it using the following <tt>OooBasic</tt> macro.

<source lang="oobas">
Sub testHelloworld
oHelloworld = createUnoService( "org.openoffice.helloworld.Helloworld" )
oHelloworld.LadyName = "Robinson"
print oHelloworld.sayHello( false )
print oHelloworld.sayHello( True )
End Sub
</source>

This macro should open two message windows with ''"Hello Mrs. Robinson"'' and ''"A third is 0.3333333"''. Your first UNO component is now running, enjoy doing others.

==Going further==
This chapter is only for those who enjoyed this tutorial and want to know more about the UNO component creation in Java or other languages. The following is a list of useful links for any UNO developer:

*[http://api.openoffice.org/docs/DevelopersGuide/DevelopersGuide.xhtml OpenOffice.org developer's guide] is a huge source of documentation for any OpenOffice.org developer. You should probably have a look at chapters 3 and 4 for UNO component information.
*[http://api.openoffice.org/docs/java/ref/overview-summary.html OOo Java reference] is the UNO binding for Java reference.
*[http://api.openoffice.org/docs/cpp/ref/names/index.html OOo C++ reference] is the UNO binding for C++ reference.
*[http://wiki.services.openoffice.org/ OOo Developer's Wiki] is the wiki for all the OpenOffice.org developers. It contains useful information even for people who are just starting out with UNO.
*[http://udk.openoffice.org/common/man/draft/multinherit.html http://udk.openoffice.org/common/man/draft/multinherit.html] for further information on what changes have been made in UNO-IDL between OpenOffice.org 1.1.x and 2.0
*[http://tools.openoffice.org/autodoc/HowToWriteDocumentation-Cpp.html Autodoc Java reference] is the reference for <tt>javadoc</tt> like comments in UNO-IDL files.
*[http://tools.openoffice.org/autodoc/HowToWriteDocumentation-Cpp.html Autodoc C++ documentation] is the reference for <tt>javadoc</tt> like comments in C++ components.
*[http://cedric.bosdonnat.free.fr/wordpress/?p=19 URE C++ application tutorial] explains how to create a C++ application based on the URE, that is a UNO C++ component that does not need OpenOffice.org.

==Trouble shooting==
* If you run into trouble it might be helpful to turn the log level to debug mode. This can be done inside Eclipse via Window > Preferences > OpenOffice.org Integration. The log file can be found in ''$YOURWORKSPACEPATH/.metadata/.log'' .
* If you run into trouble at deployment, make shure that no OpenOffice process is running
* If redeployment does not work, because the previously installed plugin can not be deleted, use <OpenOffice Installation>\program\unopkg to delete it manually
* If you plan to use the OpenOffice version that comes with your distribution try using the according SDK (in Ubuntu it is the package openoffice.org-dev). If there is no such package and you run into trouble not getting the skeletons and opening of an external editor you probably have to create a symbolic link to ''/usr/lib/libstlport_gcc.so'' from the official version of libstlport_gcc.so extracted from an official download of OOo.
* On Unix running ''setsdkenv_unix'' in your SDK directory might helpful as well.

[[Category:Eclipse]]
[[Category:Development]]
[[Category:Tutorial]]
[[Category:Java]]
[[Category:Uno]]
[[Category:Build_System]]

Prj

2008-12-29T03:38:54Z

DavidRoss:

does contain build.lst and d.lst
build.lst give us dependencies : probably a lot for vcl, build 98th module over ~148. Everything graphical depends in vcl.
qa : does contain all quality assurancy stuff
source : the most important :-)
Depending on the OS and the architecture, binaries are built or not.

Prj

2008-12-29T03:35:00Z

DavidRoss: Category:Orphan

Modularization

2008-12-29T03:32:31Z

DavidRoss: added Category:Build_System

== OpenOffice.org Modularization ==

Often the question arises why is OpenOffice.org not more modular. There are several aspects of modularization:

== Views on Modularization ==

=== User View ===

From the user point of view there are several modules:
* Word Processor
* Spreadsheet Module
* Impress Module
* Database Module
* Core Modules
* Desktop Integration
* Filter Modules
and many more.

=== Architectural View ===

The [http://www.openoffice.org/white_papers/tech_overview/tech_overview.html#27 Architectural OverView] shows a very stripped down overview. In reality we will find up to 20 layers below an Application module. All code which can be shared among the Application modules has been moved to core modules. Examples for such layers are
* System Abstraction Layer
* Infrastructure Layer
* Framework Layer
These layers themselves can contain some layers again, helper and wrapper layer and so on.

=== Source Code ===
The Source Code itself is group im more than 150 modules, each of these can be build in one pass.

Each compilation unit and each C++ class also can be viewed as a module.

=== Libraries ===

Often libraries are build on per (source code/CVS) module basis, sometimes several libraries are built in one CVS module. Attention: at many places the runtime dependencies of the library modules differs from the build sequence of CVS modules.

== Goals of Modularization ==
When viewing the list of problems, one can see some terms repeated often. In reverse, those lead to some goals (items are not necessarily distinct):

* Reducing dependencies
** implementation dependencies (improve maintainability, testability, correctness)
** build time dependencies (reduce build effort, also accelerate development)
** run time dependencies (improve runtime efficiency)
* Maintainability
** clear points of responsibility - one piece of code for each task
** changes have less risk, because they most times only affect a clearly separated amount of code
** code is easier to understand, if module's tasks and interfaces are clearly defined
* Testability
** modules can be tested in isolation
* Runtime efficiency
** only needed modules are loaded, leading to less memory usage and faster startup
* Correctness
** less regression, because changes have fewer side effects
** better tests, because tests can concentrate on sharply separated units

== Principles of Modularization ==
How does one recognize a module? What is a "good" module?
* encapsulation
* unambiguously defined, consistent and minimal interfaces
* dependencies always shall have tree-shape, no circles (small dependency circles up to about 5 compilation units or 2 larger modules may be necessary sometimes)

== Review of the Current Structure ==

=== Possibilities ===
The current structure does not only have problems, but also provides some possibilities on which further modularization might build up.

* The system abstraction layer provides a lot of independence from platforms and enables, though OpenOffice.org is a huge project, relatively easy portability.
* UNO allows to write components which enforce modularization, because they are only accessible via well defined interfaces.

=== General Problems ===
''List problems here, if they occur at many places or are of principal nature.''

* Selective Installation of Application modules doesn't save disk space for the User.
* Amount of modules and their dependencies is impossible to overview for Developers, this leads to
** maintainability problems
** code complexity
** long build times
* Architectural/source code modules are not clearly separated from each other by interfaces. Instead clients depend on implementation details of the module. Often it is not really defined what shall be interface and what was meant as implementation only. Consequences:
** complexity - as it is unclear which functions of a module are for public use and which are not
** avoidable build time - as dependant source code needs to be rebuild, when implementation details of a module are changed
** maintainability problems - because when changing implementation details of a module, it is unclear which client code will be influenced and how.
* There is a lot of duplicate code for the same tasks in parallel use cases. This leads to problems with
** performance - because of increased code size in memory
** maintainability - because to change one feature, it is often necessary to change a lot of different locations in code; sometimes even nobody knows which all those locations would be
* Large circular dependencies among compilation units. There are several cases where one or a few hundred compilation units are circular dependent on each other. This means:
** testing problems - none of them can be tested in isolation, unit tests are nearly impossible
** maintainability problems - lots of regression, because a change in one of those files may cause side effects in a few hundred others

=== Specific Suggestions for Improvement ===
''List suggestions here, if they are already related to concrete locations in the code or specific architectural concepts.''

[[Category:Build_System]]

BuildSpeedup

2008-12-29T03:30:15Z

DavidRoss: added Category:Build_System

Make the OO.o build system the coolest on the planet! OpenOffice.org is one of the largest and most interesting open source projects that exists. The target of the BuildSpeedup project is to make the build system the coolest one around. A reliable and fast build system has several direct and indirect impacts, maybe most importantly it is the first thing a new contributor comes across when they pick up the project. Main main target audience is an contributor running a high-mid level desktop. Secondary target is people running build farms (notably Sun). Specification for Jam build prototype [[SpecJamBuild]].

* Simple test harness to figure out the speed of different build tools: [http://wiki.services.openoffice.org/mwiki/images/1/11/Buildtest.tgz Buildtest.tgz]
* Paper on prototype for setting up and building OO.o on large compilation cluster: [http://wiki.services.openoffice.org/wiki/Image:Build_j50.tgz Build_j50.tgz]

== How to report build profile logs ==

Thank you for sending in a build profile log. The more logs we have, the easier it is to focus our effort correctly. Here are the steps to producing a build log:

# Apply the latest patch from {{Bug|60948}} to your source tree
# in the dmake directory type "make clean; make". In the root directory type "./bootstrap"
# When building redirect stderr and stdout to the logfile. In tcsh "build --all |& tee myconfigdesc_build.log" will do the trick. You can alternatively use cat instead of tee to speed up the build slightly. You need to build in a single go and in a single process (no parallel building)
# Check that the log contains markers like "s target 1234 foo.obj". If not, then report
# Compress the log with zip/gz
# When you send in your log URL to mailto:kaib@openoffice.org please provide a short description of the build type:
#* Important configure options (like --with-lang=?)
#* OS/compiler/generic hardware description
#* No-change, partial or full build (we are especially looking for full builds)
#* External accelerators like [[wikipedia:ccache|ccache]]

Thank you again for contributing! --[[User:KaiB|KaiB]] 16:25, 25 January 2006 (CET)

== Profile results ==

Here are some initial profile results. These were done on a HP development desktop with 4GB of RAM. Due to various reasons there is a margin of error in all results, but the largest culprits are pretty clear.

=== Full rebuild from scratch ===

{| border="1" cellspacing="0" cellpadding="5" align="center"
|-
! Time spent
! Target type (file extension)
|-
| 33.2%
| C/C++ compilation (obj)
|-
| 27%
| dmake/build.pl (time not attributed to any target)
|-
| 22.0%
| Dependency generation (dpcc)
|-
| 3.7%
| SDK installer (sdkoo_en-US)
|-
| 1.3%
| Unknown, build related (last_target)
|-
| 1.2%
| Linking (dll)
|-
| 1.1%
| OpenOffice.org installer (openoffice_en-US)
|}

Running time: 62296 s targets: 45927 s 73%

As a benchmark, a Mozilla Firefox build corrected for differences in source code size takes about 25% of the OO.o build time.

=== Nothing changed rebuild ===

Basically profiling the build in a non-changed source tree.

{| border="1" cellspacing="0" cellpadding="5" align="center"
|-
! Time spent
! Target type (file extension)
|-
| 54.8%
| SDK installer (sdkoo_en-US)
|-
| 19%
| dmake/build.pl (time not attributed to any target)
|-
| 16.2%
| OpenOffice installer (openoffice_en-US)
|}

Running time: 4209 s targets: 3431 s 81%

== Notes ==

This is a workarea for ideas and notes regarding the speeding up of the build process. --[[User:KaiB|KaiB]] 12:50, 16 January 2006 (CET)

Notes:
* Newest dmake version: cws_src680_dmake43p01)
* solenv/inc define global targets
* potential modules: KaiB: transex3, tools, svx, binfilter - small to huge :)
* helpcontent2 --with-lang=ALL (there are open issues on this already)
* batched compiles
* Interix instead of cygwin
* dependency generation

Existing possibly useful Build Speed related tweaks:
* export nodep=true
* export NO_HIDS=true
* build.pl -P parallel flag
* dmake -P parallel flag and/or MAXPROCESS (cws_src680_dmake43p01 has fixes for some problems there)
* dmake -s flag for less verbose output
* for gcj users targetedaot workspace to ahead of time compile (only) HelpLinker and FCFGMerge java build tools

=== transex3 ===

Started by tackling this small module. Initial full compile time was 137 sec.

== build_profile_analyzer.py ==

(NB. Move this to an attachment once the Wiki accepts .py files)

# Copyright 2006 Google Inc.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

# OO.o build profile analyzer. To get the required patches look at:
# http://wiki.services.openoffice.org/wiki/BuildSpeedup
# Author: Kai Backman, kaib@google.com

import os
import re
import sys

def SortProfileTimes(lhs, rhs):
if lhs[1] < rhs[1] : return 1
elif rhs[1] < lhs[1] : return -1
else : return 0

def ProcessLogFile(file_name, target_durations):
# print "Processing file: " + file_name
file = open(file_name)
start_time = 0
end_time = 0

target_start = 0
target_name = ""
line = file.readline()
while line != "" :
tokens = line[:-1].split(" ")
line = file.readline()

if len(tokens) < 2 : continue
if tokens[1] == "build" :
if tokens[0] == "s" :
start_time = int(tokens[2]) * 1000
elif tokens[0] == "e" :
end_time = int(tokens[2]) * 1000
elif tokens[1] == "target" :
if tokens[0] == "s":
target_start = int(tokens[2])
target_name = tokens[3]
elif tokens[0] == "e" and target_name == tokens[3]:
target_duration = int(tokens[2]) - target_start
target_tokens = tokens[3].split(".")
target_class = target_tokens[len(target_tokens) - 1]
if target_durations.has_key(target_class) :
target_durations[target_class] += target_duration
else :
target_durations[target_class] = target_duration
file.close()
return end_time - start_time
return

if __name__ == "__main__":
target_durations = {}
total_time = 0
for file_name in sys.argv[1:] :
total_time += ProcessLogFile(file_name, target_durations)

profile = target_durations.items()
profile.sort(SortProfileTimes)
total_target_time = 0
for target_iter in profile :
target_promille = target_iter[1] * 1000 / total_time
if target_promille > 0 :
print "%6.ds %3.d.%1.d%% %s" % (target_iter[1] / 1000, target_promille/10,
target_promille % 10, target_iter[0])
total_target_time += target_iter[1]
print "Running time: %d s targets: %d s %d%%" % (total_time / 1000, total_target_time / 1000,
total_target_time * 100 / total_time)

[[Category:Development]]
[[Category:Build_System]]

BuildingMSVCStandard

2008-12-29T03:29:36Z

DavidRoss: added Category:Build_System

== Code changes ==

What hides these issues when using Professional is more agressive inlining. Even if they all manifest with standard, they are actually separate and distinct issues. I've summarized the changes here and I'll add a patch once I've verified the impact of these changes. '''You have to do these changes before compiling'''.

Update: These are all the changes required to compile OO.o. I'm now working on a patch. --[[User:KaiB|KaiB]] 22:30, 13 January 2006 (CET)

Update: These or different changes with the same effect are implemented in m156 and will also be included in OOo 2.0.2.
--[[User:Vq|Vq]] 14:41, 13 February 2006 (EST)

=== '''sj2/util/makefile.mk''': add the SVTOOLLIB library ===

SHL1STDLIBS= \
$(VCLLIB) \
$(UNOTOOLSLIB) \
$(TOOLSLIB) \
$(CPPULIB) \
$(SALLIB) \
+$(SVTOOLLIB)

The required library was just missing from the makefile.

=== '''basic/source/apps/dialogs.cxx''' ===

1. Comment out the lines shown here starting from line 43:

//HACK( #define protected public )
//#define protected public // Kleine Schweinerei um an FreeResource ranzukommen
#ifndef _TOOLS_RC_HXX //autogen
#include <tools/rc.hxx>
#endif
//#undef protected

2. Comment out the line shown here (line 238):

aConfig.EnablePersistence( FALSE );
// aTabCtrl.FreeResource();
FreeResource();

Redefining the reserved keyword in spot 1 results in the linker trying to find a public FreeResource method while the actual one compiled into the library is protected. The error pops up in a totally unrelated module and halts the build. Spot 2 is the place that requires this workaround.

In [http://www.openoffice.org/issues/show_bug.cgi?id=58352 Issue 58352] there is a commit log of the changes needed to solve the problem and not workaround it. The fix is on CWS warnings01. (Gregor Hartmann is the basic/source/app maintainer)

=== '''tools/source/stream/stream.cxx''' (line 66): Define ENABLE_STRING_STREAM_OPERATORS to compile the stream operators into the library: ===

#define ENABLE_BYTESTRING_STREAM_OPERATORS
+#define ENABLE_STRING_STREAM_OPERATORS
#include <stream.hxx>

Simple change to ensure that the deprecated stream functions are still compiled into the library. The proper long term fix is to change the call sites and remove the requirement altogether.

[[Category:Porting]]
[[Category:Build_System]]

Tinderbox Setup

2008-12-29T03:28:17Z

DavidRoss: added Category:Build_System

Disclaimer! I tested the tinderbox scripts that are described on this page only with W32-tcsh but they should work with any *NIX like system. They are to be considered of beta quality only. Patches are very much appreciated.

----

= What is tinderbox =

In essence tinderbox collects build logs and presents the logs and the result it in a nice, clear and concise way It is very easy to tell whether build complete successfully or not and whether the results are still valid (there could have been changes to the sourcecode in the meantime). It collects the logs from separate and de-coupled build machines. Tinderbox has a few elaborations over the most simple 'status' web-page, inasmuch that it integrates with bonsai - to correlate builds against commits, and it has some nice built in error-parsers to allow huge build logs to be condensed to just a few (possible) tricky sections.

Our [http://go-oo.org/tinderbox/ tinderbox] uses the [http://www.mozilla.org/tinderbox.html Tinderbox 2] from the mozilla project plus some small cosmetic changes. Additional documentation can be found there.

= Setting up a build slave =
To do this, you need to be able to build OO.o already; if you can't do this start here: [[Building]].

== The very basics ==
As mentioned earlier, the tinderbox works by collecting the buildlogs. So all you need to do is to mail your logs to the tinderbox-server. The scripts presented further down automate this process, but let's have a look at the mails first.

=== Necessary annotations to the buildlogs ===
To be able to assign a logfile to a given buildslave, the mail must contain some lines that identify the buildslave and the cws the log belongs to.
An example of the fields looks like this:

tinderbox: administrator: John Doe <john@doe.com>
tinderbox: buildname: LinuxPPC (gcc 4.0.2)
tinderbox: tree: SRC680_m198
tinderbox: errorparser: unix
tinderbox: starttime: 1168270122
tinderbox: timenow: 1168286928
tinderbox: status: success
tinderbox: END

<buildlog goes here>

The fields should be almost self-explanatory, but still:
* Admin is the person to contact when there are problems with the buildslave/questions about it
* buildname is the identifier of the buildslave as it will appear in the overview pages
* tree identifies the Milestone/CWS that the buildslaves reports
* errorparser identifies the parser the tinderbox uses to detect build errors within the log - OOo's tinderbox currenlty uses "unix" errorparser for all platfomrs
* starttime is the timestamp when the build started (human-readable times possible as well)
* timenow is the timestap when the mail is sent
* status is the current state of the build (valid values are "building", "success" "failed", "test_failed", "not_running")

The buildlog follows the annotations.

=== Sending the buildlog gzipped compressed ===

To save both bandwidth and diskscpace (and to be in the max-message-size limit of most mail-servers), the tinderbox accepts buildlogs in gzipped format. So send gzipped mails, prepare the log as you would do with a plaintext-only message (i.e.)

<tinderbox annotations>

<buildlog>

And run gzip over the message. Then simply add it as attachment to the mail (the mail can then be empty, the body text is ignored).

=== Let tinderbox know whether it is a plaintext log or a gzipped one ===
In order to let tinderbox know that it is a gzipped compressed logfile, add a custom header to your mail:
* if your log is in the message body add
X-Tinder: cookie
* if your log is attached as a gzipped attachment add
X-Tinder: gzookie

The address to send the mails to is ooo <at> go-oo.org btw :-)
The above info should be enough to allow reporting your logs to tinderbox. If you seek more comport, set up a framework that automates building of OOo (see further below)

=== How many mails should I send? ===
Well, at the bare minimum you only need to send one single mail, but sending two mails (one when the build starts and one when the build finishes) allows the tinderbox to give estimations on when a build will be finished (and allow other buildslaves of a similar setup to skip the tree and build another one instead.
Another good way is to send a third mail in between, after configure/bootstrap is finished. That way one can check out whether patches that are added were applied successfully and whether configure setup is OK.

= Framework to automate the process =
The framework that is described in the following sections can be used to build "new" and "Ready-for-QA" CWSs and MWSs of the 680er codeline. The source is fetched from cvs.

See [http://www.go-oo.org/tinderbox/ this] webpage for a list of the currently accepted tags. You will find the build logs (providing there are any) when you click on the corresponding tag.

== Requirements ==

A mininimal framework to build OOo CWSs and MWSs and sent the reports to the tinderbox at go-oo.org is created by the following files.

These three files from [http://go-ooo.org/tinder-scripts/ this] directory are needed to refresh the build tree and send the build log after the build:
'''(Files partially updated: 2006.07.02)'''
tin-main.pl
tinget.pl
tinsend.pm

In principle any build/preparation script can be used but the following two files (also from [http://go-ooo.org/tinder-scripts/ here]) work together with the main tinderbox slave script mentioned above (tin-main.pl):
'''(Files partially updated: 2006.06.25)'''
tinprep.sh
tinbuild.sh

If you want to use your own scripts instead make sure to adapt the lines that call tinprep.sh and tinbuild.sh in tin-main.pl.

In addition to these files you need to install the Sender.pm Perl module from CPAN. See the [[CPAN_install]] page for details about getting/installing perl modules.

== Configuration ==
A few files have to be adapted to match your local setup. Changes only have to be done in areas marked with:
"# -- End of Things to tweak --"

<ul>
<li>tin-main.pl These variables need to be adapted (Follow the example in the source):<pre>
$tinsend::FROMADDRESS
</pre>
For smtpservers that doesn't need authentification just enter the server name:
<pre>
$tinsend::SMTPAUTH = '';
$tinsend::SMTPSERVER = 'smtpserver.without_pw.org';
$tinsend::SMTPAUTHID = '';
$tinsend::SMTPAUTHPW = '';
</pre>
If the smtpserver needs authentification set $SMTPAUTH to 'LOGIN' and set your username and password:
<pre>
$tinsend::SMTPAUTH = 'LOGIN';
$tinsend::SMTPSERVER = 'smtpserver.without_pw.org';
$tinsend::SMTPAUTHID = 'userid';
$tinsend::SMTPAUTHPW = 'password';
</pre>
</li>
<li>tinbuild.sh Set the options to configure your OOo build.
</li>

<li>tinprep.sh OOo needs some things prepared before it can be build. Things like that go into this file.
</li>
</ul>

== Start the tinderbox build ==
The build is then started with:

./tin-main.pl "OOoW32(opti)" /cygdrive/d/w1/SRC680_m146 SRC680_m146 co send

The first parameter sets the name the build identifies itself, the second gives the target directory the source is build in, the third sets which CWS/MWS is used (see [http://www.go-oo.org/tinderbox/ here] for allowed values), the fourth how the source is obtained/treated (checked out from cvs in this case) and the last one says that the buildlog is send to the tinderbox. The parameters are discussed in detail later in this document.

= Documentation =

The following part describes the used scripts and useful parameters. (The markup needs a brush-up.)

<pre>
tin-main.pl
Syntax (all five parameters are needed):
tin-main.pl buildstring src_path ws {co|up|cont|clean} {send|nosend} [buildshell]
buildstring - Name that will appear in the tinderbox
src_path - Pointing to source to be used
ws - Which workspace shall be build. It accepts CWSs names (from the
list in <http://go-oo.org/tinderbox/tags/tag-list>) or all MWSs
starting with ???680_m*.
co|up|cont|clean - Tells the script what to do with src_path. Fresh checkout,
update a current repo (this also deletes modified/extra files),
do nothing, just start/continue with current repo, and clean
removes all wntmsci10.pro before rebuilding.
send|nosend - send the logfile to the tinderbox (or not)
buildshell - Choose from tcsh, bash or 4nt which shell to use for the build.
This parameter is optional, the default is tcsh.

The main program that starts the build, captures the logfile and sends it to
the tinderbox.

Example: ./tin-main.pl "OOoW32(opti)" /cygdrive/d/w1/SRC680_m146 SRC680_m146 co send

tinsend.pl
This module handles sending of mails with attachments. This was necessary
because the windows build logs are easily 30MB or more and in our early
setups this was just to much to be handled by some SMTP servers and also
for go-oo.org. See some documentation inline in that file.

tinget.pl
Syntax (all four parameters are needed):
tinget.pl ws buildlog src_path {co|up|cont|clean}
ws - See tinder-main.pl.
buildlog - logfile name (this is send to the tinderbox)
src_path - See tinder-main.pl.
{co|up|cont|clean} - See tinder-main.pl.

This script does the workspace (src_path) handling.

tinbuild.sh
Syntax:
tinbuild.sh ws buildlog src_path [buildshell]
Parameter see tinder-main.pl, buildshell is optional.

The actual build script that starts the build and captures the logfile.

tinprep.sh
Syntax:
tinprep.sh src_path [ws] [buildshell]
Parameter see tinder-main.pl, ws and buildshell are optional.

Prepare the workspace for the build
</pre>

= Alternative tinderbox script =

'''Please note that this script is independent of the framework mentioned above. Don't mix the instructions!'''

If you don't want to use the modular framework you can still use the former, not mail-compressing version. Get the [http://go-ooo.org/tinder-scripts/tinder-build tinder-build] script and edit it to suit your needs:

The script will get http://go-oo.org/tinderbox/tags/tag-list and build all of the included CWSs. You will want to change that.

Choose a buildname
$BUILDNAME = 'My BuildName';

This script already includes a build script. You have to work through this to adapt it to your needs.

'''Mailer''' - you need a mailer to send mail with tinder-build, check that you have sendmail configured right, or hack the script to use your mailer.
$MTA = '/usr/bin/mail';

= Problem - It sends fine but nothing shows up =

There are two issues that may cause this. First, the tinderbox web-pages are re-built every 10 minutes using a cron job; so wait for 11 before getting to concerned.

The second thing is more crucial, since the tinderbox organises the logs chronologically, it is vital to ensure that your system time is not ahead of the tinderbox's, and that it is in the same decade, week, hour, minute etc.

Finally, it's possible that someone else has sent in corrupt logs that are stopping the script completing. See [http://go-ooo.org/tinderbox/tinderbox.log here] if the mail arrived, [http://go-ooo.org/tinderbox/tinderbox2.log here] if there were errors processing it and [http://go-ooo.org/tinderbox/err-log here] for any potential error messages from the demon.

[[Category:Build_System]]

Helpcontent2

2008-12-29T03:27:44Z

DavidRoss: added Category:Build_System

==What it contains==
The directory helpcontent2 contains all files for the OpenOffice.org help system.
==How it is organized==
The following directory hierarchy applies

{| border=1 cellspacing=1 cellpadding=2
| '''Directory'''
| '''Contents'''
|-
| helpcontent2
| The module's main directory
|-
|helpcontent2/helpers
| Files that are not used by the help content itself, like the help file DTD
|-
|helpcontent2/helpers/helpauthoring
| The help authoring environment
|-
|helpcontent2/prj
| The build and deliver lists
|-
|helpcontent2/source
| The files used to build the application help
|-
|helpcontent2/source/auxiliary
| Auxiliary files that are needed for building the help, style sheets, configuration files
|-
|helpcontent2/source/text
| The help content source files, the makefiles for the help compiler, and the localized content. Every subdirectory contains its own makefile and a file with all localized content for that directory
|-
|helpcontent2/source/text/sbasic
| Help files specific to BASIC and the IDE
|-
|helpcontent2/source/text/scalc
| Help files specific to the Calc module
|-
|helpcontent2/source/text/schart
| Help files specific to charts (Chart used to be a module of its own)
|-
|helpcontent2/source/text/sdraw
| Help files specific to the Draw module
|-
|helpcontent2/source/text/shared
| Help files common to two or more modules
|-
|helpcontent2/source/text/simpress
| Help files specific to the Impress module
|-
|helpcontent2/source/text/smath
| Help files specific to the Math module
|-
|helpcontent2/source/text/swriter
| Help files specific to the Writer module
|-
|helpcontent2/util
| The linker makefiles for the help sections
|}

[[Category:source directories]]
[[Category:Documentation/OnlineHelp]]
[[Category:Build_System]]

Windows Installer Hacking

2008-12-29T03:27:03Z

DavidRoss: added Category:Build_System

This page explains how to modify a Windows installer EXE (the big, >70 MB one which contains everything).

== Why? ==

Normally this is a bad idea, and it is better to build OOo from scratch
yourself. However, this may not be possible for various reasons, e.g. if:

* You don't have the (non-Free) toolchain available to build OOo.
* You're modifying a non-Free OOo derivative and don't have the source.
* You don't have the time and resources available to build OOo
* etc.

== OOo_2.0_Windows_install_en-US.exe ==

This is an NSIS self-extracting installer. It contains the following
structure:

openofficeorg1.cab
openofficeorg2.cab
openofficeorg3.cab
openofficeorg4.cab
openofficeorg20.msi
instmsia.exe
instmsiw.exe
licenses/
readmes/
setup.exe
setup.ini

In the OOo 2.0 build process it is built from its contents using a command
(at "call_nsis" in solenv/bin/modules/installer/download.pm) which does
something like the following:

/cygdrive/c/Program\ Files/NSIS/makensis.exe c:/ooo2/ooo-build/build/ooo680-m3/instsetoo_native/wntmsci10.pro/OpenOffice/nsis/en-US/downloadtemplate.nsi

The file

downloadtemplate.nsi

contains instructions for building the .exe. Its directory also contains

English_pack.nsh
English_pack.nlf

which both consist of text strings in the installer language and are
referenced from downloadtemplate.nsi. (Various .ico and .bmp files, located
outside the directory, are also referenced).

== CAB files ==

These contain the actual files which get extracted. Although CAB files can
apparently store a directory tree structure, these ones are flat. The
filenames inside the CAB are often, but not always, the same as the names
when installed.

N.B. '''The order in which files are stored is very important!'''

cabextract -l # lists the contents of a cab file.
makecab.exe /F blah.ddf # Create CAB from blah.ddf, a spec+filelist

The "blah.ddf" file can be generated with a perl script like this:

<pre>
#!/usr/bin/perl -w
#
# Files to pack: c:\msi\files
# Output file path is relative to that directory
# Temporary work space: c:\msi\makecabtemp
# Usage: perl make-ddf.pl (list of names of files to pack, in order, without path)
#
print <<EOF;
.Set CabinetName1=../out.cab
.Set ReservePerCabinetSize=128
.Set MaxDiskSize=CDROM
.Set CompressionType=LZX
.Set Compress=ON
.Set CompressionLevel=2
.Set Cabinet=ON
.Set DiskDirectoryTemplate=c:/msi/makecabtemp
EOF
for my $file (@ARGV) {
print qq("c:\\msi\\files\\$file" $file\n);
}
</pre>

Some files in the CABs may not actually get installed: See Component.idt
below.

== MSI file ==

This is a relational database which controls the installation process. It
can be dumped into tab-separated text files (*.idt), one per table, using

MsiDb.Exe -e -d blah.msi -f c:\text_file_dest *

The text files can be dumped back into a new MSI like this:

MsiDb.Exe -i -d blah_new.msi -f c:\text_file_dest *.idt

(N.B. In both cases, be sure to surround the * in quotes if you're using a
UNIX shell)

If you edit these text files, you have to be pretty careful, because there
is all sorts of referrential integrity to preserve between tables. To
modify the install, some tables are particularly important:

=== File.idt ===

This is a list of files which *potentially* can be installed.

* File is the name of the file in the archive.

* Each file is part of a Component.

* FileSize speaks for itself.

* Sequence is the order in which the files appear in the CABs, and the
installer will *fail* if it is not correct. (The Sequence is across all CAB
files, so for instance the first file in CAB 3 has the Sequence number one
higher than the last file in CAB 2).

=== Directory.idt ===

Defines directories per feature component

=== Media.idt ===

Specifies the CABs from which to obtain files. Crucially, this specifies
the file number ranges contained within each CAB, so if you add any files
you will probably have to alter this.

=== Feature.idt ===

Defines Features, i.e. groupings of functionality which can be selected in
the installer.

=== FeatureComponent.idt ===

Each Feature is a set of components.

=== Component.idt ===

Specifies into which directory a component is installed (relative to Directory.idt), etc.
KeyPath is the First file in the component (in Sequence order) (?)

== Full paths of executables ==

* C:\Program Files\Microsoft Platform SDK\Bin\MsiDb.Exe
* C:\WINDOWS\system32\makecab.exe (on Windows XP)
* cabextract - UNIX (or cygwin) program

[[Category:Build_System]]

VBA

2008-12-29T03:24:13Z

DavidRoss: added Category:Build_System

[[VBA zh|中]]

[http://vba.openoffice.org VBA interoperability] project is a joint Novell & Sun incubator project whose aim is to deliver a way to run Excel and Word macros natively in imported documents.
* Noel Power (lead)
* Andreas Breagas (co-lead)

'''Visual Basic for Applications''' ('''VBA''') is an implementation of Microsoft's [[wikipedia:Visual Basic|Visual Basic]] which is built into all Microsoft Office applications.

== Latest news ==
* {{CWS|npower6|SRC680}} has been integrated into {{m|211}}
* Update Wiki Page with latest info
* [http://blogs.sun.com/GullFOSS/entry/sun_and_novell_work_together Novell and Sun to work together] on the VBA incubator project
* I am delighted that Andreas Bregas now joins me to co-lead the vba incubator project

== Terminology ==

* [[helperapi]] - The compatibility API generously donated by Sun that was part of their migration toolkit
* [[oovbaapi]] - the ooo-build vba interoperability solution originally implemented by Novell + object implementations from the helperapi. Note: [[Ooo-build]] contains the latest VBA model and patches which allows you to run macros from your Microsoft Office documents. This model is under heavy development by Novell and others and the changes are continuously ported to openoffice. It is expected that many macros won't run for now.

== Dashboard ==

* {{CWS|npower8|SRC680}} (nearly complete) (contains)
* some helperapi object porting
* changes to include new multi-inheritance style idl and new style service definitions
* removal of idl for compatibilty constants[1]
* {{CWS|npower7|SRC680}} integrated
* {{CWS|npower6|SRC680}} integrated

[1] these will be generated using the mechanism from the helperapi (basically the idl is generated from metadata files, the idl files are not preserved (or needed) but the types database generated from the idl files

Task queue and status (in order of priority)

{| style="vertical-align:top; text-align:left; background-color:#efefef;"
|- style="background-color:#d6d6d6;font-weight:bold;"
| Feature || Description|| Issue # || Planned cws || State || Milestone integrated ||
|-
| autogenerate constants in oovbaapi || port helperapi constant solution to oovbaapi module || {{Bug|75551}} || {{CWS|npower8|SRC680}} || done || n/a ||
|-
| ooo-build api sync || synchronise ooo-build api changes with upstream || {{Bug|77189}} || {{CWS|npower8|SRC680}} || in progress || n/a ||
|-
| array of array indexing || in vba array of array indexing is very common, e.g. <tt>myArray(1)(2)</tt>|| n/a || n/a || n/a || n/a ||
|-
| toolbox control event support || these controls support a loose binding where the presence of a macro event handler of the form <tt>controlname_xxx e.g. controlname_click</tt> results in the appropriate macro getting called when the associated action takes place || n/a || n/a || n/a || n/a |||
|-
|}

Completed Features

{| style="vertical-align:top; text-align:left; background-color:#efefef;"
|- style="background-color:#d6d6d6;font-weight:bold;"
| Feature || Description|| Issue # || Planned cws || State || Milestone integrated ||
|-
| vba constants || adjust basic runtime to be 'conditionally' aware of the vba constants defined in oovbaapi module || {{Bug|68897}} || {{CWS|npower7|SRC680}} || complete || n/a ||
|-
| support dim of vba object || adjust basic runtime to be 'conditionally' allow a vba compatibilty api object to be used like <tt>Dim r1 as Range</tt> || {{Bug|68897}} || {{CWS|npower7|SRC680}} || complete || n/a ||
|-
| compatible erase array || in vba compatibility mode erase does not behave as expected || {{Bug|70380}} || {{CWS|npower7|SRC680}} || complete || n/a ||
|-
| null variant behaviour || in vba compatibility mode operations on null variant objects behave differently || {{Bug|71827}} || {{CWS|npower7|SRC680}} || complete || n/a ||
|-
| 'Like' || new 'Like' operator for basic || {{Bug|73830}} || {{CWS|npower7|SRC680}} || complete || n/a ||
|-
| Module scope variable || in vba module scope variables lifetime is tied to the document containing the macro || {{Bug|76819}} || {{CWS|npower7|SRC680}} || complete || n/a ||
|-
| support simple range short cut references || in vba the evaluate function is used for resolving many things, one of theses is short cut range references e.g. '[a1:b2]' || {{Bug|68898}} || {{CWS|npower7|SRC680}} || complete || n/a ||
|-
| fix accent handling || in vba mode accents in modules or macros are not handled || {{Bug|76818}} || {{CWS|npower7|SRC680}} || complete || n/a ||
|-
| fix object comparison || in vba mode there is a problem comparing objects with default paramaters (when the default is not specified) || {{Bug|76820}} || {{CWS|npower7|SRC680}} || complete || n/a ||
|-
| class module import || when class modules are imported the correct 'option' should be set || {{Bug|76822}} || {{CWS|npower7|SRC680}} || complete || n/a ||
|-
| migrate ooo-build code || suck in the mountain of idl and implementation code from ooo-build || {{Bug|74096}} || {{CWS|npower6|SRC680}} || complete || {{m|211}} ||
|-
| import vba code || conditionally import (uncommented) vba code and set appropriate module options || {{Bug|64570}} || {{CWS|npower6|SRC680}} || complete || {{m|211}} ||
|}

Broader scope tasks that need more investigation (and splitting into smaller tasks) (to be added)

create list of items that may need promoting from vba compatibility to <tt>Standard</tt> ooo-basic behaviour e.g. like {{Bug|70380}}

== How to enable the VBA model ==

The VBA model is enabled by default in the current ooo-build. It's enough to [[Getting It|get]], [[Building with ooobuild|build]], [[Installing|install]], and [[Running|be able to run]] it.

If you are using upstream OpenOffice.org and wish to play with this feature then check out and build the {{CWS|npower6|SRC680}} which contains the initial code drop for the oovbaapi

== How to disable the VBA model ==

Depending on how your version of OpenOffice.org delivers the VBA feature to you, there are a number of ways to disable it.

If you have an Openoffice.org built by a linux distro (or a windows one from Novell) that has the vba interop feature then all you need do is navigate to the 'Tools.Options.Load/Save.VBAProperties' page and uncheck the 'Load Excelbasic code to edit' option.

If you are using an own build (incorporating) {{CWS|npower6|SRC680}} the above method will always work. But if you built the vba interop feature as an office extension then you can of course disable or delete the vbaapi.oxt extension using the Extension Manager.

== How can I help you? ==

We need help in a couple of areas, [[Porting notes|porting]] objects from the [[helperapi]], understanding the VBA usage patterns, implementation and testing; see below.

== Porting Objects from the HelperApi ==

What is the [[helperapi]]?

Have a look at the [[porting notes]]

Have a look at a [[porting example]]

[[Porting_notes#Calc_Objects_to_port|list]] of objects that need porting

[[Porting_notes#Missing_attributes.2Fmethods_to_port|list]] of methods (to be ported from [[helperapi]]) to existing objects

== Understanding the VBA usage patterns ==

VBA model is huge and we need help in understanding the VBA usage patterns for prioritizing as we progress. It's important to receive as many Microsoft Office documents with macros as possible for analysis. '''We are interested in documents from developers and regular people too.'''

=== Dumping the VBA from your MS Office documents ===

==== libgsf ====

If you're worried about the sheet data you can use ''test-msvba'' from the [http://freshmeat.net/projects/libgsf/ libgsf]. Download the latest [http://cvs.gnome.org/viewcvs/libgsf/tests/test-msvba.c test-msvba.c] file and compile it with the following command:

gcc `pkg-config --libs --cflags libgsf-1` -o test-msvba test-msvba.c

Note: you need to have libgsf-devel package installed.

Now, you can dump the VBA from your documents with the following command:

find -name '*.xls' -exec sh -c 'test-msvba {} >> ~/excel-vba-stream-for-noel.bas' \;

==== pole ====

Or you can use [http://pole.berlios.de/ POLE] with GUI. POLE is a portable C++ library to access structured storage. It is designed to be compatible with Microsoft structured storage, also sometimes known as OLE Compound Document.

=== Exporting modules from the Microsoft Excel ===

Open your document and edit associated macros. You can see list of modules on the left side of your screen. Use the right mouse button and select ''Export'' from the context menu. The whole module will be saved as one huge ''*.bas''.

=== Where to send ===

If you are going to send pure VBA streams, send them directly to [Noel dot Power at Novell dot com].

== Implementation ==

=== The desired sequence ===

==== Add an extension to the IDL ====

The IDL lives in oovbaapi/org/openoffice/*, the IDL syntax can easily be gleaned from a few other IDL files. Two things are worth bearing in mind:
* it's important that the argument names are correct, so that the <tt>MsgBox title:="hello"</tt> syntax works correctly.
* for optional arguments, or variant types you need to use the <tt>any</tt> type

Having edited the IDL extension you need to:
* run: <tt>build && deliver</tt> in oovbaapi (perhaps remove types.db first),

==== Add the extension to the implementation ====

The impl. code lives in <tt>sc/source/ui/vba/</tt> - create the right header and source files.
Add the method (with the correct prototype) to the header - often it's easiest to cut/paste that from the compiled C++ headers in <tt>sc/unxlngixxx/inc/org/openoffice/vba/</tt>

Then implement the method itself in the .cxx file. Run <tt>build debug=true</tt>

==== Running it ====

You did use [linkoo] right ? - in which case - just re-run soffice.bin (killall -9 soffice.bin first to ensure there is no lurking factory process).

Now of course - you want to add a new test to exercise it to ooo-build/test/macro/*. And of course loop back to the beginning.
Once you've got something you want to share - a simple <tt>cvs diff -u | tee /tmp/foo.diff</tt> in ooo-build/scratch will yield a patch you can mail to Noel / the ooo-build mailing list to get your code folded in.
NB. it's important you sign the [http://www.openoffice.org/licenses/jca.pdf JCA] first.

== Testing ==

It's extremely important to test the work which is already done. You can use test cases from the ''ooo-build/test/macro'' directory, you can extend them or you can write your own test cases.
It's a good idea to write test cases directly in the Microsoft Excel?

== Accessing the VBA API from other languages ==

The VBA API is implemented by an UNO service, the service is accessible via a singleton. As such it is possible to use the API from any language that has an UNO binding. The main entry points to the API are certain global variables { Application, ActiveWorkbook and ActiveSheet } or methods { WorkSheets, WorkBooks } exported by the service. Using these globals as a starting point the rest of the api can be accessed.

'''NOTE:''' Beaware the idl is not stable, (nor won't be for the forseeable future be 'published') it WILL change, so if you are using a language that has a binary dependency on the interface (like c++ & java) then consider yourselves warned.

=== Python ===

vba = uno.getComponentContext().getByName("/singletons/org.openoffice.vba.theGlobals")
sheet = vba.ActiveSheet
book = vba.ActiveWorkbook

=== Java ===

<pre>
import org.openoffice.vba.*;
"
// getComponentCtxFromSomewhere is a fictional
// routine representing acquisition of the component context
// from e.g. remote ServiceManage if the code is a remote client
// or from the XScriptContext if this were a java ScriptingFramework script

XComponentContext ctx = getComponentCtxFromSomewhere();
Object oGlobs = ctx.getValueByName(
"/singletons/org.openoffice.vba.theGlobals");
XGlobals xGlobs = AnyConverter.toObject(
new Type(XGlobals.class), oGlobs);
XWorkBook xWBook = xGlobs.getActiveWorkbook();
XWorkSheet xSheet = xGlobs.getActiveWorkSheet();
</pre>

=== OO Basic ===

Basic allows access to the global variables automatically just like VBA does, there is no need to create any services or access any singletons to use the API

msgbox "Name of the current document is " & ActiveWorkbook.Path

=== Visual Basic ===

Visual Basic, VBA, VBScript and other COM-enabled languages supports accessing OpenOffice VBA API via COM-UNO bridge

<pre>
Set oServiceManager = CreateObject("com.sun.star.ServiceManager")
Set oDesktop = oServiceManager.createInstance("com.sun.star.frame.Desktop")
Dim aNoArgs()
Set oCalcDoc = oDesktop.loadComponentFromURL("private:factory/scalc", "_blank", 0, aNoArgs)

Set v = oServiceManager.DefaultContext.getValueByName("/singletons/org.openoffice.vba.theGlobals")
Set ooApp = v.Application
MsgBox ooApp.Version
Set cell = ooApp.ActiveCell
cell.Value = "Hello!"
Set r = ooApp.Range("B1", "B1")
r.Value = "Hi1"
</pre>

CHM Help file generated from oovbaapi IDL:
http://community.i-rs.ru/index.php?action=dlattach;topic=6096.0;attach=4431
[[Category:Development]]
[[Category:Build_System]]

CWS

2008-12-29T03:17:32Z

DavidRoss: added Category:Build_System

CWS here is meant as the acronym for [[ChildWorkSpace]]. For a lengthier cws explanation see the [http://tools.openoffice.org/servlets/ReadMsg?list=dev&msgNo=5044 introduction], the [http://tools.openoffice.org/#CWS Overview, Tools] (still focused on CVS though) and the [[CWS Policies]] page. This text is some really, really bare bones for the quickest, most simple cws usage.

The basic overview here is that a CWS is a SVN branch, tied to a service with a database backend called [[EIS]]. The cws tooling talks to both the SVN server and (via SOAP) to the [[EIS]] service. It makes maintaining branches more efficient, standardises their use & integrates with QA nicely.

All code that goes into OO.o has to go through a CWS. A CWS is a fairly heavy-weight beast - thus it's well worth aggregating several commits / bug-fixes into one.

NB. Since this 'howto' was written an even quicker way of committing patches to a cws has been created for people who use ooo-build: [http://cvs.gnome.org/viewcvs/ooo-build/bin/cws-commit-patch?view=log bin/cws-commit-patch].

{{Documentation/Note| As of the migration to Subversion the CWS tools have been reworked and there is just one cws command with different subcommands. Resyncing a CWS is different, adding modules isn't necessary anymore, and other details changed. This page has been adapted for SVN. }}

For more information on SVN specific CWS handling please read [[OOo and Subversion]]. If you need to work on a CWS based on legacy CVS for an OOo release 3.0.x or earlier please see an [http://wiki.services.openoffice.org/w/index.php?title=CWS&oldid=104789 older permanent revision] of this page here.

{{LinkBanner}}

== Basic setup / Assumptions ==

It is assumed that you have fixed some bug / created some feature, and you have a live build tree. It is also assumed that you have sourced the ''LinuxIntelEnv.Set.sh'', ''winenv.set'' or ''winenv.set.sh'' script as appropriate, and as a result your shell is set up correctly with various environment variables pointing to the build tree.

It is also assumed that you have an up-stream OOo account with the appropriate commit privileges in SVN and your DSA public key file assigned for the svn+ssh protocol, and of course your DSA private key needs to be accessible to ssh on your machine, best by having added it to ''ssh-agent'' with ''ssh-add'' so you won't have to type your passphrase over and over again.

=== cws config file (.cwsrc) ===

You also need to have a CWS configuration file named .cwsrc in your home directory (~/.cwsrc) for any of the cws command-line tools to work. The following is an example of a typical .cwsrc file.

[CWS_CONFIG]
CWS_DB_SERVER_1=https://eis.services.openoffice.org/soap/servlet/rpcrouter
CVS_ID=foouser
CVS_PASSWORD=SDhiod0=s
CVS_SERVER_ROOT=:pserver:foouser@localhost:/cvs
SVN_SERVER=svn+ssh://svn@svn.services.openoffice.org/ooo

The value for the ''CVS_PASSWORD'' attribute is taken from your ~/.cvspass file once you cvs login through the tunnel to legacy CVS. You can also use a script like [http://www.perlmonks.org/?node_id=457764 this one] to encrypt your password the way CVS does it. Of course Subversion will not access the CVS repository, but the ''CVS_ID'' and ''CVS_PASSWORD'' fields are also used by the ''cws'' tool for [[EIS]] access.

== Creating the cws ==

You have to think of an imaginative name for your cws; if it's just some general bug fixing thing, people tend to use account-name<index> otherwise some more descriptive name. The examples on this page here use the name ''link01''.

For details of the <tt>cws create</tt> command please see [[OOo_and_Subversion#Create_a_CWS]].

You need to have perl SOAP::Lite module installed for <tt>cws create</tt> to work. See [[CPAN install]] page for how to install Perl modules.

== Filling out the details in EIS ==

[http://eis.services.openoffice.org/EIS2/Logon Login] with your OpenOffice.org email address to [[EIS]]. Navigate the DEV300 'new' tree - find your CWS (or better simply look it up under ''Child workspaces'' - ''My CWSs'' or to a full search with the name of your CWS ''Child workspaces'' - ''Search'').

Then click on the underlined link at the top. Fill out the details, as there are:

* '''Owner''', select your account from the list if it's not already prefilled.
* '''QA representative''', check with the project you're working on or ask on the dev@qa mailing list who the proper QA-rep for your CWS would be and select from the list. If no QA-rep is assigned, the CWS shows up under the '''SeekQA''' menu and someone might jump on it. However, it may also stay there for weeks if nobody does, so better communicate with your project. See also how to [[find a QA representative]].
* '''Description''', give a reasonable description of the CWS (not just 'bugfixes').
* '''Release''', the release target, e.g. ''OOo2.3''.
* '''Estimated due date "ready for QA"''', an estimate when you plan to have it ''ready for QA'', in format 2002-11-23. This is to give QA an idea when the CWS will be ready.
* '''Estimated due date''', when the CWS should be ready for integration. Note that the time span between ready-for-QA date and the final due date needs to be communicated with the QA-rep, usually it's sufficient to add 2 more weeks to give time for QA and enter that as the final due date, in format 2002-11-23. This is to give release engineering an idea when a CWS will show up for integration.
* '''Level of impact''', ''One Application'' if working on a specific application's code, ''Two or more applications'' if working on a library used by several applications, ''Whole Office'' if touching code that is used throughout the entire office suite or affects general behavior.

== Setting up the environment ==

Now we created a cws - we need to tell the tooling we're working with this cws; we do:

export CWS_WORK_STAMP=''link01''

On Windows, if using tcsh the equivalent command is:

setenv CWS_WORK_STAMP ''link01''

== Adding tasks ==

The CWS (in order to ever get merged) has to have a number of issues associated with it, describing the bugs fixed in this CWS. The developer should mark these as ''FIXED'' as he commits/tests & QA should mark these bugs ''VERIFIED''. See issue handling in [[CWS#When_you.27re_happy | When you're happy]] further down.

It's also important to get the Milestone correct in the bug. To associate the task with the CWS do:

cws task ''i24253''

NB. cws task: SOAP only, no SVN access.

== Create a new module ==

{{Documentation/Caution| This is the procedure for legacy CVS and needs to be rewritten for SVN! }}

(Taken from [http://tools.openoffice.org/dev_docs/child_workspace_newmodule.html].)

In case you have to introduce a new module not yet known on the master workspace you have to

* first think hard if a new module is really needed. OOo now has more than 200 modules and things are getting a bit out of hand. Of course, if the new stuff doesn't really fit anywhere than a new module might be the lesser of two evils.
* please don't mix code of the core office and extensions in one module. To bring forward the modularization efforts of OpenOffice.org extensions should be treated extra to the Office code.
* create that module in cvs.
** note: if you are adding the module under '''external''' project, then creating is a bit more complicated:
::If you checkout from the CVS the ''external module'' (<code>cvs co external</code>) you will get actually the <code>util/external</code>, the directory <code>external</code> from util project's CVS. If you create a new directory, it will be committed into the util project that you do not really want.
::In order to check out the "right" ''external'', you must checkout one of the directories of external project whose name is not identical to a directory in <code>util/external</code>. For instance:
::: <code>cvs co external/libxml2</code>
::You will have to position yourselves besides the <code>libxml2</code> subdirectory (in this case) in the <code>external</code> directory, create a new directory and commit it using <code>cvs add</code>. After that, you can checkout your module and work on it as usual, still remembering that you are working on HEAD.
* get a cvs alias for that module so that it can be checked out by it's name. See the procedure in http://external.openoffice.org/ and additionally example {{Bug|76452}} (assign it to mh). this is coupled with the legal review of the new external code, so that the new alias will be available once the review has been done.
* check in for this module to cvs HEAD in your CWS. In contrast to all added modules do not work on a cws-branch but toplevel.
* assure inter module dependencies (i.e. [[Hacking#prj/build.lst]] files) are correct. Make sure all modules needing something delivered by the new one are dependent on it. If it is not needed by any module at build time, make it a prerequisite of 'postprocess'.
* when the cws is in QA, announce the new module to Hamburg release engineering. You can do this either by writing something in the CWS description field (to RE: CWS contains new module bla) or by sending an email. This is necessary because new modules do not get tracked by CWS tooling and RE has to manually check them out before doing the integration build on the master workspace.

Additionally it is good practice to provide a short description of your new module in [[Source code directories]] table.

== Committing code ==

Committing requires nothing particular new; the database doesn't track commits. Just commit them to the branched modules.

SVN should add some helpful fields for you & some helpful blurb about what to write here - often it doesn't. The stock format is:

Issue number: #i24253#
Submitted by: mmeeks
Reviewed by: mmeeks
This patch fixes a silly bug in linkoo

== When you're happy ==

Finally - when you've committed everything & built & tested it, you need to hand over the CWS to QA.

The issue handling of issues added to the CWS at this stage is

* Verify all issues assigned to the CWS are really fixed in your CWS build.
* If so, reassign the issue to the QA representative of the CWS.
* Announce new features and enhancements (not mere bug fixes) using the [[feature announcement]] form within EIS.

Having done all that, login back to the CWS page in [[EIS]] and re-edit the details - marking the state to ''Ready for QA''.

Check your changes. If you did some [[Compatible_Builds#What_changes_are_binary_incompatible.3F|binary incompatible change]] mark the corresponding module ''incompatible''.

== What next ? ==

You get to wait until the CWS is [[Approve_a_CWS | approved by your QA representative]] and nominated for integration, then it will be merged into HEAD and released.

The approval procedure may take some time. In the meantime the master workspace may change significantly. If changes got into the master touching the same code lines you have changed integrating your CWS will lead to merge conflicts. [[Resolve Merge Conflicts for CWS Integration]] gives some advice how to prevent problems during integration.

== Updating to a newer milestone ==

The long-term CWSes need a resync to a newer milestone from time to time.

For details please read [[OOo_and_Subversion#Rebasing_a_CWS]].

-----------
'''See also:''' [[Merge Parts Of A CWS Into Another CWS]]

[[Category:Development]]
[[Category:CWS]]
[[Category:Build_System]]

Porting to x86-64 (AMD64, EM64T)

2008-12-29T03:16:41Z

DavidRoss: added Category:Build_System

== Current status ==

The x86-64 port is essentially complete, modulo possible bugs. But between releases, during the development cycle, it is always likely that for a given milestone that OOo fails to build on x86_64, or that new 32bit-isms are introduced. Help is always appreciated to catch these problems early, or to recognize that there are other more subtle problems that we're unaware of.

The work was originally based on ''ooo64bit02'' [[CWS|Child Workspace (CWS)]]. It was too huge to be integrated as a whole, so it was split to various smaller CWS'es, and integrated to SRC680 (HEAD); then more fixes were introduced.

More info:
* [http://artax.karlin.mff.cuni.cz/~kendy/ooo/OOoCon-2005/ OOoCon2005 presentation about the port]
* [http://artax.karlin.mff.cuni.cz/~kendy/blog/ Jan Holesovsky (Kendy)'s blog]
* [http://blog.janik.cz/ Pavel Janik's blog]

== How to get it ==

Get the latest SRC680 development sources, and follow the general [[Getting It]], [[Building_with_ooobuild|Building]], [[Installing]], [[Running]] sections. Don't forget to use --with-system-libs while configuring.

It is recommended to use a recent distro for building, like SUSE 10.1 or newer. gcc should be at least 3.4.1 with enum+visibility patches, 4.x is probably the best choice.

It is very probable that you'll have problems with Java - some of the VM's have problems to build OOo on x86-64.

== Java ==

You have to have a 64bit Java installed. The following are known to work:
* gcj 4.0.1 - e.g. in SUSE 10.1 installation, works out of the box
* [http://www.blackdown.org/ Blackdown Java] - reported to work

== How to help ==

Generally

* Compile it
* Find a bug (crash, missing functionality, ...)
* Fix it ;-) It might be either in the ooo-build patches, or up-stream
* [http://qa.openoffice.org/issue_handling/submission_gateway.html#code_module File] the problem & the solution to the [http://www.openoffice.org/issues/query.cgi Issuezilla] if it is up-stream, or send it to openoffice@lists.ximian.com if it is in the ooo-build patches
** Ensure that you CC 'kendy', 'pjanik', and 'cmc' on the report to get a quick response
* If the underlying problem is a new problem archetype - try to find & fix all other instances of it

Should you have questions, please contact ''caolan'', ''kendy'', ''martink'', or ''paveljanik'' on [[IRC_Communication|IRC]].

[[Category:Porting]]
[[Category:Build_System]]

ReleaseMilestone

2008-12-29T03:16:16Z

DavidRoss: added Category:Build_System

The '''Release Milestone''' number will be increased whenever child workspaces will be integrated during regular development or stabilising phases. When once has been decide to make a milestone ready for release, builds with cws integration will be made on the same milestone with just the build number increased.

-- Martin Hollmichel - 14 Aug 2005
[[Category:Build_System]]

Commit Rights

2008-12-29T03:15:44Z

DavidRoss: added Category:Build_System

The procedure which will result in you having your OpenOffice.org account upgraded to '[[DomainDeveloper]]' is currently a bit fuzzy. If you are an active participant in discussions on the mailing list governing the piece of OpenOffice.org which interests you, and you intend to contribute source code to the OpenOffice.org project on a regular basis, chances are that you will need CVS commit rights.

The biggest advantage to having such rights is, of course, the ability to contribute code yourself directly into the CVS repository, without having to attach patches to issues and badger another developer into incorporating your changes.

There are a number of steps required to receive CVS commit rights, and to then activate them so that they are useful to you.

'''Step 1'''. Sign a SCA (downloadable from http://www.openoffice.org/licenses/sca.pdf). Some of the reasons why you must do this are listed at http://www.openoffice.org/FAQs/faq-licensing.html#jca1.

'''Step 2'''. Contribute a couple of quality [[Contributing_Patches|patches]]. That should do the trick to give you some visibility among the project leads. This will results in your account being upgraded to '[[DomainDeveloper]]' status.

'''Step 3'''. To enjoyably work with IssueZilla for patch submissions you might want to make yourself comfortable with issue handling and ask for the privileges to change any part of an issue [http://qa.openoffice.org/helping.html].

'''Step 4'''. Follow the instructions here: http://www.openoffice.org/scdocs/ddSSHGuide.html on how to set up and create an SSH tunnel.

'''Step 5'''. Create a [[CWS]] (Child WorkSpace) for the area of work you intend to do. Directions on how to do this can be found here: http://tools.openoffice.org/dev_docs/ooo-cws-tools-doc.sxw. Note that without CVS commit rights, you cannot create CWSs. Also, if you have already got a specific milestone build, you can avoid the lengthly 'Update' process initiated by 'cwscreate' by using the -f option. This means, for example, if you are working on the OpenOffice 2.0.0 branch, you might already have the SRC680 m130 source. To avoid the CWS toolset updating you to a milestone you already have, you can enter 'cwscreate -f SRC680 m130 <cws name>'.

More details on creating CWSs can be found here: http://tools.openoffice.org/dev_docs/child_workspace_policies.html and here [[CWS]].

'''Step 6'''. Go to the 'Environment Information System' at http://eis.services.openoffice.org/EIS2/servlet/Logon. Browse through the CWSs until you have found the CWS you just created. Once you've found it, click on the link at the top of the page, something like 'SRC680/<cws name>'. Fill in the relevant details and set yourself to be the owner of the CWS (enter your name into the textfield on the left of the dropdown combo box if you aren't already listed).

'''Step 7'''. Commit your code. Find [[DomainDeveloper#QA_Engineers|someone]] on the relevant mailing list to QA your code, assign the issues to them (note that IssueZilla will reset their status to 'New' upon reassignment), then set the QA representative in EIS.

'''Step 8'''. As QA personnel generally don't have the expertise or time necessary to apply your changes and build a patched version of OpenOffice.org, it is necessary to supply them with a build containing your changes. Do a full build, and upload the single download file from your instsetoo_native directory (for example: OOo_2.0_windows_install_en-US.exe) to: http://ooo.services.openoffice.org/pub/OpenOffice.org/cws/upload (note the URL change --[[User:St|stx12]] 17:25, 21 June 2006 (CEST)). You can obtain details on how to upload files to this server from the project lead of of your project, or from one the release engineers.

'''Step 9'''. The QA person will test the bugs you have fixed on a standard milestone build, and on your patched version and confirm that the bugs are fixed and that no new bugs have been introduced. Once the QA process is finished, the QA person will merge your changes into the MWS, and you should see them in the next milestone build, and hopefully the next release.

Happy hacking!
[[Category:Development]]
[[Category:Build_System]]

Optimization Solver

2008-12-29T03:14:57Z

DavidRoss: added Category:Build_System

The goal of this project is to develop a [[Calc]] add-on component that solves a constrained linear or non-linear programming model for an optimum solution. An optimum solution in this case is defined as a feasible point that either maximizes or minimizes the objective function while satisfying all given constraints.

This component is written in C++, so a good knowledge of C++ and design pattern helps tremendously if you want to hack at it. Of course, at least a basic knowledge of operations research is a prerequisite, but you don't necessarily need to be an expert to get involved.

'''Note that this project is now hosted and maintained externally at http://code.google.com/p/scsolver.'''

= Developers =
== Core Developers ==
* [[User:Kohei|Kohei Yoshida]] --- Lead developer

== Contributors ==
* Michael Meeks --- initial integration and general design advice
* Jody Goldberg --- general advice on optimizer development and overall design
* Tor Lillqvist --- win32 build fixes
* Rene Engelhard --- Debian build fixes
* Laurent Godard --- French translation & UNO API help
* Kazunari Hirano --- Japanese translation
* Konstantin Lavrov --- Russian translation & menu integration
* Rolf Meyer --- German translation

=User Interface=
== Menu item location ==
[[image:ScSolverMenu.png|frame|center|Proposed new menu entry location (highlighted) for the solver dialog after integration.]]

== Main Dialog ==
This is a screen shot of the main dialog after it gets launched for the first time. All input fields are empty.
[[image:ScSolverMainDialog.png|frame|center|Main dialog]]
Some general behaviors of this dialog are as follows:
* By default, the focus is on the text input field on the immediate right of the '''Set target cell''' label.
* Under '''Subject to the constraints''', the '''Change''' and '''Delete''' buttons are disabled unless there is a highlighted item in the list box on their left.
* Dismissing the dialog by clicking '''Close''' will not clear user input.

===Widget Table===
{|border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
!width="160px"|Name !! Type !! Description
|-
| Target || text input || This field takes the address of the cell whose value is to be optimized.
|-
| Goal || radio button || This radio button defines whether the target cell value is to be maximized or minimized.
|-
| Variable cell || text input || This field takes the range address of cells that whose values will change during optimization run.
|-
| Constraint box || list box || This list box maintains a list of currently defined constraints.
|-
| Add || button || Add a new constraint to the list of constraints.
|-
| Change || button || Modify the highlighted constraint definition.
|-
| Delete || button || Delete the highlighted constraint definition.
|-
| Solve || button || Optimize the current model.
|-
| Reset || button || Reset all input values. This essentially removes all input values.
|-
| Options || button || Launch a separate Options dialog.
|-
| Save || button || Save the current input values to document's metadata section. Note that clicking this button only puts the data into the document model on memory. The user still need to save the file after clicking this button to permanently save the data to disk.
|-
| Load || button || Load input values from document's metadata section.
|-
| Close || button || Close this dialog.
|-
|}

== Constraint Dialog ==
[[image:ScSolverConstraintDialog.png|frame|center|Constraint input dialog]]

===Widget Table===
{|border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
!width="160px"|Name !! Type !! Description
|-
| Cell Reference || text input || This field takes the address of the cell that represents the left-hand-side (LHS) of a constraint equation. The value of this field must be a valid cell reference.
|-
| Equality || combo box || Defines the relationship between the left hand side (LHS) and the right hand side (RHS) terms.
|-
| Constraint || text input || The right-hand-side (RHS) value of the constraint equation. This can be a cell reference or a numeric value.
|-
|}

== Options dialog ==
[[image:ScSolverOptionsDialog.png|frame|center|Options dialog]]

===Widget Table===
{|border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
!width="160px"|Name !! Type !! Description
|-
| Assume linear model|| check box || When this box is checked, the Solver uses a linear algorithm to solve the current model. When this box is not checked, it uses a non-linear algorithm.
|-
| Allow only positive values|| check box|| When this box is checked, the Solver tries to find a solution while all variables are positive.
|-
| Allow only integer values|| check box|| When this box is checked, the Solver tries to find a solution with all variables being integers. Fractional values are not allowed.
|-
| OK || button || OK button.
|-
| Cancel || button || Cancel button.
|-
|}

= Optimizer Algorithm =

== Linear Programming ==
[http://lpsolve.sourceforge.net/ lp_solve] - a Mixed Integer Linear Programming (MILP) solver supervised by Kjell Eikland and Peter Notebaert - is used as the linear optimizer. lp_solve is released under GPL/LGPL. It provides the revised simplex method and the Branch-and-Bound method for solving pure LP and MILP. The lp_solve project provides excellent documentation for [http://lpsolve.sourceforge.net/5.1/ v5.1 - stable branch] and [http://lpsolve.sourceforge.net/5.5/ v5.5 - latest branch]. The latest package can be downloaded from [http://sourceforge.net/projects/lpsolve/ here].

== Non-Linear Programming ==
Currently a draft implementation of Quasi-Newton with BFGS update is included to optimize unconstrained non-linear models. But this algorithm is still not very robust and needs massive improvement.

= Hacking Solver =

== ooo-build ==
A somewhat easier way to get started is to download and compile [[ooo-build]] from gnome.org Subversion repository. To check out ooo-build, run
<code>[bash,N]
svn co svn://svn.gnome.org/svn/ooo-build/trunk ooo-build
</code>

The Solver code is found in <code>ooo-build/scratch/scsolver</code>. Build ooo-build normally as instructed in [[ooo-build]] page, and you should have a top level <code>scsolver</code> module directory at <code>ooo-build/build/[upstream build name]/scsolver</code>. The upstream build name here refers to the name of a (semi-)latest milestone that the build script has downloaded for you when you ran <code>configure & download</code>.

== Directory Structure ==
The <code>scsolver</code> module is structured as follows:

* '''prj''' - contains files that are necessary for OO.o build process.
* '''source''' - main source directory
** '''inc''' - headers
** '''numeric''' - numerical code (including optimization/matrix codes)
** '''service''' - UNO interface
** '''ui''' - UI code (uses UNO's dialog framework - fairly rudimentary)
** '''tool''' - utility code used throughout the module.
* '''util''' - ?
* '''workben''' - contains files that are not part of the build process.
** '''optimizer'''
*** '''nlp_skel''' - set of skeleton files for independent non-linear optimizer development.
** '''addon_pkg''' - contains files necessary to build a stand-alone Solver as a UNO package.

The backend numerical codes are all found in <code>source/numeric</code>, whereas all the UI related codes are found in <code>source/ui</code>.

== Optimizer Development mini-Framework ==
===How to set up===
There is now a way to develop a new optimization algorithm ''without even touching the main code base!'' This is ideal for someone who just wants to contribute an optimizer code, but doesn't necessarily have time or desire to build the whole OO.o or even to understand the entire [[scsolver]] module. Currently this mini-framework support only NLP algorithm development, but in future support for LP algorithm may be added if there is demand.

An example set of source files is in '''scsolver/workben/optimizer/nlp_skel'''. Make a copy of the whole directory as a sibling to the original directory, change into it and compile by typing '''make'''. This will compile a binary executable named '''skel'''.

Those who are familiar with the Makefile format can read the provided Makefile to see how the example binary is built. Here is the gist of how to build a test optimizer program with your own optimizer code:

* Set the header include path to '''scsolver/source/inc'''.
* Compile the following files from the main source tree:
** '''scsolver/source/numeric/funcobj.cxx''' (includes class '''BaseFuncObj''' - the abstract base class for function object)
** '''scsolver/source/numeric/nlpbase.cxx''' (includes class '''BaseAlgorithm''' - the abstract base class for NLP optimizer)
** '''scsolver/source/numeric/nlpmodel.cxx''' (includes class '''Model''' - the NLP model class)
** '''scsolver/source/numeric/exception.cxx''' (exception classes that the optimizer can throw during optimization run).
** '''scsolver/source/tool/global.cxx''' (some global functions that are used in the above files).
* Provide the following:
** NLP optimizer class derived from '''BaseAlgorithm'''.
** A function object class derived from '''BaseFuncObj'''. This will represent an objective function to optimize.
** The main function.
You then need to link the object files you compiled from the main source tree with the one(s) you compiled from your own code.

Testing of your algorithm against a variety of objective functions can be done by creating multiple function objects and plugging them to the model instance one at a time for optimization run. Refer to the files in the '''nlp_skel''' directory for basic execution flow and how to use the optimizer API.

===Integration===
Once the algorithm beomes good enough to be integrated, .... [to be continued]

= TODO List =
== Core Optimization Algorithms ==

Listed below are algorithms proposed to be included in future versions of Calc Solver. Some are being actively developed, while the others are still in planning.
{|border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
!width="260px"|Name !! Type !! Developer !! Description
|-
|Quasi-Newton Method with BFGS Update || NLP || Kohei Yoshida || Handles only unconstrained non-linear models.
|-
|Generalized Reduced Gradient (GRG) Method || NLP || Leandro Silveira Monteiro da Silva || Excel Solver's default algorithm.
|-
|Hooke & Jeeves Method [[http://www.mylvin.com/do_techref.pdf documentation]] || NLP || Jorma Kuha || non-linear models with upper and lower boundary constraint for each variable.
|-
|[http://en.wikipedia.org/wiki/Levenberg-Marquardt_algorithm Levenberg-Marquardt algorithm] || NLP || || popular in solving curve-fitting equation but may be applicable for general non-linear models. Suggested by Laurent Godard.
|-
|}

==User Interface (UI) Tasks==
{|border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
!width="160px"|Name !! Description
|-
| Solve for a specified value || Add an additional constraint to emulate solving for a specified value.
|-
| Progress window || A separate window with a button to let user abort optimization when the optimization routine is on-going. Such window should also have a progress bar and a text message area. The window will disappears once the Solver finds a solution, or fails to find a solution.
|-
| Restore original values || Provide an option to restore original values when the user aborts the optimization run or the optimizer fails to find a solution.
|-
| Arithmetics on cell (range) address in constraint dialog || Extend the constraint parser to support input such as A2:A4 + B2:B4 > 4. If the sheet name is missing, assume the current active sheet.
|-
| Automatic loading/saving of a model || Currently, loading and saving of a model to its associated document is done by storing the model information as a metadata of the document. It may be useful to automate some of loading and saving of the model.
|-
| Storing multiple models in a single document || Users often want to save multiple models into a single document, whereas currently one model can be saved per document. It would be nice to add the capability of adding multiple models. One way to implement this is to save the model data into a region of cells, which would allow storing as many models as the cells can hold in a single file. It would also be nice to support saving and loading Excel Solver's model format to allow migration from Excel Solver.

Alternatively, we could also have multiple metadata entries with a nice front-end dialog to implement multiple model storage. Which approach should be taken is subject to discussion.
|-
| Options dialog || We need to create an options dialog to let user configure run-time behavior of the solver. At a minimum, the following options need to be present:

* algorithm type (LP, MILP, QP, NLP, ...)
* integer constraint
* positive variable constraint

The options dialog should also have sensible default values since most users just want to run the solver, get the answer and move on.
|-
| Algorithm specific options || Each algorithm requires a different set of parameters to control their run-time behavior. We need to have a good UI to allow algorithm-specific settings. The internal data structure to hold the algorithm options must be designed such that it allows variable number of parameters with names that are specific to each optimizer algorithm.
|-
| String l10n || Framework is now in place, and the strings are translated for French and Japanese. Extend the list of translated languages.
|-
| Redesign constraint dialog || The current constraint dialog, being separate from the main dialog, causes a focus related problem on Linux platform after returning from range selection mode. We should probably embed that UI functionality onto the main dialog to avoid focus problem.
|-
| User-defined Hessian matrix calculation || There are 3rd party high-performance [http://mathworld.wolfram.com/Hessian.html Hessian] matrix calculation program out there. It would be nice to add a hook for such 3rd party software, so that the user can use it to speed up iteration.
|-
| Options page in OO.o's Options dialog || Joachim Lingner presented on the possibility of an extension to use OO.o's Options dialog to store extension specific options. Find a way to take advantage of that framework.
|-
|}

==Miscellaneous==
{|border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
!width="160px"|Name !! Description
|-
| Remove boost ublas dependency || The use of boost ublas in the matrix class is causing difficulty porting to other platforms, especially on Solaris. We need to remove dependency on ublas or make it optional.
|-
| Use UNO component version for internal build || Currently, we maintain two versions of Solver, one for the internal version integrated into ooo-build, and one for external UNO component as an extension to the upstream version. We need to unify these two separate versions by having ooo-build also use the UNO component version to ease maintenance. This page ([[Extensions Integration into Installation Set]]) explains how that can be done.
|-
|}

===Automatic Algorithm Selection===
We may need an optional mechanism to select appropriate optimization algorithms (LP vs QP, linear vs non-linear) based on the characteristics of a given model. But such mechanism should be optional so that the user can still pick and choose desired algorithms.

==Documentation==
{|border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
!width="160px"|Name !! Description
|-
| User's guide || We need a user's guide. We don't even have one. :-(
|-
| How-to docs on hacking || Do we really need this?
|-
|}

= Tasks =

== Build Integration ==

=== Build an extension package in scsolver module ===

Completed.

=== Packaging in scp2 module ===

Completed.

=== UNIX packaging in setup_native module ===

Completed.

=== ooo-build ooinstall integration ===

Currently, when scsolver is built as an uno extension package, <code>ooinstall</code> fails. This needs to be resolved.

=Resources=
==Third Party Library==
Use of a third party library is encouraged, as long as there is no licensing conflict with OpenOffice.org. We cannot integrate GPL'ed code due to licensing incompatibility. LGPL-licensed library can be used, as long as such library is de-coupled and completely isolated from the core component code. BSD-licensed code can be used in a similar fashion, but due to its advertizing clause it cannot be used within the core component that needs to become a part of OO.o (Sun's requirement?). So, both LGPL and BSD codes must be completely decoupled from the core Solver code.

TODO: How about CPL? Does it pose any constraint as far as integration goes? --[[User:Kohei|Kohei]] 06:16, 25 April 2006 (CEST)

If you know of any other third party libraries not listed here, feel free to add it below.

;Free Software
*[http://www.gnu.org/software/glpk/glpk.html GLPK] (GPL)
*[http://sourceforge.net/projects/lpsolve lp_solve] (GPL/LGPL)
*[http://www.coin-or.org/index.html COIN-OR] (CPL)
*[http://www.scipy.org/SciPy SciPy] - Scientific Tools for Python released under BSD license. Currently for Python only (?)
*[http://abel.ee.ucla.edu/cvxopt/applications/openoffice-org-spreadsheet-plugin/ CVXOPT] - Convex optimization written in Python.
*[http://www.koders.com/cpp/fidCD90612B92AAF8550D835237BDD32397256F873D.aspx Non-Linear FitLM]
*[http://www.koders.com/cpp/fid6D3F5EFA327A3D6721FE7E6E713B782FF47286F4.aspx?s=gmres GMRES]
*[http://ascendwiki.cheme.cmu.edu/Survey_of_optimisation_software another list of free and non-free optimisation solvers from the ASCEND project]

;Commercial
*[http://www.dm.unipi.it/cluster-pages/mpsolve/index.htm MPSolve]
*[http://www.ilog.com/products/cplex/ cplex]
*[http://lindo.com/products/api/dllm.html LINDO API]
*[http://www.mosek.com/ MOSEK]

==Links==
* [http://www.utexas.edu/courses/lasdon/design3.htm Design and Use of the Microsoft Solver]
* [http://www.go-oo.org/bonsai/cvsquery.cgi?treeid=default&module=all&branch=cws_src680_scsolver02&branchtype=match&dir=sc%2Fscsolver&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=week&mindate=&maxdate=&cvsroot=%2Fvar%2Fcvsup All checkins to the CVS repository in the last week]
* [http://kohei.us/ooo/solver/ Kohei Yoshida's Solver Page]
* [http://www.mylvin.com/ Jorma Kuha's Direct Optimizer Page]
* [http://www-fp.mcs.anl.gov/otc/Guide/index.html NEOS Guide]
* [http://support.microsoft.com/kb/q214115/ XL2000: Solver Uses Generalized Reduced Gradient Algorithm]
* [http://math-atlas.sourceforge.net/ Automatically Tuned Linear Algebra Software (ATLAS)]
* Learn to program a simple calc [[SimpleCalcAddIn|Addin]] in C++
* Learn to program a calc [[CompleteAddIn|Addin]] in C++
* overview: [http://www.mat.univie.ac.at/~neum/glopt/software_l.html local optimizers] and [http://www.mat.univie.ac.at/~neum/glopt/software_g.html global optimizers]

[[Category:Calc|Statistics]]
[[Category:To-Do]]
[[Category:Add-On]]
[[Category:Build_System]]

Performance

2008-12-29T03:12:51Z

DavidRoss: added Category:Build_System

Performance Lead: Liheng Performance Co-Lead: Matthias Huetsch
*We have new maillist: [mailto:performance@tools.openoffice.org performance@tools.openoffice.org]. Please send mail to new maillist so that everyone concerned can see it.
*As George Ou has famously said, "It doesn't matter how fast the CPU is, OpenOffice is just bloated."
== Project Summary ==
Project will achieve the goal: maintain good performance and evaluate OOo.

== OOo Issues ==
=== Issues from End-User ===
...
=== Known areas for improvement ===

==== Configmgr'''[new]''' ====

* [http://wiki.services.openoffice.org/wiki/Configmgr_Refactoring Configmgr Refactoring]
* CWS[DEV300/configtune00]

==== Component issues ====

* [[Calc/To-Dos/Performance|Calc]] - lots to do
* [[Writer_Performance|Writer]]
* [[Impress_Performance|Impress]]
* [[Base_performance|Base]] - lots to do

==== system issues ====
* Linux / Linking - relocation processing is very slow ( [http://ooocon-ljudmila.kiberpipa.org/media/Bloated_Michael_Meeks/video.ogg ogg video], [http://go-oo.org/~michael/performance.odp odp slides] ) several possible ways to fix that
** re-ordering symbol & elf hash tables to improve cache locality, lots of good & simple ideas here.
** -Bdirect implementation [http://sourceware.org/ml/binutils/2005-10/msg00436.html] - gaining little traction.
** exporting Vague linkage more cleverly & using RTLD_LOCAL where possible
** basic linker optimizations:
*** don't export *UND* in .hash table
*** sort syms & dynsym entries more intelligently
*** .hashvals optimisation
* Linux / I/O scheduling & pre-loading is poor

==== General I/O & memory issues ====
* Image strip layout - our images strips are huge & unwieldy, layed out [http://blogs.msdn.com/oldnewthing/archive/2005/08/05/448073.aspx horizontally] and are 'cached' in scattered files - this is fixed in CWS ka009, which never seems to get integrated.
* Configuration information scattered across many files
* UI configuration - tons of scattered files
* .rdb files - loads of empty space, mmap + random access pattern

== Helpful Tooling and Resources ==

=== Test Environment ===
Popular reference configuration(use similar env on Hamburg and Beijing)
CPU: Core2 Duo 1.5~2G
Memory: 512M
OS: WindowsXP HOME

=== Test & Tuning Tools ===

* [[cold-start-simulator|Linux/cold-start]] simulator
* [[relocstat]] - dump relocation data
* [http://tools.openoffice.org/profiling/profiling-howto.html RTL_LOGFILE] - export RTL_LOGFILE=/tmp/foo
* [[valgrind]] - debug / trace memory usage
* [[speedprof]] - a quick / hackish sampling full-stack-trace profiler & visualisation tool
* [[APPR]] - a performance regression tool suite
* [[Performance Related Test Documents]]

=== Benchmarks & Description ===
If you have some benchmarks, share them here!

* [http://www.oooninja.com/2008/09/fastest-openofficeorg-edition-benchmark.html The Fastest OpenOffice.org Edition] comparison of four 2.4.1 editions on Fedora 9
* [http://www.oooninja.com/2008/05/openofficeorg-getting-faster-benchmark.html Is OpenOffice.org Getting Faster?] Comparison of 11 versions from 1.1.5 to 3.0.0 alpha

== Performance Test Results Distribution ==

=== Test results for Different Versions ===
* [http://www.oooninja.com/2008/05/openofficeorg-getting-faster-benchmark.html Is OpenOffice.org Getting Faster?] benchmarks 5 common operations for OpenOffice.org versions 1.1.5 through 2.4.0 and DEV300_m3
...

=== Contrastive Data & Analysis ===
...

== Work List and Progress ==
* Configmgr re-factor, reduces locking overhead & memory usage cf. CWS configrefactor01
* [[XML Load]]
* [[DbConfig|Config refactor]] - reduce seeks/files, better caching
* [[Disk Access]]
* -Bdirect linking
* FIXME - Malte - we should really have your list embedded here ...

== Integrated improvements ==
* [[Integrated_Performance_Improvements]]

== Other Pages ==
This Wiki page should become the ultimate authority on performance issues. Meanwhile, here are links to performance informationat other places
* [http://tools.openoffice.org/performance/ OpenOffice.org Performance Tuning page]
* [http://sw.openoffice.org/drafts/optimization.html Writer (SW, XML, Math, Linguistic) specific Optimizations]
* [http://tools.openoffice.org/performance/performance-activities-overview.html Current & Planned Performance Activities]

[[Category:Development]]
[[Category:Performance]]
[[Category:Database]]
[[Category:Effort]]
[[Category:Build_System]]

LinuxIntelEnv.Set

2008-12-29T03:09:52Z

DavidRoss: added Category:Build_System

== What it's for ==

This file is used to ensure a repeatable configuration for building OO.o.
It achieves this by taking a snapshot of your environment and freezing all your important variables. There are two versions: LinxuIntelEnv.Set (for csh/tcsh [as used in the build itself]) and LinxuIntelEnv.Set.sh (for use by all right-minded bash users).
Before you do an [[Hacking#My_first_hack|incremental]] build you to 'source' this:
source ./LinuxIntelEnv.Set.sh
dmake

== Issues ==

These files contain the absolute path of the build - thus when you copy or move the build, you need to use the [[relocate]] tool to relocate it to the new position.

== What it looks like ==

ENABLE_CUPS="TRUE"
ENABLE_FONTCONFIG="TRUE"
ENABLE_DIRECTX=""
VC_STANDARD=""
WITH_GPC="NO"
WITH_LIBART="NO"
... on and on ...
export ... ENABLE_CUPS ENABLE_FONTCONFIG ENABLE_DIRECTX ...

[[Category:Development]]
[[Category:Build_System]]

Writing warning-free code

2008-12-29T03:04:33Z

DavidRoss: added Category:Build_System

We are currently on the way towards a completely warning-free OOo C/C++ code base. And once we have reached that, we want to keep the code clean!

We reached a first milestone by integrating CWS [http://eis.services.openoffice.org/EIS2/servlet/cws.showCWS?Id=2903&Path=SRC680%2Fwarnings01 warnings01] into SRC680m173. Since then, and at least on the <code>unxlngi6</code>, <code>unxsoli4</code>, <code>unxsols4</code>, and <code>wntmsci10</code> platforms, the C/C++ compilers are used with rather aggressive warning levels, and in most CVS modules warnings are treated as errors that break the build. Some CVS modules have not yet been made warning-free.

==What changed?==

Since SRC680m173, any new or modified C/C++ code that produces warnings will break the build. (Unless, of course, you fail to pass <code>--enable-werror</code> to <code>configure</code>.) Ideally, to be sure that integrating a CWS will not break the build, the CWS should now be built on every warning-free platform (i.e., at least <code>unxlngi6</code>, <code>unxsoli4</code>, <code>unxsols4</code>, and <code>wntmsci10</code>), with all supported compiler versions, in both product and non-product variants, and with and without the <code>debug=x</code> build switch before nominating it for integration. Practically, a reasonable subset of these will have to suffice.

For <code>unxlngi6</code>, we concentrated on GCC 3.4.1, GCC 4.0.2/4.0.3, and GCC 4.1.1, while other GCC versions probably produce slightly different warnings (that could break the build now on those GCC versions).

Porters are encouraged to make additional platforms warning-free. Since most ports are using GCC, there should not be too many surprises. Any necessary changes to the platform-specific <code>.mk</code> file in <code>solenv/inc</code> can be modelled after <code>solenv/inc/unxlngi6.mk</code>. In short, you need a bunch of <code>CFLAGSxxx</code> (see [http://www.openoffice.org/servlets/ReadMsg?list=interface-announce&msgNo=758 interface-announce C/C++ compiler warnings]) and <code>MODULES_WITH_WARNINGS</code> or <code>COMPILER_WARN_ERRORS</code> (see [http://www.openoffice.org/servlets/ReadMsg?list=interface-announce&msgNo=942 interface-announce MODULES_WITH_WARNINGS]).

The <code>wall=x</code> build switch no longer has any effect on the warning-free platforms. Once all platforms are warning-free, we can remove it completely.

==The missing modules==

If your job is to clean up a given CVS module, here are some practical guidelines:
* Remove the module from the <code>MODULES_WITH_WARNINGS</code> list in the platform-specific <code>.mk</code> files in <code>solenv/inc</code>.
* Make sure your module builds and delivers successfully with <code>build && deliver</code> (and all the variants mentioned above).
* If your module contains external code which we do not want to clean up, set <code>EXTERNAL_WARNINGS_NOT_ERRORS := TRUE</code> at the beginning of the corresponding <code>makefile.mk</code>, so that warnings do not lead to errors there.
* In any case, for any header file delivered from your module, make sure that <code>testhxx</code> on the delivered header file is successful. (Note that <code>testhxx</code> only works for headers delivered to the solver, not for local headers within a CVS module, as it calls the compiler with only a fixed set of include directories.)
* If you encounter a warning that cannot reasonably be worked around, discuss that problem on <code>dev@openoffice.org</code>. One outcome of that discussion can be that we globally disable that particular warning. To see which warnings are already globally disabled on a given platform, look at the settings for <code>CFLAGSWARNCC</code>, <code>CFLAGSWARNCXX</code>, <code>CFLAGSWALLCC</code>, and/or <code>CFLAGSWALLCXX</code> in the platform-specific <code>.mk</code> file in <code>solenv/inc</code> (<code>unxlngi6.mk</code>, <code>unxsoli4.mk</code>, <code>unxsols4.mk</code>, and <code>wntmsci10.mk</code>).

See the current [[Warning-free_code_status|warning-free code status]].

==Tips for Warning-free code==

The following is a list of issues you might come across when making existing
code warning-free, or when writing new, warning-free code:

===Integral conversions===

Sometimes, a cast between integral types is needed to avoid a warning. In such a case, use <code>sal::static_int_cast</code> (C++) or <code>SAL_INT_CAST</code> (C) to make that cast stick out—it will need to be adapted when the type of any of the involved expressions changes later on:
<source lang="cpp">
sal_Int32 n;
std::vector<char> v;
if (n >= 0 && sal::static_int_cast<sal_uInt32>(n) == v.size()) ...
</source>

Note that you might get the warning C4244 (possible loss of data) on Windows also for the following situation:
<source lang="cpp">
short a = 0, b = 0;
a += b; // warning C4244 on Windows
</source>
This is because <code>a</code> and <code>b</code> are converted to <code>int</code>, then added and the result is then again cast back to <code>short</code>. This is especially nasty, as it also happens when you use <code>xub_StrLen</code>, but only if it is a typedf to <code>USHORT</code> and not to <code>sal_uInt32</code>, i.e. only as long as <code>STRING32</code> is not defined in solar.h.
The warning does not occur when you use <code>operator+</code> instead of <code>operator+=</code>.
<source lang="cpp">
short a = 0, b = 0;
a = a + b;
</source>

===Invalid enum case values===

Code like
<source lang="cpp">
enum E { A=1, B=2, C=4 } e;
switch (e) {
case A: ...
case B|C: ...
}
</source>
will cause <code>wntmsci11</code> to complain with <code>warning C4063: case '6' is not a valid value for switch of enum 'E'</code>. This can be worked around by promoting <code>e</code> to is underlying integral type:
<source lang="cpp">
...
switch (+e) {
...
</source>

----

I think the compiler warning is perfectly valid there (although a little misleading). There is a simple reason for it: because of C++ computing rules for operator|, the second case statement (B|C) has type int and value 6, whilst compiler expects it to have type E. There is not automatic conversion from int to enumeration type; even if there were one, no enumerator from E has value 6. So, in the "work around", the second case statement is actually ''unreachable'' (well, suppose there are no explicit casts in assignment to e)!

What the author probably wanted is
<source lang="cpp">
switch (e) {
case A: ...
case B: // No code, falls through to the next statement
case C: ... // The code of the original B|C branch
}
</source>

-- dt

===Casting between pointer and integer types===

====C++====

* From pointer-to-(possibly-cv-qualified-)void-or-object type <code>P</code> to unsigned integral type <code>U</code>:
<source lang="cpp">
P p;
U u = sal::static_int_cast(reinterpret_cast<sal_uIntPtr>(p));
</source>

* From unsigned integral type <code>U</code> to pointer-to-(possibly-cv-qualified-)void-or-object type <code>P</code>:
<source lang="cpp">
U u;
P p = reinterpret_cast(sal::static_int_cast<sal_uIntPtr>(u));
</source>

* From pointer-to-(possibly-cv-qualified-)void-or-object type <code>P</code> to signed integral type <code>S</code>:
<source lang="cpp">
P p;
S s = sal::static_int_cast<S>(reinterpret_cast<sal_IntPtr>(p));
</source>

* From signed integral type <code>S</code> to pointer-to-(possibly-cv-qualified-)void-or-object type <code>P</code>:
<source lang="cpp">
S s;
P p = reinterpret_cast(sal::static_int_cast<sal_IntPtr>(s));
</source>

====C====

* From pointer-to-(possibly-qualified-)void-or-object type <code>P</code> to unsigned integer type <code>U</code>:
<source lang="c">
P p;
U u = SAL_INT_CAST(U, (sal_uIntPtr) p);
</source>

* From unsigned integer type <code>U</code> to pointer-to-(possibly-qualified-)void-or-object type <code>P</code>:
<source lang="c">
U u;
P p = (P) SAL_INT_CAST(sal_uIntPtr, u);
</source>

* From pointer-to-(possibly-qualified-)void-or-object type <code>P</code> to signed integer type <code>S</code>:
<source lang="cpp">
P p;
S s = SAL_INT_CAST(S, (sal_IntPtr) p);
</source>

* From signed integer type <code>S</code> to pointer-to-(possibly-qualified-)void-or-object type <code>P</code>:
<source lang="cpp">
S s;
P p = (P) SAL_INT_CAST(sal_IntPtr, s);
</source>

===Pointer to function===

A pointer to function is not compatible with a pointer to object, so code like
<source lang="cpp">
void * osl::Module::getSymbol(rtl::OUString const &);
typedef void (* MyFunc)();
MyFunc f = module.getSymbol("myFunc");
</source>
will not compile. The only places were converting between pointer to function and pointer to object (typically <code>void *</code>) should be necessary are <code>osl::Module::getSymbol</code> and <code>osl::Module::getUrlFromAddress</code>, and in both cases there are additional functions (<code>osl::Module::getFunctionSymbol</code> and an overload with <code>oslGenericFunction</code> of <code>osl::Module::getUrlFromAddress</code>) that handle the problem internally. Use them!

===Name hiding===

In C++, use a <code>using</code> declaration to make visible (virtual) function declarations from a base clase that would be hidden by a function declaration in a derived class:
<source lang="cpp">
class Base {
public:
virtual void f(int);
virtual void f(double);
};
class Derived: public Base {
public:
using Base::f;
virtual void f(int);
};
</source>

Make sure to apply the correct access control to the <code>using</code> declaration:
<source lang="cpp">
class Base {
protected:
void f();
};
class Derived: public Base {
public:
void f(int);
protected:
using Base::f;
};
</source>

If you can, avoid such constructs as in the above example, by chosing different names for the two functions <code>f</code>. If on the other hand the function f is clearly meant to be overloaded, then make all instances of <code>f</code> virtual in the base class.

===Unused parameters===

There are three cases where a parameter of a function is not actually used in the definition of the function:

* The function has to have a certain signature (it is a virtual function, shall be used with a certain function pointer type, or is part of a stable API that cannot be changed). In those cases, leave out the paramter name in the function definition (C++) or use
<source lang="cpp">
(void) paramName; /* avoid warning about unused parameter */
</source>
at the start of the function body (C).

* The function is created by the Macro IMPL_LINK( Class, Method, ArgType, ArgName ) from tools/inc/link.hxx or similar. Use EMPTYARG as Parametername as in
<source lang="cpp">
IMPL_LINK( Class, Method, ArgType, EMPTYARG )
</source>
EMPTYARG is defined empty, so this will result in leaving out the parameter name as suggested above.

* The function uses the paramter only in an <code>#ifdef</code>-block, or only in <code>OSL_ASSERT</code> etc. debug code. If the first case occurs in C++ code, fix it by using the same <code>#ifdef</code> around the parameter name in the function header. In all other cases, fix it by using
<source lang="cpp">
(void) paramName; /* avoid warning about unused parameter */
</source>
at the start of the function body.

* The function once used the parameter, but does no longer do so. In that case, clean up the function declaration and all uses of the function.

===When all else fails===

There are cases where the only sensible solution is to suppress warnings for a given chunk of code:

* As explained above, in external code which we do not want to clean up, use <code>EXTERNAL_WARNINGS_NOT_ERRORS := TRUE</code> so that warnings do not lead to errors there.

* Header files included directly from the system, or header files delivered from external code included in the OOo code base but which we cannot reasonably make <code>testhxx</code>-clean: Surround that code (e.g., the <code>#include</code>-directives for those headers) by
<source lang="cpp">
#if defined __GNUC__
#pragma GCC system_header
#elif defined __SUNPRO_CC
#pragma disable_warn
#elif defined _MSC_VER
#pragma warning(push, 1)
#endif
</source>
and
<source lang="cpp">
#if defined __SUNPRO_CC
#pragma enable_warn
#elif defined _MSC_VER
#pragma warning(pop)
#endif
</source>
(probably together with an explanatory comment). Due to the nature of the GCC solution, this does not work directly within the compilation unit's main (<code>.c</code>, <code>.cxx</code>) file, only within a (<code>.h</code>, <code>.hxx</code>) file included directly or indirectly. Even more important, because the <code>system_header</code> pragma affects the ''rest of the current header'', the entire warnings guard mechanism should be separated into a ''header file on its own'', including just the file in question. From the original file then include that wrapper file.

* Code generated by <code>flex</code> or <code>bison</code>: The solution here is similar to the solution in the previous item—disable all warnings in the generated code. However, this has two implications: For one, it means that also all warnings from our client code integrated into the <code>flex</code>/<code>bison</code> output are suppressed; this is not really that large an issue, given the relatively small number of <code>flex</code>/<code>bison</code> files we use. For another, due to the nature of the GCC solution, it means that you need to introduce a wrapper file. The individual steps for a given <code>flex</code>/<code>bison</code> file named <code>example.ly</code>, translated to <code>$(MISC)$/example.cxx</code>, are as follows: First, change <code>example.ly</code> by adding
<source lang="cpp">
#if defined __GNUC__
#pragma GCC system_header
#elif defined __SUNPRO_CC
#pragma disable_warn
#elif defined _MSC_VER
#pragma warning(push, 1)
#endif
</source>
(probably together with an explanatory comment) at the very end of the initial <code>%{...%}</code> section (for <code>_MSC_VER</code>, <code>#pragma warning(push, 1)</code> might not disable all the warnings that occur; in that case, add <code>#pragma warning(disable: NNN1 NNN2 ...)</code> after it to disable specific warnings <code>NNN1</code>, <code>NNN2</code>, etc.). Second, create a new file named <code>wrap_example.cxx</code> in the same source directory as <code>exmaple.ly</code>, containing
<source lang="cpp">
#include "example.cxx"
</source>
Third, change the corresponding <code>makefile.mk</code> by adding
<code>[]
INCPRE=$(MISC)
</code>
to the top, by changing occurences of <code>example.obj</code> to <code>wrap_example.obj</code>, and by adding
<code>[]
$(OBJ)$/wrap_example.obj: $(MISC)$/example.cxx
</code>
and/or
<code>[]
$(SLO)$/wrap_example.obj: $(MISC)$/example.cxx
</code>
at the bottom.

[[Category:Development]]

[[Category:Education]]
[[Category:Build_System]]

GNU Linux Sparc Porting

2008-12-29T03:04:04Z

DavidRoss: added Category:Build_System

The objective is to maintain the upstream sources so that the GNU/Linux [http://en.wikipedia.org/wiki/SPARC SPARC] platform can be packaged for example by Debian, Gentoo, and others. Also to provide an upstream "benchmark" version that can be installed for checking who owns any bugs, while not interfering with the distribution's installed packages. For GNU/Linux SPARC all Java building is done with gcj.

Other projects that need more work:

* fix multimedia
* more qa needs to be done

The latest upstream release is on OpenOffice.org mirrors under contrib/linuxsparc

== What is SPARC? ==

SPARC means Scalable Processor ARChitecture [http://www.sparc.org/ about SPARC]

The most common hardware implementation is done by [http://www.sun.com/ Sun].

Most GNU/Linux SPARC users are running second-hand hardware which may be quite old and the installed user base and developer resources are relatively small.

There are 2 main flavours of SPARC hardware:

32 bit known as sparc (uname -m returns sparc)
64 bit known as sparc64 (uname -m returns sparc64)

GNU/Linux is ported to run on both sparc and sparc64, there are separate kernels for sparc and sparc64 but the majority of user software is designed to run on both sparc and sparc64.

For example on my system I can find these files:
jim@sun:/boot$ file vmlinux-2.6.13
vmlinux-2.6.13: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV), statically linked, not stripped

jim@sun:~/o147/program$ file soffice.bin
soffice.bin: ELF 32-bit MSB executable, SPARC, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped

So the first issue for porting is, how to build the 32 bit product on a 64 bit system? The simple and correct method is to build in a shell where the command "uname -m" will return "sparc" on a "sparc64" machine. This is achieved by using the command "sparc32 bash" or "linux32 bash" to get the shell for building. See here for a [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=251149 more authoritative comment]

== Which shell to use for building, sparc or sparc64? ==

But for maintaining the port I prefer to not use the sparc shell (from the "linux32 bash" command) because that might hide some bugs or bad behaviour. For GNU/Linux Sparc the 32 bit product can be built in the sparc64 shell, by the simple method of:

compiler flag "-m32" will tell gcc to build sparc and not sparc64

In the past bad behaviour occurred when a module ignores the configured compiler path or compiler flags. For example:

configured to build with "/usr/local/4.1/bin/gcc -m32"
module builds with a different "gcc" for example /usr/bin/gcc"

Currently there are no examples of this bad behaviour. This will not be easily noticed unless all alternative possible compilers are excluded from the configured environment path. Still there remains a risk that a module will seek "/usr/local/bin/gcc" and find it. This sometimes seemed to involve using libtool which may have some defaults configured on the build machine?

In summary, building in the sparc shell is the simple and correct method, but building in a sparc64 shell is better for finding bugs.

== Specific code for GNU/Linux SPARC ==

There are only a small number of places where GNU/Linux SPARC requires different code than used by other GNU/Linux platforms. The following list is not complete but it provides some examples and will be gradually increased. For a full history of the GNU/Linux SPARC port just query Issuezilla for issues where sparcmoz has reported or commented.

===Platform Make file===
Various compiler and other flags are set in the platform Make file solenv/inc/unxlngs.mk. That file is kept as close as possible to solenv/inc/unxlngi6.mk but the following differences are important:

If the assembler is called directly, it must build for sparc v7 by default (could use v8 safely?) and not v8plus or v9
# mk file for unxlngs
ASM=$(CC)
AFLAGS=-Wa,-K,PIC -c $(CDEFS)

Code must be compiled with -fPIC, as -fpic will not do for sparc/sparc64
PICSWITCH:=-fPIC

Platform specific identifier for shared libs
DLLPOSTFIX=ls
DLLPRE=lib
DLLPOST=.so

===Module sal===

GNU/Linux SPARC did not provide an implementation of frame.h that was needed for backtrace functions. It was also needed to provide the backtrace function without using the crash reporter. (This is out of date - it is no longer required. I need to remove this code from OOo sources). Backtrace is currently broken, possibly something here:
sal/osl/unx/backtrace.c
sal/osl/unx/backtrace.h

The following code provides runtime detection of the user hardware (sparc or sparc64) and loads some different code at start up.
sal/osl/unx/util.c
sal/osl/unx/asm/interlck_sparc.s

This file is modified to build the preceding files
sal/osl/unx/makefile.mk

===Module sc===
A number of runtime isssues (crash) were found with the early builds of the spreadsheet using gcc 3.2. A workaround was found to compile certain files with no optimisation. A review of the code suggests similar issues were found with other platforms, but in different files. The files were found fairly quickly by using a binary search pattern to locate the files that caused the crashes (build - test - crash - build half the files again without optimisation). Fortunately this type of work-around is supported by the build system environment variables NOOPTFILES and EXCEPTIONSNOOPTFILES! It is possible some of these issues have gone away with later compilers, further investigation is needed. Refer to the source code as follows:

sc/source/core/data/makefile.mk:.IF "$(OS)$(COM)$(CPUNAME)"=="LINUXGCCSPARC"
sc/source/core/tool/makefile.mk:.IF "$(OS)$(COM)$(CPUNAME)"=="LINUXGCCSPARC"
sc/source/filter/excel/makefile.mk:.IF "$(OS)$(COM)$(CPUNAME)"=="LINUXGCCSPARC"
sc/source/ui/unoobj/makefile.mk:.IF "$(OS)$(COM)$(CPUNAME)"=="LINUXGCCSPARC"
sc/source/ui/view/makefile.mk:.IF "$(OS)$(COM)$(CPUNAME)"=="LINUXGCCSPARC"

A typical example follows from sc/source/core/data/makefile.mk:

.IF "$(OS)$(COM)$(CPUNAME)"=="LINUXGCCSPARC"
NOOPTFILES= \
$(SLO)$/column2.obj \
$(SLO)$/column3.obj \
$(SLO)$/table3.obj \
$(SLO)$/table4.obj \
$(SLO)$/documen4.obj \
$(SLO)$/conditio.obj \
$(SLO)$/validat.obj
EXCEPTIONSNOOPTFILES= \
$(SLO)$/cell.obj
.ELSE
EXCEPTIONSFILES+= \
$(SLO)$/cell.obj
.ENDIF

===Module bridges===
The bridges code in bridges/source/cpp_uno/gcc3_linux_sparc is copied exactly from the corresponding gcc3_linux_intel and only the assembler snippets have been changed.

TODO: describe bridges code

TODO: configuration, installation

== Building OOo on GNU/Linux SPARC with OpenJDK ==

This is work in progress. The first step is to build OpenJDK.

No distributions are shipping OpenJDK for sparc yet (please correct me if I'm wrong ;)

On Debain/sid I have got the build dependencies OK, configured and started ./make for icedtea6 from icedtea.classpath.org

For the first build I will play it safe - building in a sparc shell:

$ linux32 bash
$ ./configure
$ ./make

Progress will be tracked at [http://qa.openoffice.org/issues/show_bug.cgi?id=91484 issue 91484]

== Building with GCC 4.1.2 (preview) ==

This section is deprecated - the SPARC build works fine on debian with java-gcj-compat.

''I don't mention here any issues that affect gcc < 4.1 ''

I normally build using debian gcc/ecj but if it is desired to build gcc too, then GCC 4.1 is built using gcc.gnu.org sources checked out by svn from gcc-4_1-branch and installed in /usr/local/4.1 with these configure flags: --prefix=/usr/local/4.1 --enable-java-awt=gtk,xlib

Also need put ecj.jar in the source file - see gcc instructions for building gcj with ecj

=== Step 1: get a version of gcc with suitable gcj ===

In my case I get gcc version that builds with ecj, and build gcc into /usr/local/4.1

=== Step 2: set up the required commands for build tools ===

Note that the required compiler can be specified by setting environment variables CC and CXX before running configure. The code expects some "java" commands to be available in the PATH: java jar javadoc. Different distributions provide those commands in different ways, but when using one's own gcc built from upstream sources then gcc provides instead the corresponding commands: gij fastjar gjdoc. There is an issue with internal ant commands in build files in xmerge so that a symbolic link is needed: javadoc-> gjdoc

=== Step 3: configure ===

In my case the configure commands may be like this:

$ export CC="ccache /usr/local/bin/gcc -m32"

$ export CXX="ccache /usr/local/bin/g++ -m32"

$ ./configure --with-jdk-home=/usr/local/4.1 \

--with-ant-home=/usr/local/apache-ant-1.6.5 \

--enable-crashdump=STATIC --enable-symbols=SMALL --enable-build-mozilla \

--with-package-format=rpm \

--with-alloc=system

Now if configure reports that "ant does not work" try this: export PATH=/path/to/gcj:$PATH

Some additional [http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=16375 hoops to jump through] for the crash reporter

=== Step 4: Build ===

berkeleydb - see [http://qa.openoffice.org/issues/show_bug.cgi?id=54657 issue 54657]
berkeleydb has hardcoded "java" command with fallback to JAVA but environment defines JAVAINTERPRETER. the fix is in cws_src680_maho1

sal: Since m166 some memory alignment problem will cause bus errors (signal 10 or SIGBUS) on GNU/Linux SPARC.
This is referenced at [http://www.openoffice.org/issues/show_bug.cgi?id=65788 issue 65788] and the workaround is configure --with-alloc=system

moz: some recent change in GCC? (4.1.2) mimeExternalObjectClass' with 'C++' linkage
mimemult.cpp:76: error: conflicts with new declaration with 'C' linkage
[http://qa.openoffice.org/issues/show_bug.cgi?id=66906 issue 66906] (fixed?)

== Installing from rpm without root access ==

The GNU Linux Sparc packages from contrib/linuxsparc should not interfere with installations provided by the various distribution packagers such as debian, gentoo etc. Therefore the supplied rpms can be installed in the user's home directory using the install_linux.sh script which is available on mirrors at pub/OpenOffice.org/developer/install_scripts/

The rpm command is required but root access is not required

[[Category:Porting]]
[[Category:Build_System]]

Infrastructure Problems

2008-12-29T03:03:38Z

DavidRoss: added Category:Build_System

== OOo's SourceCast Instance ==

The OOo instance of SourceCast is based on an extremely old version (2.6), the equivalent up-to-date product is 'CollabNet Enterprise Edition'. It is believed that many problems of the current infrastructure are fixed in the latest versions of this (ver 4.0). The use of 'SourceCast' hereinafter referrs to the (patched & older) OOo version of this infrastructure.

SourceCast provided services are typically extremely unresponsive - it typically taking longer to log-into SourceCast than search the entire-web at google.com with some complex search. High latencies are also sporadic - there are unpredictable periods of low & high latency.

=== Scaling issues ===

Under heavy load - such as close to a release - it is common for SourceCast to become almost totally unresponsive & unusable, sometimes for days.

=== Constant re-login ===

For unknown reasons SourceCast login infrastructure [http://qa.openoffice.org/issues/show_bug.cgi?id=34822 requires] that you re-log-in when closing and restarting your browser. It's hard to quantify quite how frequently, but normally for every new bug filed it is necessary to go to the IssueZilla page, log-in, hit back, hit refresh - adding (if you're lucky) 15seconds or so to any bug filing - prolly more. This latency is not present with other bugzilla derived products. Of course, developers Issue access patterns are typically not those of the casual tester, or heavy SourceCast user - they spend an hour or more fixing a bug, then return to mark the bug fixed (sometimes from one of their other desktop machines) - at which point; re-login is forced on them. A persistant, long-lived client-side authentication cookie would remove this problem entirely.

Some people report not being able to reproduce this frequent re-login issue; it is possible the bug relates closely to the end users' network topology, such as NAT gateways etc. Or - as a serious discussion without exaggeration seems to reveal - it's just that a session cookie is used and not a persistent one.

=== CVS ===

CVS is extremely slow ({{Bug|24771}}). This problem is compounded by the OO.o source code being extremely large it is true.
However an order of magnitude slow-down is due to a simple source-cast design bug of having the CVS .rcs files on a different disk to that of the CVS daemon itself - adding untold latency to each NFS file operation.

Access control - the CVS repository was by default constructed in such a way as to deny even those granted access commit writes to large chunks of it. This was coupled to the formal role request/granting process. Similarly the CVS structure itself (split into separate top-level modules per-project) is confusing (not matching the source directory layout), also making it not possible to have a 'familiar' structure, configure / autogen.sh / README / BUILDING etc. in the top-level directory. [ at least without breaking other CVS operations ]. This artefact also makes the real CVS structure (as seen in LXR etc.) hard to navigate & confusingly different.

CVS also has rather a [http://qa.openoffice.org/issues/show_bug.cgi?id=23306 habit] of loosing cvs tags cf. the [[CvsFAQ]]

== Searching ==

There is no ability to search openoffice.org without logging in, there's no good reason for that. More seriously googling doesn't show any results from within the mailing lists! Making them nigh on useless as a resource.

{{Bug|58310}} has been raised to address this issue. The Googlebot web crawler is well behaved, and respects the overly restrictive 'robots.txt' files scattered around the OpenOffice.org website, such as this one: http://tools.openoffice.org/source/browse/tools/www/robots.txt.
 
The consequences of a [http://qa.openoffice.org/robots.txt reduced robots.txt] file for [[Infrastructure_Problems#Scaling_issues|scaling issues]] are checked for the qa project starting 2005-11-21.

Hint: as a workaround, for fast and easy mailing list searches and a threaded archive go to mail-archive.com, e.g. http://www.mail-archive.com/dev@openoffice.org/, combined with Google this leads to something like ''site:mail-archive.com/dev@openoffice.org YourSearchTerm'', which works in many cases. Of course there are also others like Gmane and such.

== Projects & roles ==

There is an extremely formal project / role structure built on SourceCast's features in this area, with various roles being requested, and granted via E-mail round-trips. Thankfully this doesn't impact CVS access these days - with broadly unconstrained CVS accounts being the norm.

== IssueZilla ==

This is rather old and nasty compared with the excellent modern Bugzilla releases, that shows in lots of places - file typing, uploads, comment management, well - tens of usability & cleanup features missing. {{Bug|34665}} contains a good sample of such problems.

== Mailing lists ==

It is critical in any new Free software project to attract developers. One way to drive away newbies is to have an unstated rule that anyone who wants to get a reply from a mailing list post needs to add "please CC me I'm not subscribed - and retain this message so the rest of the thread reaches me" in a prominent place in their E-mail. Thus (I imagine) people regularly ask a question on a list, and receive no reply, even if one is written.

Futhermore address munging is a hugely bad idea for busy mailing lists - it is not possible to read all (busy) mailing lists on topics that people are interested in in linear time; hence keeping a thread CC'd to one is important, it allows a quick response - while keeping the mailing list informed. This is not possible with collab-net's Reply-To: mangling - hence discouraging busy people from using or CC'ing the mailing lists.

Also Reply-To: mangling is just a [http://www.unicom.com/pw/reply-to-harmful.html bad idea], cf. Linux Kernel, GNOME et. al's non-invasive, non-munging policies that encourage contributors & build collaboration.

It may be that one reason behind this mangling is to discourage people from replying off-list to people, - that unfortunately stifles community by not building strong inter-personal relationships, (although clearly off-list replies tend to be short, punchy, amusing, and not the norm). Another reason may be that there exist people out there who don't know how to use their mailer's reply-to-all feature.

It is believed that underneath SourceCast uses [http://cr.yp.to/ezmlm.html ezmlm] to handle mail.

== Missing services ==

=== LXR / Bonsai / Tinderbox ===

With 8 million lines of code no-one outside Sun is familiar with, is is essential to have some hard-code code search, change tracking, indexing functionality. Unfortunately SourceCast does not provide this, that makes it way more difficult to collaborate on developing the code.

A central well-maintained Tinderbox server, should be a pre-requisite for any large project with as many complex build issues as OO.o. One is provided at http://go-oo.org/tinderbox/ however.

=== RSS aggregator / 'planet' ===

It's not clear why it is not possible eg. to re-direct .openoffice.org domain names to existing solutions here as elsewhere.

== Additional Links ==
[[SVNMigration|Migration to SVN]]

[[Infrastructure_Requirements]]

[[Infrastructure_Overview]]

[[Category:Website]]
[[Category:Build_System]]

Contributing Patches

2008-12-29T03:03:07Z

DavidRoss: added Category:Build_System

== Sun Contributor Agreement ==

To submit any code to OOo you need to sign the [[Sun Contributor Agreement]] (SCA) that replaces the former [[Joint Copyright Assignment]] (JCA). This process can take some time, so check [[Pending JCAs]] to see if yours is pending legal review.

== Diff style ==

Always use unified diffs <tt>cvs -z3 diff -u</tt> , since they are the most readable, (and sensible) types of
diff to read and apply.
If you're not using them - most likely you want to setup your [[Tips#CVS_setup|cvsrc]] properly.

== Filing patches ==

The best hacker centric bug filing interface is
[http://qa.openoffice.org/issue_handling/submission_gateway.html#code_module here].
Whack the patch there & wait for feedback.

Sometimes assigning the bug to the code owner helps accelerate the process.
We can sometimes extract the owner of a module by checking
for the ADMIN_FILE_OWNER tag; there is a little tool in
<code>ooo-build/bin/owner <file-name> </code> that helps you
find out who to E-mail / interact with about a given module;
it's worth assigning very specifically located bugs to that
person.

== Some interaction ==

It tends to be a good idea to work out how best to implement
your fix, and/or discuss it with a developer or two before hand.
Some of the best ways to do this are to post to
[mailto:dev@openoffice.org] or lurk on IRC at <tt>irc.freenode.net</tt> on the
<tt>#dev.OpenOffice.org</tt> channel. IRC is an awfully poor
communication medium, but better than no communication.

See [[DomainDeveloper]] to unwind who is whom.

== ooo-build patch creation ==

Once you have created your patch you need to add it to the apply file so it
can be applied by apply.pl during build time.

Then simply re-run 'make' in the toplevel - this should incrementally apply
your patch to an (untouched) build tree.

==Speedy Handling of Patch Submissions==

Developers are encouraged to submit their first code contributions
as patches - attachments to issues of type PATCH - to IssueZilla for
review and integration into the main repository. We have been criticized that submitted
PATCHes are not handled in a reasonable timeframe. To support the timely work on patches we introduced the two metrics as listed below.

The consequences of insufficient responsiveness are contributor
dissatisfaction, bad reputation for the project and project leads and most significantly that the developer will probably not contribute again.

The number of 5 - 15 submissions per week and a backlog of about
170 open patches seems to be within our capabilities.

===Initial Response Time (IRT)===

[http://eis.services.openoffice.org/patchreport/irt_index.html Initial Response Time] (IRT) describes the time between submission and first comment or status
change from someone else than the submitter for open issues of type PATCH.

Please acknowledge the submission within one of the following days and assign the issue to the developer maintaining the code in question.

===Issue Inactivity Time (IIT)===

[http://eis.services.openoffice.org/patchreport/iit_index.html Issue Inactivity Time] (IIT)
describes the time since the last addition of a comment or status
change for open issues of type PATCH.

Let's avoid that patches linger around with unclear status for too long.
The expectation of a contributor is that he will see his code reviewed and - if applicable - integrated in one of the next microreleases.
So we should drive the issue towards a resolution and closure.

[[Category:Development]]
[[Category:Build_System]]

Mono Integration

2008-12-29T03:00:00Z

DavidRoss: added Category:Build_System

== Notice ==

This functionality is available only in patches associated with [[ooo-build]]/

=== Building ===

To build this, grab a recent mono - 1.1.8.3 is likely to work.
Then [[Building_with_ooobuild | Build]] with --enable-mono. [[Installing | Install]] in the normal way.

=== Build sample programs ===

cd odk/examples/CLI/CSharp/Spreadsheet
export CLI_URE=../../../../../cli_ure/unxlngi6.pro/bin
mcs SpreadsheetSample.cs SpreadsheetDocHelper.cs -r:$CLI_URE/cli_basetypes.dll \
-r:$CLI_URE/cli_types.dll -r:$CLI_URE/cli_cppuhelper.dll -r:$CLI_URE/cli_ure.dll
cp SpreadsheetSample.exe /opt/OOInstall/program
cd /opt/OOInstall/program
mono ./SpreadsheetSample.exe

You should get a nicely auto-generated spreadsheet.

=== With a binary installation ===

You need to grab the files above from: [http://go-oo.org/lxr/source/api/odk/examples/CLI/CSharp/Spreadsheet/ lxr] and whack them in /usr/lib/ooo-2.0/program slightly differently:

cd /usr/lib/ooo-2.0/program
mcs SpreadsheetSample.cs SpreadsheetDocHelper.cs \
-r cli_basetypes.dll -r cli_types.dll \
-r cli_cppuhelper.dll -r cli_ure.dll
mono ./SpreadsheetSample.exe
[[Category:Build_System]]

New Module

2008-12-29T02:59:34Z

DavidRoss: added Category:Build_System

== Adding a New module to the OO.o build ==

This process is somewhat complex, an example (adding cairo) is annotated here:

First create a your new module directory eg. <code>libpixman</code>

<ul>
<li>makefile.mk - in your module directory. see following example what it should contain, it is important that your
tarball is added to the <code>libpixman/download/</code> directory.
<pre>
PRJ=.

PRJNAME=libpixman
TARGET=libpixman

# --- Settings -----------------------------------------------------

.INCLUDE : settings.mk

# --- Files --------------------------------------------------------

.IF "$(GUI)"=="UNX"
TARFILE_NAME=libpixman-0.1.5

CONFIGURE_DIR=

CONFIGURE_ACTION=./configure
CONFIGURE_FLAGS=
BUILD_DIR=$(CONFIGURE_DIR)
BUILD_ACTION=$(GNUMAKE)

OUT2LIB= \
$/src$/.libs$/libpixman.so.*

OUT2INC= \
$/src$/pixman.h

# --- Targets ------------------------------------------------------

.INCLUDE : set_ext.mk
.INCLUDE : target.mk
.INCLUDE : tg_ext.mk
.ELSE

dummy:
@echo "Nothing to build for your platform"

.ENDIF
</pre></li>
<li>prj/build.lst - see following example and [[Hacking#prj.2Fbuild.lst|detailed description]]
<pre>
pm libpixman : solenv NULL
pm libpixman usr1 - u pm_mkout NULL
pm libpixman nmake - u pm_pixman NULL
</pre></li>
<li>prj/d.lst - see following example and [http://ooo.ximian.com/wiki/index.php/Hacking#prj.2Fd.lst detailed description ]

<pre>
mkdir: %_DEST%\inc%_EXT%\pixman
..\%__SRC%\inc\pixman.h %_DEST%\inc%_EXT%\pixman\pixman.h
..\%__SRC%\lib\libpixman.* %_DEST%\lib%_EXT%\libpixman.*

linklib: libpixman.so.*.*.*
linklib: libpixman.dylib.*.*.*
</pre></li>
</ul>

== Extra bits for ooo-build ==

Of course, you'll need to turn all of the above into patch form for [[ooo-build]]; but ooo-build also
has some infrastructure to help download the source you need easily; those need setting up:

<ul>
<li>configure.in - usualy you want your module to be build conditionaly. inspire yourself by looking how mdb or cairo are handled.
<pre>
AC_ARG_ENABLE(cairo,
[
--enable-cairo Enables cairo canvas backend.],
,)

...

if test "$enable_cairo" != "no"; then
CAIRO_ENABLED=TRUE
LIBPIXMAN_VER=0.1.5
GLITZ_VER=0.4.3
CAIRO_VER=0.5.2
else
CAIRO_ENABLED=
LIBPIXMAN_VER=
GLITZ_VER=
CAIRO_VER=
fi
AC_SUBST(CAIRO_ENABLED)
AC_SUBST(LIBPIXMAN_VER)
AC_SUBST(GLITZ_VER)
AC_SUBST(CAIRO_VER)
</pre>

<li>download.in - add your code to download package from network, best if you place the module tarball on ooo.ximian.com in /var/www/packages/SRC680/ directory.

<pre>
%SRC_URLS = (
'binutils-.*' => 'http://go-ooo.org/packages/support',
...
'libpixman-*' => 'http://go-ooo.org/packages/SRC680',
'cairo-*' => 'http://go-ooo.org/packages/SRC680',
'glitz-*' => 'http://go-ooo.org/packages/SRC680',

...

if ('@CAIRO_ENABLED@' eq 'TRUE') {
push @files, ( 'libpixman-@LIBPIXMAN_VER@.tar.gz' );
push @files, ( 'cairo-@CAIRO_VER@.tar.gz' );
push @files, ( 'glitz-@GLITZ_VER@.tar.gz' );
}

download_files (\@files, \%SRC_URLS, '@SRCDIR@');
</pre>

<li>bin/setup.in - you can set environment variable by autoconf variable values here. the setup is sourced (as in shell terminology) in unpack, so you can use info from configure that way

<pre>
...
CAIRO_VER=@CAIRO_VER@
CAIRO_ENABLED=@CAIRO_ENABLED@
GLITZ_VER=@GLITZ_VER@
...
</pre>

<li>bin/unpack - create a directory for your module in OOo tree, create another download directory for your tarball and copy it there

<pre>
...
if test "$CAIRO_ENABLED" == "TRUE"; then
echo "Making symbolic links of libpixman, cairo and glitz at build location"

mkdir -p $OOBUILDDIR/libpixman
check_tarball $SRCDIR/libpixman-$LIBPIXMAN_VER.tar.gz
mkdir -p $OOBUILDDIR/libpixman/download
cp -a $SRCDIR/libpixman-${LIBPIXMAN_VER}.tar.gz $OOBUILDDIR/libpixman/download/

mkdir -p $OOBUILDDIR/glitz
check_tarball $SRCDIR/glitz-${GLITZ_VER}.tar.gz
mkdir -p $OOBUILDDIR/glitz/download
cp -a $SRCDIR/glitz-${GLITZ_VER}.tar.gz $OOBUILDDIR/glitz/download/

mkdir -p $OOBUILDDIR/cairo
check_tarball $SRCDIR/cairo-${CAIRO_VER}.tar.gz
mkdir -p $OOBUILDDIR/cairo/download
cp -a $SRCDIR/cairo-${CAIRO_VER}.tar.gz $OOBUILDDIR/cairo/download/
fi

</pre>
</ul>

== Extra bits for Childworkspaces ==
Some additional things should be considered when introducing a new module on a [[CWS|Childworkspace]]. Please see
[[CWS#Create_a_new_module|here]].
[[Category:Build_System]]

Tips

2008-12-29T02:59:06Z

DavidRoss: added Category:Build_System

[[Tips zh|中]]
== Getting an OO.o CVS account ==


This is the process for getting CVS accounts for the up-stream
CVS server, (ooo-build accounts are handled [http://go-oo.org/ooo-build.html#section-2.5.1 differently]).
To see how the issue raising process works see eg. issue [http://www.openoffice.org/issues/show_bug.cgi?id=7270 i#7270#]
Having got the account setup, you need to tunnel to the secure CVS server
something like:


<code>ssh -f -2 -P -L 2401:localhost:2401 tunnel@openoffice.org sleep 1400 < /dev/null > /dev/null</code>


Then you need to change your CVSROOT to point at your local
machine, since this is the endpoint of the tunnel:


<code>:pserver:mmeeks@localhost:/cvs</code>


Your account name and password - will be the same as you use for
filing bugs etc. in the SourceCast system. Login, and ... you'll
soon notice that you'll need to migrate your CVS settings to the
new server, to do this without wasting B/W with duplicate
checkouts do:

<code>bin/re-root /path/to/checkout ":pserver:<account-name-here>@localhost:/cvs"</code>

Of course, to commit anything, you'll need various project
priviliges - and to battle the bureaucracy.


== Using patch / diff ==

Patch/diff are wonderful tools, however people often provide data that confuses them in a messy and difficult to un-tangle sort of a way. Here are some hints on untangling the mess:

* When creating diffs, '''please''' use <code>diff -upN</code> to create a diff against the revision(s) you checked out. The options used are:
*; -u
*: Create unified context diff.
*: Chances are much higher that the patch reviewer sees what it is about and is able to apply the patch to code that changed in the meantime.
*; -p
*: Show which C function each change is in.
*: Just informational, be nice to the patch reviewer.
*; -N
*: New file, treat absent files as empty,
*: which effectively includes new files in your diff that otherwise would be missing.

* If at all unsure, run patch with --dry-run first, this will appear to do the patching action, but not actually do it [ this can give bogus results with compound inter-depending patches, but is extremely useful ].

* Mostly use patch -p0; 0 signifies the number of path elements to strip from the beginning of the file path the diff points at.

* When you mess up, and have 1/2 of the patch applied and want to revert to clean, either remove the files and cvs update, or re-patch with the '-R' option, to reverse the effect.

* Sometimes using diff between modules with lots of whitespace changes makes the patch hard to read; the '-w' flag to (cvs) diff makes this easier.

Before committing a patch to ooo-build, test it with <code>make patch.apply</code> in the top-level, NB. it really pays to have 2 copies of the tree - 1 hacked, 1 pristine.

== Make clean ==


Just use <code>dmake clean</code> in the <code>build/src680</code> directory.
Or for a more descructive version in ooo-build try <code>rm -Rf build</code>.


== CVS setup ==


In order to make efficient use of bandwidth, generate sensible
diffs by default, and follow the trend, you need this in your
~/.cvsrc.

<pre>
cvs -z3 -q
diff -upN
update -dP
checkout -P
status -v
</pre>

== Adding header files to the build ==


Adding header files to the OO.o build is notoriously clunky. To
add header files under <code>external/</code>, make sure you list them in
<code>external/prj/d.lst</code> so that they get copied under the
<code>solver/680/unxlngi4.pro/inc/external</code> directory when building.


== Finding where to hack ==


Often there is some GUI element used near the thing you're
trying to locate / fix. So, find some sufficiently unusual
string and search for it in [http://go-ooo.org/lxr" LXR's]
text search; this should reveal an identifier related
to that string; eg. SID_AUTOFORMAT, or FN_NUM_BULLET_ON.
Having obtained that, do a new text search for that string,
and you'll find the usage [ or a chained define to something
else ]. For eg. menus/toolbar buttons the functionality is
usually in a case statement eg. case SID_AUTOFORMAT: ...


== Adding an UNO interface ==

This is slightly more complex build wise than you might expect.
*Add IDL file to offapi/com/sun/star/wherever/Foo.idl.
*If 'wherever is ''not'' a new path, add Foo.idl to IDLFILES in wherever/makefile.mk.
*If 'wherever' ''is'' a new path, update offapi/util/makefile.mk to refer to the relevant TARGET .db, prolly 'whatever.db'.
*If 'wherever' ''is'' a new path, update offapi/prj/d.lst and build.lst appropriately.

This should result in your type information being built into types.rdb & installed. This is however only part of the mix: the module 'offuh' builds & installs the .hdl/.hpp files we need (for C++), so if 'wherever' is a new path we need to update offuh/prj/d.lst to install those files too.

Finally, check that the types.rdb in the install set has your types; a <code>regview types.rdb / | grep 'whatever' -i </code> would work well for that. If not, copy it in from the solver.

== Creating a new top-level module ==

See [[New_Module|here]] for technical details about bringing external code into the OOo build environment. How to handle new modules in the Childworkspace process is described in [[CWS#Create_a_new_module|this]] CWS-HowTo.

== Find out which OOo version you are using ==

Open up the About dialog (last entry in the help menu), and hold down the <Ctrl> key, while pressing S D T in a row. The very first line that starts scrolling in (directly below the OK button) gives the internal milestone number, plus the build ID.

= See also =
* [[Using_Cpp_with_the_OOo_SDK|Using C++ with the OOoSDK]]
* [[:Category:Developer_Tools|Developer tools]]
* [[Building OpenOffice.org]]
* [[CWS|Working with Childworkspaces]]

[[Category:Development]]
[[Category:Build_System]]

Solenv

2008-12-29T02:58:33Z

DavidRoss: added Category:Build_System

== What it contains ==

solenv/ contains many of the tools necessary to build and package OO.o. It also contains lots of common makefile fragments:

* '''solenv/'''
** '''bin/'''
*** build.pl - aliased to '[[build]]' by [[LinuxIntelEnv.Set]]
*** cws* - tools for manipulating [[CWS]]
*** deliver.pl - aliased to '[[deliver]]' by [[LinuxIntelEnv.Set]]
*** [[relocate]] - built tree relocation tool
*** [[linkoo]] - rapid devel. iteration tool
*** make_installer.pl - builds system packages
*** modules/ - perl tools for cws & installer code
** '''inc/'''
*** contains fragments common to all makefiles, particularly:
*** settings.mk - sets up common platform/compiler settings
*** target.mk - creates default target & rules.
*** unxlngi6.mk - gcc specific targets (cf. unxlngi4/5, unxlngppc, unxlngx4)

[[Category:source directories]]
[[Category:Build_System]]

Config office

2008-12-29T02:58:11Z

DavidRoss: added Category:Build_System

== What it contains ==

This directory manages the configuration of the OO.o source tree. In a 'normal' project this would be expected to be in the toplevel source directory - however, due to a rather unfortunate initial repository setup, this is not possible.

== Configure process ==

The configure script is generated from configure.in by 'autoconf' - when checking into a [[cws]] including this module it is best not to update the 'configure' script since this creates cws merge problems for releng.

When run the configure script does a load of system checks, and with the result generates 'set_soenv' from 'set_soenv.in' using the normal autotools substitution rules.

'set_soenv' is then run at the tail of configure, which does more checks, and finally builds [[LinuxIntelEnv.Set]] which contains the environment for this build. This freezes all the significant settings including PATH, LD_LIBRARY_PATH etc. The idea here is to allow this build to be repeated trivially, and to reduce unexpected environment related problems in subsequent builds.

The configure script also creates 'bootstrap' in the toplevel - a simple script that builds [[dmake]] - the tool which then is used to build the rest of the project.

== Gotchas ==

In many cases running 'configure' when you have [[LinuxIntelEnv.Set]] sourced creates rather subtle problems; configuring from a clean shell is to be recommended.

[[Category:source directories]]
[[Category:Build_System]]

Source code directories

2008-12-29T02:57:35Z

DavidRoss: added Category:Build_System

Below is a (somewhat terse) description of the various directories for OpenOffice source code.

If you want to know the build order of the modules check out the [[Module_Build_Order]].

{| border="1"
| '''Name''' || '''Project hosting the module''' || '''Informations'''
|-
| [[agg]] ||[http://external.openoffice.org/ external] || antigrain geometry lib (from http://www.antigrain.com/), a software renderer used in canvas
|-
| [[animations]] ||[http://graphics.openoffice.org/ graphics] || Containers for the css::animation UNO API, used in slideshow and sd
|-
| [[autodoc]] ||[http://tools.openoffice.org/ tools] ||html pages from c++, java, idl inline documentation
|-
| [[automation]] || || Hook for QA automation (TestTool)
|-
| [[avmedia]] ||[http://graphics.openoffice.org/ graphics] ||Audio/Video media implementation - requires a working Java Media Framework (JMF)
* currently can't play streams only file-system URIs anyway.
|-
| [[basctl]] || || controls and dialogs - basic
|-
| [[basebmp]] || [http://gsl.openoffice.org gsl]|| algorithms and data types for bitmap graphics (e.g. line and fill polygon scan conversion, bitmap format iterators, and a SalGraphics-compatible software renderer)
|-
| [[basegfx]] ||[http://graphics.openoffice.org/ graphics] || algorithms and data types for graphics (e.g. polygons, vectors, matrices and the like - see that used in canvas)
|-
| [[basic]] || || basic interpreter
|-
| [[OOoBean|bean]] ||[http://api.openoffice.org/ api] || office bean
|-
| [[beanshell]] ||[http://external.openoffice.org/ external] || java interpreter - so you can write java in command shell,
* interactive java -- good for prototyping /macros
* from http://www.beanshell.org/ with some patches
|-
| [[berkeleydb]] ||[http://external.openoffice.org/ external] || external library. http://www.sleepycat.com/products/db.shtml simple db - used for search in help and galleries
|-
| [[Framework/Modules/binfilter|binfilter]] ||[http://framework.openoffice.org/ framework] || [[StarOffice]] 5.2 compatibility layer, the UI and everything. Basically a little SO 5.2 inside OO.o. This is huge - avoid building it by giving '--disable-binfilter' on the configure line.
|-
| [[boost]] ||[http://external.openoffice.org/ external] || external (C++ template) library: http://boost.org/native
|-
| [[Uno/Binary/Module/bridges|bridges]] || [http://udk.openoffice.org/ udk] || Bridges from various C++ ABIs, Java JNI, MS .Net to [[Uno/Binary|Binary Uno]]. Also implementation of the [[Uno]] Remote Protocol. And in ooo-build a bridge from Mono to [[Uno]] and back.
|-
| [[canvas]] || [http://gsl.openoffice.org gsl] || new canvas implementation to improve rendering, various backends implement the new XCanvas API eg. cairo / DirectX
|-
| [[chart2]] ||[http://graphics.openoffice.org/ graphics] || new, improved chart implementation, arrived in OO.o 2.3
|-
| [[Uno/CLI/Modules/cli_ure|cli_ure]] ||[http://udk.openoffice.org/ udk] || '''C'''ommon '''L'''anguage '''I'''nfrastructure '''U'''no '''R'''untime '''E'''nvironment -- support assemblies and tools for the MS .Net (and Mono) [[Uno]] binding.
|-
| [[Uno/Binary/Module/codemaker|codemaker]] ||[http://udk.openoffice.org/ udk] || [[Uno]] interface declaration/stub generators for [[Uno/Cpp|C++ Uno]] (headers), [[Uno/Java|Java Uno]] (class files), [[Uno/CLI|CLI (.Net / Mono) Uno]].
|-
| <div id="configmgr">[[configmgr]]</div> || || the configuration database - UNO services and some tools
|-
| [[config_office]] ||[http://tools.openoffice.org/ tools] || build configs, configure scripts, autotools, etc.
|-
| [[connectivity]] ||[http://dba.openoffice.org/ dba] || database pieces, drivers, etc.
|-
| [[cosv]] ||[http://tools.openoffice.org/ tools] || "Common Services," part of [[autodoc]]
|-
| [[cppcanvas]] || [http://gsl.openoffice.org gsl]|| helper C++ classes for canvas, plus a GDIMetaFile-to-XCanvas converter
|-
| [[Uno/Binary/Modules/CPPU|cppu]] ||[http://udk.openoffice.org/ udk] || [[Uno/Binary|Binary (read 'C') Uno]] runtime.
|-
| [[Uno/Cpp/Module/CPPUhelper|cppuhelper]] ||[http://udk.openoffice.org/ udk] || [[Uno/Cpp|C++ Uno]] runtime, additionally helpers e.g. templates for implementing Uno components, bootstrapping stuff etc. - get Uno up & running.
|-
| [[Uno/Binary/Module/CPPUtools|cpputools]] ||[http://udk.openoffice.org/ udk] || [[Uno/Binary|Binary Uno]] tools, like uno.exe, regcomp etc.
|-
| [[crashrep]] || || reports crashes (Novell disabled that)
|-
| [[curl]] ||[http://external.openoffice.org/ external] || external library [http://curl.haxx.se curl] (a URL manipulation engine)
|-
| [[dbaccess]] ||[http://dba.openoffice.org/ dba] || data base access tools
|-
| [[default_images]] ||[http://external.openoffice.org/ external] || all images and resources
|-
| [[desktop]] || [http://framework.openoffice.org/ framework] || what used to be the desktop in SO5 - now the binary
|-
| [[dmake]] ||[http://tools.openoffice.org/ tools] || the dmake tool itself, built by running 'bootstrap' after configure
|-
| [[dtrans]] || [http://gsl.openoffice.org gsl] || clipboard abstraction - data transfer
|-
| [[embeddedobj]] ||[http://framework.openoffice.org/ framework] || Embedding objects
|-
| [[embedserv]] ||[http://framework.openoffice.org/ framework] || Embed OOo through OLE2
|-
| [[epm]] ||[http://external.openoffice.org/ external] || enhanced package manager- nasty hack for packaging
* not useful - but default build uses, every linux packager disables this
|-
| [[eventattacher]] || || how basic handles events -
|-
| [[expat]] ||[http://external.openoffice.org/ external] || external library with added UCS2 support, ... simple SAX parser
|-
| [[extensions_(source_code_module)|extensions]]|| || browser plugin, activex control, scanner bits
|-
| [[external]] ||[http://external.openoffice.org/ external] || placeholder for extra code needed to build
|-
| [[extras]] ||[http://installation.openoffice.org/ installation] || templates, clipart galleries, palettes, symbol font etc.
|-
| [[fileaccess]] || || tiny: implements XSimpleFileAccess interface - that makes the UCB interfaces actually usable (via [[Uno]]) and more intuitive.
|-
| [[filter]] ||[http://framework.openoffice.org/ framework] || filter registration and some simple filters (also descriptions
|-
| [[forms]] || [http://gsl.openoffice.org gsl] || embedded forms control and pieces (design forms in documents, fields and database driven)
|-
| [[fpicker]] || [http://gsl.openoffice.org gsl] || native file pickers for Unix and Windows (file open dialog) GTK+, KDE, Windows
|-
| [[Framework]] ||[http://framework.openoffice.org/ framework] || UI rewrite, toolbars, menus, [[Uno]] stuff, including accelerators & interaction, etc.
|-
| [[External/Modules/freetype|freetype]]||[http://external.openoffice.org/ external] || Font rasterrizer.
|-
| [[goodies]] ||[http://graphics.openoffice.org/ graphics] || graphics filters, 3d and 2d graqphics pieces
|-
| [[helpcontent2]] ||[http://installation.openoffice.org/ installation] || for OpenOffice.org 2 - english + other languages help content
|-
| [[hsqldb]] ||[http://external.openoffice.org/ external] || external library. http://hsqldb.org/ Java database engine. Default database format for OpenOffice.org
|-
| [[hwpfilter]] ||[http://sw.openoffice.org/ sw] || filter for a word processor file format popular in Korea. (Hangul Word Processor)
|-
| [[i18npool]] ||[http://l10n.openoffice.org/ l10n] || internationalization, counting, calendaring, complex text layout
|-
| [[i18nutil]] ||[http://l10n.openoffice.org/ l10n] || small bits of internationalization
|-
| [[icc]] ||[http://external.openoffice.org/ external] || External library used to build the sRGB profile for PDF/A-1a export. http://www.color.org/ with patches. Generated and used at build time only. More details can be found in icc/README.
|-
| [[ICU|icu]] ||[http://external.openoffice.org/ external] || external library. International Components for Unicode, http://www.icu-project.org/ with patches.
|-
| [[idl]] ||[http://framework.openoffice.org/ framework] || SvIDL Compiler
|-
| [[Uno/Binary/Module/idlc|idlc]] ||[http://udk.openoffice.org/ udk] || The [[Uno/Specifications/IDL|Uno IDL]] compiler.
|-
| [[instsetoo_native]] ||[http://installation.openoffice.org/ installation] || install set for oo, native installers -
|-
| [[Util/Module/IO|io]] || || Provides socket and pipe acceptors / connectors, as well as text input / output streams.
|-
| [[Uno/Java/Module/javaunohelper|javaunohelper]]||[http://udk.openoffice.org/ udk] || [[Uno/Java|Java Uno]] components implementation helpers.
|-
| [[Uno/Java/Module/JURT|jurt]]||[http://udk.openoffice.org/ udk] || '''J'''ava '''U'''no '''R'''un'''t'''ime - Basically [[Uno/Java|Java Uno]].
|-
| [[Util/Module/JUT|jut]] ||[http://udk.openoffice.org/ udk] || '''J'''ava '''U'''no '''T'''ools - Tools for [[Uno/Java|Java Uno]].
|-
| [[jvmaccess]], [[jvmfwk]] ||[http://udk.openoffice.org/ udk] || wrappers so you can use all the Java Runtime Environments with their slightly incompatible APIs with ease. Hah.
|-
| [[libwpd]] || || external library. Not modified. http://libwpd.sourceforge.net/ wordperfect filter - SAX api - emits callbacks when things happen
|-
| [[libxmlsec]] || || external library. (Still) heavily patched. http://www.aleksey.com/xmlsec/ to do XML signing, etc.
|-
| [[lingucomponent]] ||[http://lingucomponent.openoffice.org/ lingucomponent] || spellcheck, hyphenator, thesaurus, ...
|-
| [[linguistic]] ||[http://sw.openoffice.org/ sw] || This component manages all registered linguistic module implementations for spellchecker, hyphenator and thesaurus.
|-
| [[lpsolve]] || || external library that provides a mixed integer linear programming (MILP) solver, see http://lpsolve.sourceforge.net
|-
| [[mathmldtd]] || || MathMLDTD to implement XML Math format, see http://www.w3.org/TR/REC-MathML
|-
| [[msfontextract]] || || external library. http://www.kyz.uklinux.net/libmspack/ for use in FontOOo (unpacking the downloaded Microsoft fonts (webfont))
|-
| [[nas]] ||[http://external.openoffice.org/ external] || The Network Audio System (NAS), An Audio Protocol For Networks. See http://radscan.com/nas.html
|-
| [[neon]] ||[http://external.openoffice.org/ external] || web library to help deal with WebDAV or other protocols
|-
| [[netbeans_integration]] || || java?
|-
| [[np_sdk]] ||[http://external.openoffice.org/ external] || Netscape Plugin SDK. Header to build Mozilla plugins.
|-
| [[odk]] ||[http://api.openoffice.org/ api] || office development kit - implements the first step on the way to the OpenOffice.org SDK tarball
|-
| [[offapi]] ||[http://api.openoffice.org/ api] || all of the [[Uno/Specification/IDL|Uno IDL]] files except those in [[#udkapi|udkapi]] - i.e. the interfaces that are specific to the OpenOffice.org application.
|-
| [[officecfg]] || || the schema and default settings for the [[#configmgr|OpenOffice.org configuration database]]
|-
| [[offuh]] ||[http://api.openoffice.org/ api] || Tiny module to build the generate the [[Uno/Cpp|C++ Uno]] headers.
|-
| [[oocustomimages]] || || themes, custom themes
|-
| [[oo_extensions]] || [http://extensions.openoffice.org/ extensions] || generic OpenOffice.org extensions module
|-
| [[OOX|oox]]|| || [[OpenXML]] parser
|-
| [[packages]] ||[http://xml.openoffice.org/ xml] || reading and writing zips
|-
| [[padmin]] || [http://gsl.openoffice.org gsl] || printer administration dialog - used lpr - obsolete with CUPS and fontconfig, but still used for some things
|-
| [[External/Modules/portaudio|portaudio]] ||[http://external.openoffice.org/ external] || an audio output library for various sound setups.
|-
| [[postprocess]] || || Postprocessing and checking of files delivered by other modules. This module has to be the last one before creating install sets in module 'instset_native'.
|-
| [[psprint]] || [http://gsl.openoffice.org gsl] || postscript print - unix only - implements font discovery, interface to CUPS / lpr, query and basic PS - dump PS on print - actual PS rendering inside vcl
|-
| [[psprint_config]] || || ppds for use by psprint when not using CUPS
|-
| [[pyuno]] ||[http://udk.openoffice.org/ udk] || [[Uno]] binding for python
|-
| [[qadevOOo]] || || qa testsuite
|-
| [[Uno/Binary/Module/rdbmaker|rdbmaker]] ||[http://udk.openoffice.org/ udk] || makes registries for openoffice for storing type data, etc./?
|-
| [[readlicense_oo]] || || reading oo license when starting up
|-
| [[regexp]] || || regular expression matching
|-
| [[registry]] ||[http://udk.openoffice.org/ udk] || registry reading, etc.
|-
| [[Uno/Binary/Module/remotebridges|remotebridges]] ||[http://udk.openoffice.org/ udk] || [[Uno]] services dealing with interprocess bridges.
|-
| [[rhino]] || || java script engine/interpreter
|-
| [[Uno/Java/Module/ridljar|ridljar]] ||[http://udk.openoffice.org/ udk] || Generators [[Uno/Java|Java Uno]] types (like [[offuh]]).
|-
| [[rsc]] || [http://gsl.openoffice.org gsl] || resource compiler - turns resource descriptions src and hrc files scattered throughout.
|-
| [[rvpapi]] || [http://gsl.openoffice.org gsl] || Obsolete.
|-
| [[sablot]] ||[http://external.openoffice.org/ external] || external library. yet another xslt implementation in the tree (in C++)
|-
| [[Porting/Module/SAL|sal]] || [http://porting.openoffice.org porting] || system abstraction layer - rtl, osl and sal (rtl - platform independent strings, osl - platform specific stuff, threads, dynamic loading, process, ipc, etc.). Exports only C API and some inline-methods-only C++ API
|-
| [[Uno/Cpp/Module/SALhelper|salhelper]] ||[http://udk.openoffice.org/ udk] || C++ helpers to make use of sal easier
|-
| [[Util/Module/sandbox|sandbox]] || || Generic sandboxing, e.g. used for Java applet embedding stuff. Totally useless without a Sun JDK. Might be obsolet.
|-
| [[sane]] ||[http://external.openoffice.org/ external] || external scanner library
|-
| [[sax]] ||[http://xml.openoffice.org/ xml] || wrapper around expat using [[Uno]].
|-
| [[sc]] ||[http://sc.openoffice.org/ sc] || calc - the Spreadsheet core
|-
| [[scaddins]] || || extra functions for calc
|-
| [[scp2]] ||[http://installation.openoffice.org/ installation] || script particles - being rewritten for oo2. all of installation was driven by starbasic - this is now in instsetoo-native
|-
| [[scripting]] ||[http://framework.openoffice.org/ framework] || scripting framework - for java, python, etc. to play together and uses UNO
|-
| [[scsolver]] || || [[Optimization Solver]] for Calc
|-
| [[sd]] ||[http://graphics.openoffice.org/ graphics] || Impress and Draw components. Think of Impress as hack on top of Draw.
|-
| [[sdext]] ||[http://graphics.openoffice.org/ graphics] || Extensions for the Impress and Draw applications.
|-
| [[sdk_oo]] ||[http://api.openoffice.org/ api] || software development kit OO - implements the second step on the way to the OpenOffice.org SDK tarball (see odk)
|-
| [[setup-native]] ||[http://installation.openoffice.org/ installation] || ?
|-
| [[sfx2]] ||[http://framework.openoffice.org/ framework] || gui code, much of which is now deprecated - list of documents open would be tracked - raw C++ code; gutsy core of document management and loading.
|-
| [[shell]] || [http://gsl.openoffice.org gsl] || system helpers - launching URI, recently used files, system integration, external mailer support, gconf integration etc.
|-
| [[sj2]] || || Java Applet support.
|-
| [[slideshow]] ||[http://graphics.openoffice.org/ graphics] || new impress slideshow engine in OO.o 2.0
|-
| [[smoketestoo_native]] ||[http://installation.openoffice.org/ installation] || Test code to launch each component for a smoke test.
|-
| [[sndfile]] ||[http://external.openoffice.org/ external] || soundfile - library for loading all kinds of sound - external lib
|-
| [[so3]] || || StarObject (v3)
|-
| [[solenv]] ||[http://tools.openoffice.org/ tools] || make and build infrastructure - solar (think: Sun or Star Division) environment
|-
| [[soltools]] || || all sorts of build tools
|-
| [[solver]] || || dumping ground for binaries as object output
|-
| [[sot]] || || compound file storage tools code (?)
|-
| [[starmath]] ||[http://sw.openoffice.org/ sw] || formula editor
|-
| [[External/Modules/stlport|stlport]] || || external library. STL implementation, from the days when compilers had crappy implementations.
|-
| [[Uno/Binary/Module/STOC|stoc]] ||[http://udk.openoffice.org/ udk]|| Core Components for [[Uno/Binary|Binary Uno]] (e.g. registry access, reflection, introspection).
|-
| [[store]] || || Storage implementations, used by [[Uno]] registries.
|-
| [[svtools]] ||[http://framework.openoffice.org/ framework] || useful code, common dialogs, file and print dialogs, wizards, vcl filters, lots of helper code
|-
| [[svx]] ||[http://graphics.openoffice.org/ graphics] || Graphics related helper code - xoutdev - rendering - This is where a lot of work would happen to move to the canvas. svdraw - transparent gradient stuff. Lot of the Draw and Impress code is in this module. Part if the PPT binary importer is in there too.
|-
| [[sw]] ||[http://sw.openoffice.org/ sw] || writer - the word processing core
|-
| [[sysui]] || [http://gsl.openoffice.org gsl] || .desktop files for different distros
|-
| [[toolkit]] || [http://gsl.openoffice.org gsl] || abstract windowing thing- [[Uno]] implementations of windows stuff - so can be used from basic
|-
| [[tools]] ||[http://framework.openoffice.org/ framework] || predates sal - string etc. functions, URL manipulation, stream stuff, polygons, etc.
|-
| [[transex3]] ||[http://l10n.openoffice.org/ l10n] || translation tools
|-
| [[twain]] || || Windows scanner support
|-
| [[ucb]] || || '''U'''niversal '''C'''ontent '''B'''roker (has ucp) which do things like convert files to strings in content broker world.
|-
| [[ucbhelper]] || || C++ wrappers to help make using content providers easy
|-
| <div id="udkapi">[[udkapi]]</div> ||[http://api.openoffice.org/ api] || URE API definition - [[Uno/Specification/IDL|Uno IDL]] files
|-
| [[udm]] ||[http://tools.openoffice.org/ tools] || part of [[autodoc]]
|-
| [[unixODBC]] || || external lib
|-
| [[unocontrols]]|| [http://gsl.openoffice.org gsl] || separate process and thread for progress bars, etc.
|-
| [[unoil]] ||[http://udk.openoffice.org/ udk][http://api.openoffice.org/ api] || Like offuh for [[Uno/Java|Java Uno]] - Generates Java class files from OOo application Uno types.
|-
| [[unotools]] ||[http://udk.openoffice.org/ udk] || helpers for C++ use of UNO
|-
| [[unoxml]] ||[http://framework.openoffice.org/ framework] || [[Uno]] wrappers for XML services
|-
| [[unzip]] || || used by installer
|-
| [[ure]] ||[http://udk.openoffice.org/ udk] || beginnings of standalone UNO distribution foo.
|-
| [[uui]] || || An Interaction Handler for the UCB. It uses VCL to visualize and handle interaction requests, for eg. authentication dialogs for file operations.
|-
| [[vcl]] || [http://gsl.openoffice.org gsl] || base windowing toolkit abstraction Visual Class Libraries, and graphical output layer - includes backends for unix & Win32
|-
| [[vigra]] || || Template framework from [http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/ here]. VIGRA stands for "Vision with Generic Algorithms". Used from [[basebmp]].
|-
| [[vos]] ||[http://udk.openoffice.org/ udk] || (Virtual Object System) - deprecated but still used, lots of sal like stuff
|-
| [[wizards]] ||[http://installation.openoffice.org/ installation] || java wizards for db setup, importing, tutorials, etc.
|-
| [[writerperfect]]||[http://framework.openoffice.org/ framework] || word perfect filter - wrapper for libwpd
|-
| [[X11_extensions]] || || headers for XRender support
|-
| [[xalan]] ||[http://external.openoffice.org/ external] || external library. java xslt implementation
|-
| [[xmerge]] ||[http://xml.openoffice.org/ xml] || The XMerge SDK provides a Java-based framework for converting documents between different formats using conversion plugins to read and write each format. See http://xml.openoffice.org/xmerge
|-
| [[xml2cmp]] || || Comes with the OO SDK. xml2cmp is launched in general by a makefile to extract types from a xml file
|-
| [[xmlhelp]] || || Help reader and viewer for online help
|-
| [[xmloff]] ||[http://xml.openoffice.org/ xml] || OpenDocument import / export filter.
|-
| [[xmlscript]] || || Implements XML dialogs serialization.
|-
| [[xmlSearch]] || || ?
|-
| [[xmlSecurity]] ||[http://xml.openoffice.org/ xml] || Document signing
|-
|}

[[Category:Source directories]]
[[Category:Build_System]]

Environment Variables

2008-12-29T02:57:09Z

DavidRoss: added Category:Build_System

== OpenOffice.org runtime environment variables ==

This page documents environment variables you can export in your environment to change the OpenOffice.org behaviour at runtime. It does not include variables used by the configuration system, or by the build system in general.

==What's an environment variable, Where do I find them and how do I edit them?==

Environment variables are key-value pairs stored on your system. The operating system / the shell is responsible for managing and make them visible for all applications.

The user can change values of those variables, completely undefine or define new variables.

In the following, managing variables is explained on different operating systems:

* '''Linux Bash Shell'''
** Display all set variables with 'export'
** Set value: 'export varname="new value of variable"' Embrace the new value with inverted commas if they contain spaces.
** Refer to value: 'echo $varname' Echo prints out the variable contents of varname. Referring is indicated by a preceeding dollar sign.

* '''Windows XP'''
** Display all set variables with 'set'
** Set value: 'set varname="new value of variable"
** Refer to value: 'echo %varname%'
** Set variable through the GUI Interface:
*** Start - Settings - Control Panel - System - Advanced - Environment Variables
*** You can manage your user and system variables independently.

== Environment variables for users ==

Variables that users could use, or should know about.

"Users" includes people developping applications based on OOo (macros, UNO applications).

{| class="prettytable sortable"
|-
! Name
!| OS
!| Belongs to
!| Description
|-
| AUDIODEV
|| unx
|| ooo
|| Tells which audio device to use if your sound support is of type /dev/audio.
|-
| AUDIOSERVER
|| unx
|| ooo
|| Tells the server to connect to if your sound support is of type rptp.
|-
| AVOID_BURN_IN_FOR_GALLERY_THEME
||all
||gallery
||When putting shapes into the gallery, normally style-governed attributes are converted to hard attributes and stored at the gallery object. If you want to create your own custom gallery, whose objects should adapt to style changes, use this variable.
|-
| DISPLAY
|| unx
|| system
|| X11 display string (ex "localhost:0")
|-
| GALLERY_ENABLE_ID_DIALOG
||all
||gallery
||Adds a new menu elemet to the Gallery context menu to assing themes with IDs. IDs are added in the source when you want to create localized gallery in build time.
|-
| GALLERY_SHOW_HIDDEN_THEMES
||all
||gallery
||Show the hidden gallery element like AutoShape, Web, Fontwork gallery. You can add more element by selecting the object, press CTRL + click and drag it into gallery.
|-
| GALLERY_SHOW_PRIVATE_TITLE
||all
||gallery
||Shows the internal gallery title, instead of the translated UI name.
|-
| HOME
|| unx
|| system
|| User's personal directory
|-
| LANG
|| unx
|| system
|| This variable determines the locale category for native language, local customs and coded character set in the absence of the LC_ALL and other LC_* (LC_COLLATE, LC_CTYPE, LC_MESSAGES, ...) environment variables. This can be used by applications to determine the language to use for error messages and instructions, collating sequences, date formats, and so forth. See environ(5) for details.
|-
| LC_ALL
|| unx
|| system
|| This variable determines the values for all locale categories. The value of the LC_ALL environment variable has precedence over any of the other environment variables starting with LC_ (LC_COLLATE, LC_CTYPE, LC_MESSAGES, ...) and the LANG environment variable. See environ(5) for details.
|-
| LC_COLLATE
|| unx
|| system
|| This variable determines the locale category for character collation. It determines collation information for regular expressions and sorting, including equivalence classes and multi-character collating elements. See environ(5) for details.
|-
| LC_CTYPE
|| unx
|| system
|| This variable determines the locale category for character handling functions, such as tolower(), toupper() and isalpha(). This environment variable determines the interpretation of sequences of bytes of text data as characters (for example, single- as opposed to multi-byte characters), the classification of characters (for example, alpha, digit, graph) and the behaviour of character classes. See environ(5) for details.
|-
| LC_MESSAGES
|| unx
|| system
|| This variable determines the locale category for processing affirmative and negative responses and the language and cultural conventions in which messages should be written. See environ(5) for details.
|-
| MOZILLA_CERTIFICATE_FOLDER
|| unx
|| system
|| Specify where digital certificates detection should look for, override auto detection in mozilla/firefox/thunderbird's user profile path.
|-
| OOO_CALC_USE_ENGLISH_FORMULAS
|| all
|| ooo
|| '''Experimental (!)''' If set to ''1'' or ''Yes'' (or any other value starting with ''y'') the UI uses English function names and decimal separator in spreadsheet formulas, and only in formulas, cell input and displayed values are not affected. Since milestone DEV300_m2.
|-
| OOO_FORCE_DESKTOP
|| unx
|| ooo
|| Override the desktop detection (also implies usage of the appropriate plugin, see SAL_USE_VCLPLUGIN). Possible values: "kde" (KDE), "gnome" (Gnome), "none" (other)
|-
| SAL_ACCESSIBILITY_ENABLED
|| all
|| ooo
|| Set to nonempty value enforce accessibility bridging.
|-
| SAL_DISABLE_OWN_IM_STATUS
|| solaris
|| ooo
|| Set to nonempty value to disable OOo displaying an input method status window.
|-
| SAL_ENABLE_NATIVE_XFONTS
|| unx
|| ooo
|| 0 will disable OOo's use of native X11 fonts
|-
| SAL_USE_VCLPLUGIN
|| unx
|| ooo
|| The VCL plugin to use. Possible values: "kde" (KDE) or "gtk" (Gnome) or "gen" (generic X11)
|-
| SAL_DISABLE_NATIVE_ALPHA
|| all
|| ooo
|| When set, disables usage of the new system-level alpha rendering. Use this if e.g. your Xrender implementation is flaky.
|-
| SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION
|| unx
|| ooo
|| If set to nonempty value disables synchronous printer detection. This can help on startup e.g. if your CUPS server is very slow.
|-
| SAL_DECIMALSEP_ENABLED
|| all
|| ooo
|| Set to any value to force localized decimal separator in vcl settings.
|-
| SAL_NOOPENGL
|| unx
|| ooo
|| Disables usage of OpenGL if set to "true".
|-
| SAL_VISUAL
|| unx
|| ooo
|| Explicitly set the X11 visual id to use. See xdpyinfo(1) for information on available X11 visuals and the current default visual. There are only some very rare cases where an X11 server would offer multiple visuals and the default visual would not be suitable for use with OOo. But in these cases this variable provides a method to override the default visual for OOo.
|-
| SAL_WHEELLINES
|| unx
|| ooo
|| Specifies the number of lines a wheel mouse event will scroll. Default is 3 lines. Setting this to something larger than 10 results in page-wise scrolling.
|-
| SystemRoot
|| win
|| system
|| OS specific variable pointing to OS System Directory. If not set external UNO communication to the OOo process will not work. This is relevant when using OOo as component in other applications, for example.
|-
| USE_XOPENIM
|| Solaris
|| ooo
|| Force use of XOpenIM instead of XvaOpenIM. Changes behaviour of X11 input method (used in generic and kde vcl plugin).
|-
| SAL_USEINPUTMETHOD
|| unx
|| ooo
|| set to empty value to disable internationalized input (used in generic and kde vcl plugin).
|-
|}

== Environment variables for OOo developers ==

For testing, debugging, getting system information, etc.

{| class="prettytable sortable"
|-
! Name
!| OS
!| Belongs to
!| Description
|-
| <div id="CFG_LOGFILE">CFG_LOGFILE</div>
|| all
|| ooo
|| Is used by the sample configuration logger implementation from [[Source code directories#configmgr|configmgr]]/source/workben/logger. This logger service can be used to get diagnostic output from the configuration services. By default that logger logs to stderr. If CFG_LOGFILE is set to a file name or path, the log output is redirected there.
|-
| CFG_LOGLEVEL
|| all
|| ooo
|| Is used by the sample configuration logger implementation (see [[#CFG_LOGFILE|CFG_LOGFILE]]) to control how much detail should be logged. See API documentation for com.sun.star.util.logging.LogLevel [http://api.openoffice.org/docs/common/ref/com/sun/star/util/logging/LogLevel.html] for available values. Only numeric values are accepted. Default is to log messages from WARNING(=900) and up. Use lower numbers for more detail.
|-
| DISABLE_SAL_DBGBOX
|| all
|| ooo
|| Disable the OSL assertion dialogs for the non-product builds
|-
| ENVCFGFLAGS
|| all
|| ooo
|| Will be deprecated or obsoleted soon! Controls an older trace output facility in [[Source code directories#configmgr|configmgr]] that is active only in non-product builds or debug versions of the library. Has a rather obscure syntax.
|-
| help_debug
|| all
|| ooo
|| Enables additional debug facilities of the help system. In particular, if you press Shift-F1 and hover over an element in the OOo UI, the tooltip will now show you the help id of the element, and the help module where its help text is looked up.
|-
| OOO_CALC_GENPARCLASSDOC
|| all
|| ooo
|| If Calc's sc/source/core/tool/parclass.cxx was compiled with OSL_DEBUG_LEVEL defined > 1 and this variable is set, generate Calc's parameter classification documentation to stdout, similar to what's available at http://specs.openoffice.org/calc/compatibility/cac/parameter_classification.txt Available since SRC680_m67.
|-
| OOO_DISABLE_RECOVERY
|| all
|| ooo-build
|| If set this stops the recovery dialog prompting you as OO.o starts up - instead the recovery files are just silently accumulated.
|-
| OOO_ENABLE_LOCALE_DATA_CHECKS
|| all
|| ooo
|| Check locale data in product builds. For a full description see comment in i18npool/source/localedata/data/locale.dtd Available since SRC680_m109.
|-
| OOO_FORCE_SYSALLOC
|| all
|| ooo-build
|| If set this disables the internal OO.o allocators, in favour of the system allocators - this means it is possible to get useful valgrind data out of a production build.
|-
| PROT_REMOTE
|| all
|| ooo
|| Set the file name prefix for logging in bridges/remote modules
|-
| PROT_REMOTE_FAST
|| all
|| ooo
|| Keep the logging file always open for logging in bridges/remote modules
|-
| PROT_REMOTE_ACTIVATE
|| all
|| ooo
|| If existing in env activate logging in bridges/remote modules
|-
| U_RBBIDEBUG
|| all
|| ooo
|| For testing the "rule based break iterator" for ICU
|-
| SAL_ANTIALIAS_DISABLE
|| unx
|| ooo
|| Disables all AA - useful for debugging
|-
| SAL_DISABLE_BITMAPS_OPTS
|| all
|| ooo
|| Disables a relatively new templatized fast-path for outputting bitmaps (setting the variable reverts to the old, slow method)
|-
| SAL_DISABLE_STACKING_CHECK
|| unx
|| ooo
|| Disables selecting events on the window manager's window.
|-
| SAL_ENABLE_GLX_XFREE4
|| unx
|| ooo
|| If set enables usage of OpenGL extension on XFree >= 4.0 servers
|-
| SAL_FLOATWIN_NOAPPFOCUSCLOSE
|| all
|| ooo
|| Set to nonempty value to prevent floating windows from closing if the application loses focus.
|-
| SAL_HIGHPRIORITY_REPAINT
|| unx
|| ooo
|| Forces quasi-synchronous paints if set. Only known use case: automated screenshots.
|-
| SAL_IGNOREXERRORS
|| unix
|| ooo
|| if set X window system errors are ignored by soffice.bin (Use only if you know what you do. Handle with care!)
|-
| SAL_NO_NWF
|| all
|| ooo
|| Set to nonempty value to disable native widget rendering. Widgets will be painted with the generic vcl methods.
|-
| SAL_PROPERTIES
|| unx
|| ooo
|| If set contains a bitfield activating various bug Xserver bug workarounds. Not very useful nowadays.
|-
| SAL_RTL_ENABLED
|| all
|| ooo
|| Unconditionally enable Right-To-Left layout of UI elements independently from language/script used.
|-
| SAL_SYNCHRONIZE
|| unx
|| ooo
|| Reports X server errors on the calls that made them rather than asynchronously - vital for X debugging.
|-
| STAR_RESOURCEPATH
|| all
|| ooo
|| resource files are searched in ${STAR_RESOURCEPATH} instead of the "resource" subdirectory next to the tools library
|-
| STAROFFICE_USERTYPE
|| all
|| ooo
|| Used in crash report handling. Valid values are "qa", "developer" and "internal". Will be included in crash report if set and marks the report as belonging to a certain usertype group. The only usage of that setting is that the crash report database can be asked afterwards how many reports there where of those groups as opposed to normal users.
|-
| XLSDUMPER
|| all
|| ooo
|| Path to the configuration file of the XLS file dumper. The XLS file dumper is built into debug versions of OOo Calc and allows to create text dumps of every MS Excel file loaded into OOo Calc. The configuration file is part of the sc module and can be found in the CVS repository: /sc/sc/source/filter/excel/xldumper.dat. If this environment variable is set and points to an existing configuration file, the file dumper is enabled (also dependent from the settings in the configuration file). Effective from SRC680m164.
|}

== Environment variables not classified yet ==

Remaining to be done

An authoritative version of this list can easily be generated from [[LXR]] by searching for 'getenv'.

{| class="prettytable sortable"
|-
! Name
!| OS
!| Belongs to
!| Description
|-
| all_proxy
||
||
||
|-
| ALL_PROXY
||
||
||
|-
| AUDIOHOST
||
||
||
|-
| BMP_COLLECT_FILE
||
||
||
|-
| BMP_FSYS_RESOURCES
||
||
||
|-
| BOOST_PRG_MON_CONFIRM
||
||
||
|-
| BOOST_TEST_CATCH_SYSTEM_ERRORS
||
||
||
|-
| CHARSET
||
||
||
|-
| C_INCLUDE_PATH
||
||
||
|-
| CLASSPATH
|| all
|| java
|| Path with Directories and jar files to search for .class files.
|-
| COLUMNS
||
||
||
|-
| COMMAND_SHELL
||
||
||
|-
| COMP_ENV
||
||
||
|-
| COMSPEC
|| win
|| system
|| Path to the batch file command interpreter eg. command.com or 4nt.exe.
|-
| CPLD_ACCESSPATH
||
||
||
|-
| CURL_CA_BUNDLE
||
||
||
|-
| CURL_DEBUG_NETRC
||
||
||
|-
| CURL_MEMDEBUG
||
||
||
|-
| CURL_MEMLIMIT
||
||
||
|-
| CURL_TRACE
||
||
||
|-
| CURL_TRACE
||
||
||
|-
| DBGSV_INIT
||
|| ooo
||
|-
| DBGSV_LOG
||
|| ooo
|| debugging logfile (can be used within debug versions of OOo)
|-
| DB_HOME
||
||
||
|-
| DEBUG
||
||
||
|-
| DESKTOP_LAUNCH
||
||
||
|-
| DYLD_LIBRARY_PATH
||
||
||
|-
| EMXSHELL
||
||
||
|-
| EPMLIST
||
||
||
|-
| ERRORREPORT_PROXYPORT
||
||
||
|-
| ERRORREPORT_PROXYSERVER
||
||
||
|-
| ERRORREPORT_SENDERADDRESS
||
||
||
|-
| FT2_ALLOC_COUNT_MAX
||
||
||
|-
| FT2_ALLOC_TOTAL_MAX
||
||
||
|-
| FT2_DEBUG
||
||
||
|-
| FT2_DEBUG_MEMORY
||
||
||
|-
| FTP_PROXY
|| unix
|| system
||
|-
| ftp_proxy_password
||
||
||
|-
| ftp_proxy_user
||
||
||
|-
| GAI
||
||
||
|-
| GNOME_DESKTOP_SESSION_ID
||
||
||
|-
| GTK_MODULES
||
||
||
|-
| GUISTDIO_KEEPRUNNING
||
||
||
|-
| HelpEx
||
||
||
|-
| http_proxy
|| unix
|| system
||
|-
| HTTP_PROXY
|| unix
|| system
||
|-
| ICU_DATA
||
|| OOo
|| libicu related
|-
| INCLUDE
||
||
||
|-
| JAVA_HOME
|| all
|| java
|| Path to java installation.
|-
| JPEGMEM
||
||
||
|-
| KDE_FULL_SESSION
||
||
||
|-
| LANGUAGE
||
||
||
|-
| LC_PAPER
|| unix
|| system
||
|-
| LD_LIBRARY_PATH
|| unix
|| system
|| usage of [[LD_LIBRARY_PATH]] is a bad idea
|-
| LIBRARY_PATH
|| unix
|| system
||
|-
| LOCALINI
||
||
||
|-
| LOCPATH
||
||
||
|-
| MAKE
||
||
||
|-
| MALLOC_CKCHAIN
||
||
||
|-
| MALLOC_ERRFILE
||
||
||
|-
| MALLOC_FATAL
||
||
||
|-
| MALLOC_WARN
||
||
||
|-
| MIXERDEV
||
||
||
|-
| NAS_EMPTY_SIZE
||
||
||
|-
| NETPATH
||
||
||
|-
| no_proxy
||
||
||
|-
| NO_PROXY
||
||
||
|-
| NPX_PLUGIN_PATH
||
||
||
|-
| OLDSLOTHANDLING
||
||
||
|-
| OOO_PRINT_PS_DIRECTLY
||
||
||
|-
| OPENOFFICE_MOZILLA_FIVE_HOME
||
||
||
|-
| PA_LATENCY_ENV_NAME
||
||
||
|-
| PA_MIN_LATENCY_MSEC
||
||
||
|-
| PA_MIN_LATEWNCY_MSEC
||
||
||
|-
| PATH
|| all
|| system
|| Directories searched for finding programs and depending on OS also shared libraries.
|-
| POSIXLY_CORRECT
||
||
||
|-
| PRODUCTNAME
||
|| ooo
||
|-
| PRODUCTVERSION
||
|| ooo
||
|-
| ProgramFiles
||
||
||
|-
| PSPRINT_ENABLE_TTF_COPYRIGHTAWARENESS
||
||
||
|-
| PYTHONCASEOK
||
||
||
|-
| PYTHONDEBUG
||
||
||
|-
| PYTHONDUMPREFS
||
||
||
|-
| PYTHONEXECUTABLE
||
||
||
|-
| PYTHONHOME
||
||
||
|-
| PYTHONINSPECT
||
||
||
|-
| PYTHONMALLOCSTATS
||
||
||
|-
| PYTHONOPTIMIZE
||
||
||
|-
| PYTHONPATH
||
||
||
|-
| PYTHONSTARTUP
||
||
||
|-
| PYTHONUNBUFFERED
||
||
||
|-
| PYTHONVERBOSE
||
||
||
|-
| PYTHONY2K
||
||
||
|-
| RESOURCE_NAME
||
||
||
|-
| RPMDIR
||
||
||
|-
| RSC_LANG_ISO
||
||
||
|-
| SAL_ACCESSIBILITY_ENABLE_MENU_SELECTED
||
|| ooo
||
|-
| SAL_ANTIALIAS_DISABLE
|| unx
|| ooo
|| font related debugging feature
|-
| SAL_AUTOHINTING_PRIORITY
|| unx
|| ooo
|| font related debugging feature (prefer hinted scan-converted glyph shapes)
|-
| SAL_EMBEDDED_BITMAP_PRIORITY
|| unx
|| ooo
|| font related debugging feature (prefer embedded glyph bitmaps if available)
|-
| SAL_ANTIALIASED_TEXT_PRIORITY
|| unx
|| ooo
|| font related debugging feature (allows embedded glyph bitmap for monochrome text, hinted glyph for grayscaled text)
|-
| SAL_CHANGENOTIFIER_UPDATEINTERVAL
||
|| ooo
||
|-
| SAL_DEBUG_UPDATES
||
|| ooo
||
|-
| SAL_DISABLE_CUPS
|| unx
|| ooo
|| Disable CUPS printing support
|-
| SAL_DISABLE_FLOATGRAB
|| unx
|| ooo
|| Prevent grabbing the X pointer and keyboard when showing a float window (e.g. a menu)
|-
| SAL_DO_NOT_USE_INVERT50
|| unx
|| ooo
|| Graphics card related (maybe S3 Virge) workaround for a bug triggered by card drivers, do not use the 50 percent pattern used to show docking window positions
|-
| SAL_ENABLE_FILE_LOCKING
||
|| ooo
|| file locking related (a lockd must be running)
|-
| SAL_FONTPATH
|| unix
|| ooo
|| the SAL_FONTPATH is added to X fontpath at application start. This allows the usage of private fonts
|-
| SAL_MAXFONTHEIGHT
||
|| ooo
|| some X11 servers have problems with huge native X11 fonts. Setting this environment variable can prevent the problems.
|-
| SAL_MOUNT_MOUNTPROG
||
|| ooo
||
|-
| SAL_MOUNT_SU_DO
||
|| ooo
||
|-
| SAL_MOUNT_UMOUNTPROG
||
|| ooo
||
|-
| SAL_NOEXPANDFPICKER
||
|| ooo
||
|-
| SAL_TRANSPARENT_FLOATS
||
|| ooo
||
|-
| SAL_XKEYBOARDGROUP
||
|| ooo
||
|-
| SESSION_MANAGER
||
||
||
|-
| SGML_CATALOG_FILES
||
||
||
|-
| SHELL
|| unix
|| system
|| Command shell to use
|-
| SOLAR_JAVA
||
|| ooo
||
|-
| SOLARSRC
||
|| ooo
||
|-
| SOLAR_USER_RTL_TEXTENCODING
||
|| ooo
||
|-
| SRC_ROOT
||
||
||
|-
| STAR_BSERVERROOT
||
|| ooo
||
|-
| STAR_ENABLE_FILE_LOCKING
||
|| ooo
|| file locking related
|-
| STAR_INIROOT
||
|| ooo
||
|-
| STAR_INIROOTOLD
||
|| ooo
||
|-
| STAR_OVERRIDE_DOMAINNAME
||
|| ooo
||
|-
| STAR_PROFILE_LOCKING_DISABLED
||
|| ooo
|| file locking related
|-
| STAR_RESOURCE_LOGGING
||
|| ooo
||
|-
| STAR_SSCOMMON
||
|| ooo
||
|-
| STAR_SSOLARINI
||
|| ooo
||
|-
| STAR_STANDLST
||
|| ooo
||
|-
| SWITCHAR
||
||
||
|-
| SW_NOBEEP
||
||
||
|-
| SYSTEM_REGISTRY_NAME_ENV
||
||
||
|-
| TCP_DEVICE
||
||
||
|-
| TCP_SERVER
||
||
||
|-
| temp
||
||
||
|-
| TEMP
|| win
|| system
|| A pathname of a directory made available for programs that need a place to create temporary files.
|-
| TempFolder
||
||
||
|-
| TERM
|| unix
|| system
|| The kind of terminal for which output is to be prepared.
|-
| THREADDEBUG
||
||
||
|-
| tmp
||
||
||
|-
| TMP
|| unx
|| system
|| A pathname of a directory made available for programs that need a place to create temporary files.
|-
| TMPDIR
|| unx
|| system
|| A pathname of a directory made available for programs that need a place to create temporary files
|-
| UPDATER
||
|| ooo
||
|-
| USER
||
||
||
|-
| USER_REGISTRY_NAME_ENV
||
||
||
|-
| UTAUDIODEV
||
||
||
|-
| VERBOSE_RUNTESTS
||
||
||
|-
| XENVIRONMENT
||
||
||
|-
| XLOCAL
||
||
||
|-
| XML_CATALOG_FILES
||
||
||
|-
| XML_DEBUG_CATALOG
||
||
||
|-
| XMLLINT_INDENT
||
||
||
|-
| XML_MEM_BREAKPOINT
||
||
||
|-
| XML_MEM_TRACE
||
||
||
|-
| XMODIFIERS
||
||
||

|}

== Deprecated environment variables ==

Were used, but should not be used anymore.

{| class="prettytable sortable"
|-
! Name
!| OS
!| Belongs to
!| Description
|-
| SAL_WM
|| unx
|| ooo
|| Used to force recognition of a certain window manager. Nowadays not used anymore.
|-
| SAL_NOSEGV
|| unx
|| ooo
|| Used to continue after fatal errors. Not in use anymore.
|-
| XPDISPLAY
|| unx
|| ooo
|| Used to set the display of the Xprint server. Today this is not functional anymore.
|-
| XPRINTER
|| unx
|| ooo
|| Used to set the display of the Xprint server, taking priority over XPRINTER. Today this is not functional anymore.
|}

== Feedback and Explanation ==

This list is under construction. If you have information about the role of some environment variable(s), please modify this page (using "Edit" tab at the very top of this page).

To add information about some environment variable that is listed here, please move it from the "not classified yet" table to the "user" or "developer" table (use cut and paste). Try respecting the alphabetical order. Do not hesitate to add missing environment variables nor to remove any "variable" that appears here by mistake.

Reminder: these are runtime environment variables. Not build system ones.

Categories tables are:

* [[#Environment variables for users]] = users could use them or should know about them
* [[#Environment variables for OOo developpers]] = for developpers only (testing, debugging, getting system information, ...)
* [[#Environment variables not classified yet]] = remaining to be done
* [[#Deprecated environment variables]] = were used, but should not be used anymore

Operating System ("OS") field is:

* (empty) = not known yet
* linux = GNU/Linux
* mac = Mac OS X
* solaris = Solaris
* other = other UNIX-like system
* win = Microsoft Windows
* unx = linux + mac + solaris + other
* all = unx + win

"Belongs to" field is:

* (empty) = not known yet
* ooo = introduced by OOo
* system = belongs to the underlying operating system(s)

The original list of the environment variables was extracted from the OOo sources.

[[Category:Porting]]
[[Category:Development]]
[[Category:Build_System]]

Debugging

2008-12-29T02:56:13Z

DavidRoss: added Category:Build_System

This section assumes use of [[wikipedia:GNU Debugger|gdb]], from the console. There are also specific notes on [[Windows Debugging]] or graphical tool on Mac OS X ( see : [[MacOSX_Debug_OpenOffice.org_using_XCode]] ) and hints on [[Debug Build Problems|Build Problems Debugging]]

== Building with debugging symbols ==

OO.o includes a way to add debugging code in per module, via
the <code>build debug=true</code> command in each module.
This also adds lots of runtime assertions,
churning warnings etc. in addition to debug symbols - which
can be useful. To do just a plain build with debug symbols
though use <code>build debug=true dbg_build_only=true</code>
or in later versions use <code>build debug=true dbglevel=2</code> for max
output and dbglevel=1 or 0 for less output.

You can also configure OO.o with --enable-symbols to build with symbolic generation.

== gdb invocation ==

If you debug with gdb, you may find that execution stops due to signals at inappropriate locations, especially if running against libgcj and need to debug ignoring its [http://gcc.gnu.org/java/gdb.html garbage-collection]. Best invocation is...

<pre>
gdb ./soffice.bin
(gdb) handle SIGPWR nostop noprint
(gdb) handle SIGXCPU nostop noprint
(gdb) handle SIG33 nostop noprint
(gdb) run -norestore -writer
</pre>

replace -writer with -draw/-impress/-calc/... as appropriate. The -norestore option prevents display of the crash reporter (as one frequently kills office during debugging).

== The recommended .gdbinit file ==

You can add the <tt>handle</tt> commands from above to your <tt>~/.gdbinit</tt> to save some typing. Also you can define there macros to print the content of strings even in cases where dbg_dump() does not work. The following is such recommended <tt>~/.gdbinit</tt> file:

<pre>
set history filename ~/.gdbhistory
set history save on

handle SIGPWR nostop noprint
handle SIGXCPU nostop noprint
handle SIG33 nostop noprint

tabset 4

# define "pu" command to display sal_Unicode *
def pu
set $uni = $arg0
set $len = $arg1
set $i = 0
printf "\""
while (*$uni && $i++<$len && $i<255)
if (*$uni < 0x80)
printf "%c", *(char*)$uni++
else
printf "\\x%x", *(short*)$uni++
end
end
printf "\"\n"
end

# define "pus" command to display rtl_uString
def pus
set $ns = $arg0
if ($ns.buffer)
pu $ns.buffer $ns.length
else
print "Invalid/non-initialized rtl_uString."
end
end

# define "pou" command to display rtl::OUString
def pou
set $ns = $arg0
if ($ns.pData)
pus $ns.pData
else
print "Invalid/non-initialized OUString."
end
end

# define "ptu" command to display tools (Uni)String
def ptu
set $ns = $arg0
if ($ns.mpData)
pu $ns.mpData->maStr $ns.mpData->mnLen
else
print "Invalid/non-initialized tools String."
end
end
</pre>

With this, you can use <tt>pou the_OUString</tt> in gdb to print <tt>OUString</tt> named <tt>the_OUString</tt>, similarly <tt>pus the_rtl_uString</tt> for <tt>rtl_uString</tt> and <tt>pu the_p_sal_Unicode</tt> for <tt>sal_Unicode *</tt>. For tools's UniString (or just String for historical reasons) you can use <tt>ptu the_String</tt>

== Starting at the beginning ==

We start in 'main' with a sal wrapper, that calls
vcl/source/app/svmain.cxx (SVMain). It invokes Main on
pSVData->mpApp; but pSVData is an in-line local. To
debug this use the pImplSVData global variable. eg:

p pImplSVData->maAppData

This 'Main' method is typically: <code>desktop/source/app/app.cxx (Main).</code>

== Examining strings ==

We have [[Hacking#Can_I_get_a_char_.2A.2C_please.3F|already]] seen that OO.o has
its own set of string classes, none of which gdb understands.
You need to use:
<code>(gdb) print dbg_dump(sWhatEver)</code> to print the contents
of a UniString/ByteString/rtl::OUString/rtl::OString regardless
of the type when debugging C++ code. See Caolan's
[http://www.skynet.ie/~caolan/TechTexts/GdbUnicodePrinting.html write-up]
for details.

the functions <code>dbg_dump()</code> may not be available in gdb due to link. Just copy them in your current source file from '/sal/rtl/source/debug_print' and add the associated includes <code>#include <rtl/strbuf.hxx> #include <rtl/ustring.hxx></code>. gdb should recognize them now.

Another way is to use the macros from the [[Debugging#The_recommended_.gdbinit_file|recommended .gdbinit file]]. Unfortunately, so far works only for OUString, sal_Unicode *, and rtl_uString.

== Getting the build order right ==

The build dependencies of the modules are clearly crucial to
getting a clean build. When you type 'build' in a module, first
build examines prj/build.list, eg.<code>neon/prj/build.lst</code>:

xh neon : soltools external expat NULL

this specifies that 'soltools', 'external' and 'expat' have to
be satisfactorily built and delivered before neon can be built.
Occasionally these rules get broken, and people don't notice for
a while.

== It crashes, but only in gdb ==

What fun — you symlinked desktop/unxlngi4.pro/bin/soffice to
soffice.bin in your install tree didn't you. That works fine
if you just run it, but it seems gdb unpacks the symlink and
passes a fully qualified path as argv[0], which defeats the
hunting for the binary in the path, so it assigns the program
base path as <code>/opt/OpenOffice/OOO_STABLE_1/desktop/unxlngi4.pro/bin</code>
and starts looking for (eg. applicat.rdb) in there. Of course
when it fails to find any setup information, it silently
crashes somewhere else yards away from the original problem.

== It crashes, but doesn't crash ==

For various reasons signal handlers are trapped and life
can get rather confusing; thus it's best for builders to
apply something like this:

<pre>
--- sal/osl/unx/signal.c
+++ sal/osl/unx/signal.c
@@ -188,6 +188,8 @@ static sal_Bool InitSignal()
bSetILLHandler = sal_True;
}

+ bSetSEGVHandler = bSetWINCHHandler = bSetILLHandler = bDoHardKill = sal_False;
+
SignalListMutex = osl_createMutex();

act.sa_handler = SignalHandlerFunction;
</pre>

== I can't find the code from the trace ==

Some methods, are described as having a special linkage, such that
they can be used in callbacks; these typically have a prefix:
'LinkStub', so search for the latter part of the identifier in a
freetext search. eg.
<pre>
IMPL_LINK( Window, ImplHandlePaintHdl, void*, EMPTYARG )
</pre>

builds the 'LinkStubImplHandlePaintHdl' method.

== How can I re-build just the files I see in the trace ==

Often when you run gdb on a build without debugging symbols, you get an unhelpful gdb trace, but yet you can't afford the time/space to recompile all of OO.o with debugging symbols. Thus we have created a small perl helper, which will hunt for and touch files containing the symbols from your trace. This sub-set can then be re-built with debugging enabled for a better trace next time around:

<pre>
gdb ./soffice.bin
...
bt
#0 0x40b4e0a1 in kill () from /lib/libc.so.6
#1 0x409acfe6 in raise () from /lib/libpthread.so.0
#2 0x447bcdbd in SfxMedium::DownLoad(Link const&) () from ./libsfx641li.so
#3 0x447be151 in SfxMedium::SfxMedium(String const&, unsigned short, unsigned char, SfxFilter const*, SfxItemSet*) ()
from ./libsfx641li.so
#4 0x448339d3 in getCppuType(com::sun::star::uno::Reference<com::sun::star::document::XImporter> const*) () from ./libsfx641li.so
...
quit
cd base/OOO_STABLE_1/sfx2
ootouch SfxMedium
build debug=true
</pre>

Thus, all files referencing or implementing anything with SfxMedium will be touched, and hence rebuilt with debugging symbols.

[http://go-oo.org/developers/ooo-build/bin/ootouch ootouch] is not available upstream: it is available through ooo-build.

== How can I re-build all the files in one source directory ==

If you want to recompile the code in just your current directory, you can
use the killobj dmake target to remove the object files:

<pre>
dmake killobj
dmake
</pre>

== It always crashes in sal_XErrorHdl ==

You are a victim of asynchronous X error reporting;
<code>export SAL_SYNCHRONIZE=1</code> will make all the X traffic
synchronous, and report the error by the method that caused it,
it'll also make OO.o far slower, and the timing different.

== It silently fails to load my word file ==

Caolan suggests: put breakpoints in ww8par.cxx top and tail of
SwWW8ImplReader::LoadDoc, and confirm that the document gets as far
as the import filter.

A handy human place to put a breakpoint is in
SwWW8ImplReader::ReadPlainChars, you can see chunks of text as
they are read in. Alternatively SwWW8ImplReader::AppendTxtNode as
each paragraph is inserted.

== How do I use the debug console ? ==

So OO.o contains some hefty debugging infrastructure; pictured
[http://go-oo.org/images/debug-window.png here] '''(FIXME BROKEN LINK)'''

Enabling it is pretty easy - what you need is a so-called [[Non_Product_Build|Non-Product Build]].

By default, an OpenOffice.org build is a Product Build, i.e. ready for release after completion. If you specify the <code>--enable-dbgutil</code> switch during <code>configure</code>, then your environment will be prepared for a [[Non_Product_Build|Non-Product Build]] - with lots of additional diagnostic tools.

Note that libraries from product and non-product builds are usually incompatible, so don't mix them in the same installation.

For available tools in non-product builds, have a look at the various <code>DBG_foo</code> macros in <code>tools/debug.hxx</code>, or, if you already are knowledgeable about this, let others participate by writing your knowledge down here.

To actually fire up the debug settings dialog, press <ctrl><alt><shift>-D.

== Draw/Impress text edit debugging ==

When running a [[Non_Product_Build|Non-Product Build]], live edit mode in Draw/Impress text boxes has an extra debug hotkey: pressing <ctrl><alt>-F2 writes information about the currently edited text into a debug.log file (currently Windows-only).

== Excel Interop debugging ==

This is fairly easy; define an environment variable XLSDUMPER pointing to the file sc/source/filter/excel/xldumper.dat (full path needed). Then run <code>soffice.bin foo.xls</code> and you should get a foo.xls.txt in the same directory with the debug data in it.

Note: this requires a debug build of the <code>sc</code> module. To easily get such a build, execute the following within your <code>sc</code> directory: <code>build -- killobj ; build debug=true</code>

== The trace shows a crash in 'poll' ==

OO.o is a fairly threaded program, you're probably just looking at the wrong thread: there are not likely to be bugs in poll. Use <code>thread apply all backtrace</code> to get a backtrace of all threads - this will most likely fail. When it does do: <code>thread 1</code> then <code>bt</code> - most crashers occur in the 'main' thread.

== What does this trace mean ? ==

There are several typical stack-traces that come up again
and again, one would be:

<pre>#15 0x4164a501 in raise () from /lib/tls/libc.so.6
#16 0x4164bcd9 in abort () from /lib/tls/libc.so.6
#17 0x415fb5a5 in std::set_unexpected ()
from /home/mnagashree/m72install/program/libstdc++.so.5
#18 0x415fb5e2 in std::terminate ()
from /home/mnagashree/m72install/program/libstdc++.so.5
#19 0x415fb69c in __cxa_rethrow ()
</pre>

This section of trace means (essentially) that an
exception was thrown - but there was no-one trying to
catch it. Often this means there was a missing
'try {} catch()' clause in one of the calling frames.

A great way to debug exceptions is to add a breakpoint
in catch/throw, do this with <code>catch throw</code> or
<code>catch catch</code> in gdb.

== Useful places to put breakpoints ==

If you have compiled with debugging enabled: <code>build debug=true</code> it is possible that you get some nice churning debug / assertion failure - and you want to get a pleasant & detailed stack-trace: to do that do
<code>break osl_assertFailedLine</code>.

== STLport and checking iterators ==

The STL is a powerful tool but it also makes it easy - in the grand old C/C++ tradition - to shoot one selves in the foot, as we all know. STL containers and algorithms are now pervasive in OOo, so there is a need to validate the use of STL constructs in OO.o to find hidden problems.

Fortunately the [http://www.stlport.org/ STLport library] - the default STL implementation for OO.o - has a powerful debug mode, and it's easy to use. Since SRC680 m128 it is possible to use the environment variable <code>USE_STLP_DEBUG</code> to switch on the STLport debug mode, since SRC680 m150 it works for Windows, too

The most useful part of the STLport debug mode is iterator checking. Doing the OO.o smoke test and some little additional random testing we already found a number of questionable STL constructs.

Only code paths which are exercised will be tested by the STLport debug mode, though. If STLport finds a questionable STL usage it will throw an assertion and terminate. It is usually quite easy to extract a precise stack trace.

Some notes:
* STLport debug mode iterators are no pointers! We've cleaned up all occurrences of the lazy - and wrong - usages of iterators as pointers in SRC680 m128/m150, but maybe something new has already crept in. This clean up also helps with other STL implementations, like the one which comes with gcc-4.x
* A complete recompile is necessary, the debug modes renders all objects with STL constructs binary incompatible
* The STLport debug mode breaks the complexity assertions of the STL. Theoretically some operations should be much slower in debug mode than in product mode. In practice I didn't notice a real slowdown of OO.o.

[[Category:Development]][[Category:Build_System]]

Hacking

2008-12-29T02:55:17Z

DavidRoss: added Category:Build_System

{|
|
== My first hack ==

So - we've built and run OO.o, and we want to prove to ourselves that it is in fact possible to hack on it. So in a new terminal do this:

cd build/src680-m66
. ./LinuxX86Env.Set.sh
cd vcl

Now have a hack at vcl/source/window/menu.cxx (Menu::SetItemText);
(near line 1770) I suggest manually applying this change:

- pData->aText = rStr;
+ pData->aText = String(rStr).Reverse();

Then save. ( You can find more sensible things to hack in the [[Tutorials]] )

You're still in vcl/ yes ? then type 'build debug=true'; wait for the scrolling text to stop; (5 seconds?). Now re-run
<code>soffice -writer</code>. You should notice the effect in the menus.
If not, ensure the previous soffice.bin was dead with
<code>killall -9 soffice.bin</code>

'''Note:''' for day to day hacking you want to just run 'build' inside the source tree. It is also highly recommended to work inside a copy of the build tree, and generate / test patches in an un-hacked version. To copy just the build/src680-m66 directory elsewhere, you need to use the [[ relocate ]] tool.

== Read the Fine manual ==

With the power of C++ comes the ability to shoot yourself in the foot all the more easily; (and implicitly), cf. Holub, Rules for C and C++ programming, McGraw-Hill, 95.


The best way to prepare yourself for battle is to read the
[http://tools.openoffice.org/CodingGuidelines.sxw OpenOffice coding guidelines], and for the easily confused c'tor / d'tor is short for
constructor / destructor.


Also, there's an extensive list of [[Recommended_Reading|recommended literature]] about C++ - but that's of course no prerequisite to start coding.

== Sending patches ==

The toplevel structure of the OO.o source code is not the same as the layout of the CVS repository [ a good rational for this strange state of affairs is absent ]. Thus to work out what real module a file is in you need to do eg.
cd binfilter
cat CVS/Repository
framework/binfilter
This shows you that the '[[Framework/Modules/binfilter|binfilter]]' directory is part of the [[Framework|'framework' project]].

These days there is a [http://qa.openoffice.org/issue_handling/submission_gateway.html#code_module hackers bug filing page] that will assign bugs to the correct project, and the correct owner to get rapid attention.

== Starting the right app ==

As you start soffice.bin, there are several useful parameters to
use to accelerate your debugging experience; particularly
<code>-writer</code>, <code>-calc</code>, <code>-draw</code>,
and (the wizardly painful) <code>-impress</code> arguments.


== Understanding D' make (man) ==

While the build system is in similar to many other systems, it is also perhaps slightly different. The overview is that each module is built, and then the results are delivered into the [http://www.openoffice.org/dev_docs/source/solver.html solver]. Each module builds against the headers in the solver. Thus there are a few intricacies.

<ul>

<li id="build">
build — this perl script solenv/bin/build.pl is
used in conjunction with [[Hacking#prj/build.lst|prj/build.lst]]
to ensure that every module that is needed is built first. 
build then un-winds internal module dependencies, and builds
each module with a chdir, dmake pair.
</li>

<li id="deliver">
deliver — this perl script solenv/bin/deliver.pl
installs headers, and libraries (etc.) into the solver, as
informed by [[Hacking#prj/d.lst|prj/d.lst]]. Crucially
deliver ensures that the date stamp on any file that is
installed to the solver is the same as that in the module's
directory. This ensures, that (particularly for headers) that
there is no dependency cascade triggering re-builds in other
modules.
</li>
</ul>

=== Standard directories ===

There are various standard directories and files in most of the modules that make up OO.o, here are some of the more useful:

*'''prj'''
**''build.lst'' — this lists directories to be made, '^#' comments are allowed, the order of the list is immaterial see [[Hacking#prj/build.lst | detail]], it is dictates ''build'''s operation.
**''d.lst'' — this file describes the ''deliver'' process, see [[Hacking#prj/d.lst | detail]].
*'''util''' — typically the util directory is charged with glueing together the sub-libraries for each sub-module into a single large library, adding system library dependencies, building GUI resource files etc. All the work is described in ''makefile.mk'', this is usually the last directory to be built in a project.
*'''inc''' — public headers are typically separated into an 'inc' directory, these will be installed into the solver by the 'deliver' phase (using [[Hacking#prj/d.lst | prj/d.lst]])

Build's mode of operation is to invoke 'dmake' in each of the projects' directories with a given dependency order. dmake then executes the rules in makefile.mk.

=== prj/build.lst ===

On first view build.lst looks scary:
<pre>
vc vcl : NAS:nas FREETYPE:freetype psprint rsc sot ucbhelper unotools sysui NULL
vc vcl usr1 - all vc_mkout NULL
vc vcl\source\unotypes nmake - all vc_unot NULL
vc vcl\source\glyphs nmake - all vc_glyphs vc_unot NULL
...
vc vcl\mac\source\src nmake - m vc__srcm vc_unot NULL
vc vcl\util nmake - all
vc_util vc__plug.u vc__appa.u vc__appm.m vc__appu.u vc__appw.w vc__gdim.m
vc__gdiu.u vc__gdiw.w vc__srcm.m vc__srcu.u vc__srcw.w
vc__wina.u vc__winm.m vc__winu.u vc__winw.w vc__du.u
vc__gtka.u vc__gtkw.u vc__gtkg.u vc__kde.u vc_app
vc_ctrl vc_gdi vc_hlp vc_src vc_win vc_glyphs NULL
</pre>
so we need to try and un-pack what's going on here, which is in fact not
as odd as it might seem at first glance. Firstly lists are terminated
by the 'NULL' string. Every line is prefixed by a shortcut which has to be unique, no two modules are allowed to have the same shortcut.

<ul>
<li>
First active line contains a ':', this describes the
fact that this project (vcl) depends on these other modules
'nas', 'freetype', 'psprint' etc. to be built first. This is
for inter-project dependencies.
</li>
<li>
Some modules have a CAPITALS:lowercase arrangement; the first
segment is a conditional, driven by a space delimited list in
the BUILD_TYPE environment variable at build time.
</li>
<li>
Then we have a redundant line 'usr1' [ for fun ? ], in fact
only lines containing the magic string 'nmake' are valid after
this.
</li>

<li>
The next lines describe internal project directory dependencies
and look like:
<pre>
[shortcut] [path to dir to build] nmake - [flags] [unique-name] [deps...] NULL
vc vcl\source\glyphs nmake - all vc_glyphs vc_unot NULL
</pre>
shortcut is not used; flags determines which platforms
this builds on; usually single char platform codes: 'dnpum' 'u' being
Unix. The higher up the system, the more stuff is flagged 'all'. 
unique-name this is a magic name, used by other lines to
describe an internal dependency. deps... any number of names of
other directories in this file, that must be built before this one. If such prerequisite dir is built for special platforms only, the platform code has to be appended to its magic name.
</li>

</ul>

So we see in the vcl case that vcl\source\unotypes (vc_unot) has to be built before vcl\source\glyphs (vc_glyphs). For Mac vcl\mac\source\src (vc__srcm) has to be built before vcl\util (vc_util) It is '''important''' to understand that the order of the list is ~immaterial, and instead of a simple ordered list, we have a more complex internal dependency system — this contrasts with most other make systems.

There is also documentation [http://tools.openoffice.org/tools/build.html here] on it.

=== deliver, deliver.log and prj/d.lst ===

The syntax of d.lst is more comprehensible than build.lst, it omits
some default actions, such as copying build.lst into
inc/<module>/build.lst.

A line is of the form:

[action]: [arguments]
mkdir: %_DEST%\inc%_EXT%\external

where if '[action]:' is omitted, it defaults to the 'copy' action. Typical actions are copy, mkdir, touch, hedabu, dos and linklib.

The 'hedabu' action is particularly interesting, inasmuch that it
cosmetically re-formats the header to shrink it on install and adds the module name to the include path (''#include "my_header.hxx"'' becomes ''#include <my_module/my_header.hxx>''). Otherwise it's much like the copy action.

During the action, various macro variables are expanded some of which are:
* %__SRC% — distribution directory name eg. unxlngi4.pro</li>
* %_DEST% — absolute path into solver eg. /opt/OpenOffice/OOO_STABLE_1/solver/641/unxlngi4.pro
* %_EXT% — (unusual) way of having minor updates eg. 641.1, typically used to version every base sub-directory.

Typically then, if indeed you need to add a rule (cf. implicit directory copies), it will be of the form:
..\%__SRC%\inc\sal\*.h %_DEST%\inc%_EXT%\sal\*.h

NB. relative paths are relative to the 'prj/' directory.

Sometimes you might run into the situation where you'd like to remove the delivered files from solver. Your configuration might have changed and they are no longer needed. "deliver -delete" does just that, however you might still need to delete "deliver.log" files manually as well.

== Can I get a <code>char *</code>, please? ==


Just barely. OO.o has at least six string wrappers, although the C
implementations are of little interest:


<ul>
<li>


<code>rtl_String</code> — sal/inc/rtl/string.h 
"Normal" string plus reference counting.
<code>rtlstring-</code>><code>buffer</code> is useful, as is
<code>rtlstring-</code>><code>length</code>. This object encapsulates
an generic 8bit string - of unknown encoding. Feel free to treat
<code>rtlstring-</code>><code>buffer</code> as your beloved <code>char *</code>.
If you really want to look at the implementation of some
<code>rtl_String</code> function and lxr nor grep can help you, have
a look at sal/rtl/source/strtmpl.c.


</li>

<li>

<code>OString</code> — sal/inc/rtl/string.hxx 
Simply a rtl_String wrapped inside a <code>class</code>; you
can use <code>ostring.pData</code> to get at the rtl_String
(it's public). <code>OString</code> has reasonably useful
methods for if you need them.


</li>

<li>

<code>rtl_uString</code> — sal/inc/rtl/ustring.h 
"Normal" Unicode string, similar to rtl_String, and
refcounted as well. However, this one always comes in UCS-2
encoding, presumably to be compatible with Java's
questionable choices.
See <code>rtl_String</code> above to find where the implementation
of some <code>rtl_uString</code>functions is hidden.


</li>

<li>

<code>OUString</code> — sal/inc/rtl/ustring.hxx 
An rtl_uString wrapped inside a <code>class</code>. This is
what most of the OO.o code uses to pass strings around.
To convert an <code>OString</code> to an <code>OUString</code>

it is necessary to specify the character set of the
<code>OString</code> see; <code>sal/inc/rtl/textenc.h</code>
— the only interesting case is <code>RTL_TEXTENCODING_UTF8</code>

</li>

<li>

<code>String</code> — tools/inc/string.hxx 
This is an obsolete string class, aliased to 'UniString'.
It has a number of limitations such as a 64k length limit. You can have the buffer with <code>GetBuffer()</code>, but it's Utf-16 encoded.

</li>
</ul>

A couple of conversion functions are really useful here, particularly: 
<code>rtl::OString aOString = ::rtl::OUStringToOString (aOUString, RTL_TEXTENCODING_UTF8);</code>
 And the reverse: 
<code>rtl::OUString aOUString = ::rtl::OStringToOUString (aOString, RTL_TEXTENCODING_UTF8);</code>

If you just want to programattically print out a string for debugging purposes you probably want define a macro like : 
<code>#define CHAR_POINTER(THE_OUSTRING) ::rtl::OUStringToOString (THE_OUSTRING, RTL_TEXTENCODING_UTF8).pData->buffer</code>
 and use it like : 
<code>printf ( "SvXMLNamespaceMap::AddIfKnown : %s / %s\n", CHAR_POINTER(rPrefix), CHAR_POINTER(rName) );</code>.
 For the obsolete String class, aliased UniString, it's like : 
<code>printf ( "rGrfName : %s\n", ByteString( rGrfName, RTL_TEXTENCODING_UTF8).GetBuffer() );</code>

To print the value of rtl::OUString directly in the debugger, you can use <code>dbg_dump()</code>. It is intended to be called interactively from the debugger, in both debug and non-debug builds of OOo. You can see the definition in sal/rtl/source/debugprint.cxx.

Some code snippets about manipulating those objects can be found on the codesnippets service page : [http://codesnippets.services.openoffice.org/Office/cpp.xml]

== Linkoo & Limitations ==

Linkoo is the tool that implements the <code>-l</code>
functionality of <tt>[[bin/ooinstall]]</tt>. It essentially
sym-links files of similar names into your local tree,
allowing a fast development iteration.


It is however slightly limited - some of the modules
cannot be linked for various reasons; these are:
<code>cppuhelper</code> and <code>configmgr</code>,
thus in the rare case that these are altered, they
must be copied manually into <code>/opt/OOInstall/program</code>.


In addition symlinks cannot be used for soffice.bin, and this is more commonly altered - it has to be installed from <code>desktop/unxlngi4.pro/bin/soffice</code> NB. with an appended '.bin'

== See also ==

* [[Debugging]]
* [[Using_Cpp_with_the_OOo_SDK|Using C++ with OOoSDK]]

| valign="top" |
{{Hacking|Languages}}
|}

[[Category:Development]]
[[Category:Build_System]]

FAQ

2008-12-29T02:52:08Z

DavidRoss: added Category:Build_System

{{DISPLAYTITLE:Development FAQ}}

[[Documentation/FAQ|There are also user FAQs!]]


So no-one ever asked me these, I just made them up to astro-turf
a bit (safer, wipe-clean, more durable questions).


== Why do branches like 'mws_srx645' have odd numbers in them ? ==


By consulting various oracles, entrails etc. it transpires that
in theory this number once incremented weekly, there being weekly
freezes and hence solvers, development environments.
The 'mws' stands for 'Master Workspace'. Master Workspaces for releases
are on CVS branches. Those branches are named with Master Workspace
name, f.e. 'mws_ooh680' is the name of the branch of workspace OOH680,
used for OpenOffice.org 2.4.
The latest 3.0 development is done with the DEV300 stem ob CVS HEAD;
with auto-incrementing milestones; hence milestone tags like
<code>DEV300_m5</code> would be common.


== Why does XYZ require Java ? up-stream/Sun are so evil !? ==

Nah up-stream just use the best tool to hand, and have a different set world-view to you, where Java is an engineering solution to their cross platform problems. By using Java StarDivision can avoid having to re-invent and then maintain an essentially competing cross-platform layer. There is no malice here whatsoever; just pragmatic engineering from a different perspective.

See [[Java and OpenOffice.org]]

== Why is [t]csh so broken ? ==


This is rather inscrutable; some particularly curious brokenness
would be the way piping commands on stdin is crucially different
to inputting them from the tty thus:
<code>echo 'echo #define DLL_NAME "libsch641li.so" >./foo.hxx' | /bin/tcsh -s</code>
fails to do anything whereas typing the same thing into the shell
works just fine. Even more oddly:
<code>tcsh -fc 'echo #define DLL_NAME "libsch641li.so" >./foo.hxx'</code>
does do the right thing. See also [http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/ csh].


== I just tried to re-locate the build, why doesn't it work ? ==


The simple answer is: you need to run <code>relocate /path/to/new/build</code>;
another more complex answer is:


Well, assuming you have re-configured things (LinuxIntelEnv.Set will
need paths tweaking too — and re-importing to your shell) — then it's most
likely down to the ubiquitous non-relative paths, coded in lots
of generated / built files, particularly '.dpc*' (dependency)
files. Try:
<code>find -name '*.dpc*' -exec rm {} \;</code>


The stlport does some really broken things, so
you will also need to edit the 'stl_gcc.h' inside the solver/, and replace the
two path instances there (see inc/stl/config/stl_gcc.h. )

== CVS says 'Fatal Error aborting. [acc] no such user', why ? ==


While of course it's possible that your user name is not registered; often
this just means your ~/.cvspass got lost and/or that you haven't logged in.
cvs login, and repeat the command.


== What does '.pro' in 'unxlngi4.pro' mean ? ==


Product — isn't it obvious ?


== What does OpenOffice really look like ? ==


Today I found a photograph of it on my system, so I stuck it in here:


http://go-oo.org/images/layers.png Abstraction Layers

SW: Star Writer 
SD: Star Draw 
SC: Star Calc 
SCH: Star Chart 
SFX: Star Framework ??? 
SVX: Star View X for miscellany ?, it's a bit of a dumping ground for dialogs and shared between apps code 
UNO: Universal Network Objects 
UCB: Universal Content Broker 
SBL: Scripting And Basic Library 
SO: ??? 
VOS: Virtual Operating System 
VCL: Visual Class Library 
STL: Standard Template Library 
RTL: Run Time Library 
OSL: Operating System Library 

== How do I take a screenshot of OO.o ? ==

OOo does some very odd things with X resources, thus some conventional
screenshot apps fail to take accurate shots. ImageMagick's 'import'
however does a good job; use:

import foo.png

from the console, or

sleep 2; import -window root foo.png

instead.

NB. unless you want your world to look tiny, you need to turn large toolbar icons first.

You can also use [http://www.gimp.org The GIMP] to Acquire Screenshots of OpenOffice.org.
From the Gimp:
* Click '''File'''
* Click '''Aquire'''
* Click '''Screen Shot'''

== Why does the code look so ugly? ==

The authors must be using a really strange editor.
It thinks tab stops are on every fourth column.
Of course, the files come out ugly in Unix editors which know
that tabs are eight characters wide.


If you happen to use
[http://www.gnu.org/software/emacs/ a Real Editor],
we have some pink glasses to sell to you. Paste the contents of
[http://go-ooo.org/emacs.el] into your <tt>.emacs</tt>,
or load it with a line like this: <tt>(load "/path/to/that/file.el")</tt>.
Don't forget to adapt <tt>my-openoffice-path-regexp</tt> to your needs.


Henceforth emacs will use 4-column tabs for your OOo source files.
(And use C++-Mode for <tt>sdi</tt>-, <tt>hrc</tt>-,
and <tt>src</tt>-files.) Alternatively if you are sufficiently set in
your ways that you can't cope with investing these few seconds do:
<code>M-x set-variable\ntab-width 4</code> & learn to love change.


Apparently if you use vi you can do: <code>:set ts=4 sw=4</code>, and
good luck to you. For a better vim, use <code>:set ts=4 sw=4 et</code> to also expand tabs to spaces, as this is what new code should use.


== Where can I suggest ideas for what OpenOffice.org should do and what I don't/do like about it? ==
''Awaiting an answer from a kind contributor.''

== How can OOo be used to author wiki pages at a MediaWiki site?==
''Awaiting an answer from a kind contributor.''

== Can the content of a MediaWiki hosted wiki be exported into OOo? ==
''Awaiting an answer from a kind contributor.''

The dream idea is to take a complete wiki and flow it into a filter so that it can be exported into a series of OOo documents, or one larger OOo document. This would allow writters to start a wiki and then finish with a book.

I'm not sure if they can be exported from MediaWiki to OOo, but the reverse is possible. If you follow :- [[http://wiki.services.openoffice.org/wiki/Odt2Wiki Odt2 To Wiki]]

== How can OOo be used to author blog pages at a Blogspot.com hosted site? ==
A filter exists for MS Word users to write blog articles -- and then upload the content to the blog easily. A similiar add-on is [http://people.redhat.com/caolanm/oooblogger/ oooblogger] which is an experimental blogger plugin for OOo which is not complete, but is a suitable starting position for a developer (python) who wants to tackle this area

== See also ==

* [[CvsFAQ]] - for CVS problems
* [[OOo_Ergonomics]] - why is it so painful to use ?
* [[Bibliographic/FAQ]] - for bibliographic problems
* [[CWS|How to use Childworkspaces]]

[[Category:Development]]
[[Category:Build_System]]

OOoHelpOutline

2008-12-29T02:51:38Z

DavidRoss: added Category:Build_System

{{Documentation/Candidate}}

'''Welcome to the outline of existing OpenOffice.org user resources!'''

<div>

[[image:documentation_exclamation.png|40px]] This article is outdated. (But it may still contain a lot of helpful links)

</div>

The OOo Help Outline moved to OpenOffice.org's Wiki to help open its accessibility as much as possible to the OpenOffice.org community, so that all may help to keep it current and reliable.

See also [[Press coverage on OpenOffice.org]] for various articles, reviews and tips related to OpenOffice.org.

==Product==

===Overview===

* [[Documentation/Dashboard/Application Online Help|Application Online Help]]
* [http://www.openoffice.org/ OpenOffice.org's Home Page]
** [http://www.openoffice.org/product/ OpenOffice.org Product Description]
** [http://www.openoffice.org/sitemap.html OpenOffice.org's Site Map]
** [http://marketing.openoffice.org/2.0/featureguide.html OpenOffice.org 2.0 Office Suite - Guide to New Features]

* [http://documentation.openoffice.org/manuals/index.html OpenOffice.org User Guide]
* [http://support.openoffice.org/index.html OpenOffice.org Support Area]
**List of links to free community support, commercial support and training, OpenOffice.org books, and general community resources.

* [http://openoffice.start4all.com/ openoffice.org.start4all.com]
* [http://en.wikipedia.org/wiki/OpenOffice.org OpenOffice.org at Wikipedia] ([http://en.wikipedia.org/wiki/Category:OpenOffice.org OpenOffice.org Category])

Related Products
* [[StarOffice|StarOffice Office Suite]]
* [http://portableapps.com/apps/office/suites/portable_openoffice Portable OpenOffice.org]

===FAQs===

* [[Documentation/FAQ|Documentation Project FAQs]]
* [http://www.openoffice.org/faq.html OpenOffice.org's General FAQs]
* [http://www.bytebot.net/openoffice/faq.html The OpenOffice.org UnOfficial FAQs by Colin Charles]
* [http://www.openoffice.org/FAQs/fontguide.html Font Troubleshooting Guide]

Also from this Wiki:
* [[Font-FAQ]] (in progress)
* [[Bibliographic/Hints and Tips]]
* [[VBA|MS Office VBA Macros]]

===Downloads===

* [http://download.openoffice.org/#latest OpenOffice.org Download Central]
* [http://download.openoffice.org/2.0.2/index.html OpenOffice.org 2.0.2]
* [http://download.openoffice.org/1.1.5/index.html OpenOffice.org 1.1.5]
* [http://www.openoffice.org/dev_docs/source/1.0.3/index.html OpenOffice.org 1.0.3.1] (use this for Windows 95)

===Installation===

* [http://documentation.openoffice.org/setup_guide2/index.html OpenOffice.org's Setup Guides for 1.x and 2.x]
** Good stuff: version 2.x of the Setup Guide provides extensive instructions for installation on ''many'' Linux distros and UNIXes (in addition to Windows):
*** Linux: RPM-based distro, Debian-based distro, Gentoo, Slackware
*** UNIX: Solaris, FreeBSD, Mac OS X
** Another install guide for Debian: [http://www.reallylinux.com/docs/oo2install.shtml Installing OpenOffice.org 2.0 for Debian]
** [http://www.oooforum.org/forum/viewtopic.phtml?t=33125 Adding interface language to existing OpenOffice.org]
* [http://www.openoffice.org/dev_docs/instructions.html OOo's Instructions for Installing and Setting Up OpenOffice.org 1.1.x]
* [http://download.openoffice.org/index.html OpenOffice.org's Download Central]
* [http://user.services.openoffice.org/en/forum/viewforum.php?f=6 OpenOffice.org Forum: Setup and Configuration]
* [http://user.services.openoffice.org OpenOffice.org Community Forum]
* [http://www.hypermax.net.au/~settantta/ooo/default.html Alex Fisher's OpenOffice.org Introduction]
* [http://www.openoffice.org/FAQs/build_faq.html Build FAQs for OpenOffice.org]

* Dictionaries: Please see [[OOoHelpOutline#Dictionaries|the Dictionaries sub-section]] for further information.
* Java issues
** [http://java.com/java/download/index.jsp Java.sun.com] - Download the [[Wikipedia:JRE|Java Runtime]] for use with OpenOffice.org (required by Base and Wizards)
** See also [[Java and OpenOffice.org]] for more information

* Linux/BSD issues
** [https://wiki.ubuntu.com/SCIM SCIM IME and OpenOffice.org]: Workaround for the gcc ABI incompatibility issue under Linux/BSD.
** [http://www.bluethingy.com/linux/rh8menu.html Editing GNOME2 Menus] for Linux/BSD users

* Mac issues: for Mac users, please see
** [[http://porting.openoffice.org/mac/ Mac OS X Porting project for OpenOffice.org ]] and
** [[MacOS_X|OpenOffice.org for Mac OS X Development pages]]

===OpenOffice.org Applications===

====Calc====

* [http://sc.openoffice.org/ OpenOffice.org's Spreadsheet Project]
* [http://graphics.openoffice.org/chart/chart.html OpenOffice.org Graphics Applications – Charts]
* [http://documentation.openoffice.org/HOW_TO/index.html OpenOffice.org's How-To Documents]
* [[Documentation/FAQ/Calc|Spreadsheet FAQ]]
* [http://sc.openoffice.org/addin_howto.html How to add-in in OpenOffice.org Calc]
* [http://user.services.openoffice.org/en/forum/viewforum.php?f=9 OpenOffice.org Community Forum]
* [[Documentation/OOoAuthors_User_Manual/Getting_Started/Getting_Started_with_Calc|Getting Started with Calc]]
* [http://www.richhillsoftware.com/ OpenOffice Calc Tips]
* 
* [http://spreadsheets.about.com/od/openofficecalc/ OpenOffice Calc Tutorials and Tips]
* [http://www.erack.de/bookmarks/D.html#SpreadSheet Links: Develop (targets SpreadSheet section)]
* [http://www.phptr.com/articles/article.asp?p=430837 Make Calc Spreadsheets Dance for You in OpenOffice.org]

====Writer====

* [http://sw.openoffice.org/ OpenOffice.org's Word Processing Project]
* [http://graphics.openoffice.org/chart/chart.html OpenOffice.org Graphics applications – Charts]
* [http://documentation.openoffice.org/HOW_TO/index.html OpenOffice.org's How-To Documents]
* [[Documentation/FAQ/Writer|Word Processor FAQ Index Page]]
* [http://user.services.openoffice.org/en/forum/viewforum.php?f=7 OpenOffice.org Community Forum]
* [http://prdownloads.sourceforge.net/ooodocs/writer_guide_en_1.0.1.zip?download OpenOffice.org Writer Guide] - for OOo 1.0.1
* [http://www.taming-openoffice-org.com/writer/index.htm Taming OpenOffice.org on Writer]
* [http://www.onlineconnections.com.au/public/openoffice/brochureprinting.html Producing a Brochure or Booklet by Kelvin]
* [http://lingucomponent.openoffice.org/download_dictionary.html Spelling, Hyphenation, and Thesaurus Dictionaries: Download / Installation]
* [http://ooovidtutors.sf.net/ Ooovidtutors - OpenOffice.org video tutorials by mimooh]
* [http://www.8daysaweek.co.uk/forums/viewtopic.php?t=34 Page Numbering in OpenOffice.org (a tutorial)]
* [[Documentation/OOoAuthors_User_Manual/Getting_Started/Getting_Started_with_Writer|GettingStarted with Writer]]
* [[Documentation/OOoAuthors_User_Manual/Writer_Guide|OpenOffice.org 2.0 Writer Guide]]

====Draw====

* [http://graphics.openoffice.org/ OpenOffice.org Graphics Applications Project]
* [http://documentation.openoffice.org/HOW_TO/index.html OpenOffice.org's How-To Documents]
* [http://documentation.openoffice.org/faqs/drawing_graphics/index.html Drawing FAQ Index Page]
* [http://user.services.openoffice.org/en/forum/viewforum.php?f=11 OpenOffice.org Community Forum]
* ''OOoAuthors:''
** [http://documentation.openoffice.org/manuals/oooauthors2/0108GS-GettingStartedWithDraw.pdf Getting Started with Draw] (free PDF)
** [http://documentation.openoffice.org/manuals/oooauthors2/index.html OpenOffice.org 2.0 Draw Guide] (free PDF)
** [http://www.lulu.com/content/285709 Buy a printed copy of the Draw Guide]
* Two-page PDF sample reference card for
** [http://www.cluesheets.com/SO8DrawCS.pdf StarOffice Draw 8.0]
** [http://www.cuesheets.com/OO2DrawCS.pdf OpenOffice.org Draw 2.0]

====Impress====

* [http://graphics.openoffice.org/ OpenOffice.org Graphics Applications Project]
* [http://documentation.openoffice.org/faqs/presentation/index.html Presentation FAQ Index Page]
* [http://user.services.openoffice.org/en/forum/viewforum.php?f=10 OpenOffice.org Community Forum]
* TUX Magazine: [http://www.tuxmagazine.com/node/1000179 Creating a Slide Show from OOo's Built-in Templates]
* James Abela ELT [http://www.jamesabela.co.uk/bus/Impress.html Impress Training]

* ''OOoAuthors:''
** [http://documentation.openoffice.org/manuals/oooauthors2/0109GS-GettingStartedWithImpress.pdf Getting Started with Impress] (free PDF)
** [http://documentation.openoffice.org/manuals/oooauthors2/index.html OpenOffice.org 2.x Impress Guide] (free PDF)
** [http://www.lulu.com/content/881167 Buy a printed copy of the Impress Guide]

====Math / Formula Editor====

* [http://sw.openoffice.org/ OpenOffice.org's Word Processing Project]
* [http://documentation.openoffice.org/HOW_TO/index.html Formula Command Reference and How-to]
* [http://documentation.openoffice.org/faqs/formula/index.html Math FAQ Index Page]
* [http://user.services.openoffice.org/en/forum/viewforum.php?f=12 OpenOffice.org Community Forum]
''OOoAuthors''
* [http://documentation.openoffice.org/manuals/oooauthors2/0111GS-GettingStartedWithMath.pdf Getting Started with Math] (free PDF)
* [http://documentation.openoffice.org/manuals/oooauthors2/0216WG-MathObjects.pdf Math Objects: The Equation Editor] (free PDF)
*: same as "Getting Started with Math" but also includes reference tables.

''Third-party add-ons for OpenOffice.org Math''
*[http://www.dmaths.org/modules.php?name=Content&pa=showpage&pid=9 Dmaths] (with [http://www.dmaths.com/dmaths/userguide/user_guide_en.html user guide]) - a Math enhancement package for OpenOffice.org licensed under GPL
*[http://ooolatex.sourceforge.net/ OOoLateX] - a set of OpenOffice.org macros designed to integrate LaTeX equations
** Check out the [http://www.oooforum.org/forum/viewtopic.phtml?t=36 LaTeX or OpenOffice.org Math] discussion at OOoForum for more detail.

====HTML====

* [http://sw.openoffice.org/ OpenOffice.org's Word Processing Project]

====Base and Database ====

* [http://en.wikipedia.org/wiki/OpenOffice.org_Base OpenOffice.org Base information and links at Wikipedia]
* [http://dba.openoffice.org/ OpenOffice.org's Database Access Project]
** [http://dba.openoffice.org/howto/index.html OpenOffice.org Database How-Tos]
** [http://dba.openoffice.org/FAQ/index.html OpenOffice.org Database Tips 'n' Tricks]
** [http://documentation.openoffice.org/HOW_TO/index.html Other OpenOffice.org's How-To Documents]

* [http://documentation.openoffice.org/manuals/oooauthors2/0110GS-GettingStartedWithBase.pdf Getting Started with Base]
* [http://sheepdogguides.com/fdb/fdb1main.htm Tutorials on using ooBase] from Sheepdog Guides ''(updated)''
* [http://user.services.openoffice.org/en/forum/viewforum.php?f=13 OpenOffice.org Community Forum]

* Macro and Base: [http://www.pitonyak.org/database/ Andrew Pitonyak's OOo Base macro document]
* ODBC and MySQL: [http://www.unixodbc.org/doc/OOoMySQL.pdf OpenOffice.org 1.0, ODBC, and MySQL 'How-tos' by John McCreesh]

* [http://homepage.ntlworld.com/garryknight/linux/oodbase.html Creating Flatfile Databases with OOo and SO 6 by Garry Knight]
* [http://ericzander.com/Publications/OO_MySQL_Tutorial/index.htm OO_MySQL_Tutorial by Eric Zander] (OOo 1.x)
* [http://kienlein.com/pages/oo.html EDV - Systeme Kienlein]
* [http://openoffice.homelinux.org/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=4&MMN_position=5:3 Documenation for Database and JRE]

===Advanced Features and Topics===

====Macros====

* [http://documentation.openoffice.org/HOW_TO/index.html OpenOffice.org's How-To Documents]
* [http://scripting.openoffice.org/ OpenOffice.org's Scripting Home Page]
* [http://www.ooomacros.org/ OOoMacros]
* [http://user.services.openoffice.org/en/forum/viewforum.php?f=20 OpenOffice.org Community Forum - Macro and API]
* [http://user.services.openoffice.org/en/forum/viewforum.php?f=21 OpenOffice.org Community Forum - Code Snippets]
* [http://www.pitonyak.org/oo.php Andrew Pitonyak's Macro Information]
* [http://www.darwinwars.com/lunatic/bugs/oo_macros.html Andrew Brown's OpenOffice.org Macro Page]
* [http://homepages.paradise.net.nz/hillview/OOo/ Iannz OpenOffice.org Page]
* [http://www.oooforum.org/forum/viewtopic.phtml?t=4818 How to use OOo with Python on Windows]
* [http://ooodocs.sourceforge.net/modules.php%3fop=modload&name=Downloads&d_op=viewdownload&cid=23 Templates and Macros from OOoDocs.org]
* [http://www.linuxjournal.com/article/7802 OOo Off the Wall: Macros and Add-ons]
* [http://disemia.com/software/openoffice/ dis-Emi-A Software: OpenOffice]
* [http://home.nikocity.de/sysentw/FAQ/SO-FAQ_English_Version/so-faq_english_version.html SO-FAQ]
* [http://perso.wanadoo.fr/moutou/index.html#OOoDoclink UNO/C++ programming (SXW and HTML formats)]

====Styles====

* [http://documentation.openoffice.org/manuals/oooauthors2/0206WG-IntroductionToStyles.pdf Introduction to Styles] (chapter in ''Writer Guide'')
* [http://documentation.openoffice.org/manuals/oooauthors2/0207WG-WorkingWithStyles.pdf Working with Styles] (chapter in ''Writer Guide'')
* [http://www.openoffice.org/servlets/ReadMsg?msgId=685429&listName=users Setting Up to Write Text Vertically]

====Templates====

* [http://documentation.openoffice.org/manuals/oooauthors2/0112GS-WorkingWithTemplates.pdf Working with Templates] (chapter in ''Getting Started with OOo'')

* [http://documentation.openoffice.org/Samples_Templates/User/template/index.html User/Templates]
* [http://ooextras.sourceforge.net/ OOExtras]
* [http://ooodocs.sourceforge.net/modules.php%3fop=modload&name=Downloads&d_op=viewdownload&cid=23 Templates and Macros from OOoDocs.org]
* [http://sourceforge.net/project/showfiles.php?group_id=170021&package_id=208656 Downloadable Template Extensions from OxygenOffice Professional Project]

====XML====

* [http://xml.openoffice.org/ OpenOffice.org XML File Format]
* [http://www.w3.org/XML/ Extensible Markup Language (XML)]
* [http://blogs.sun.com/roller/page/shudson310 Scotty's Engineering Log]
* [http://www.oasis-open.org/committees/office/press.php OASIS Open Office XML Format TC]
* [http://books.evc-cit.info/ OpenOffice.org XML Essentials]
* [http://www.zvon.org/ ZVON.org - The Guide to the XML Galaxy]
* [http://www.logilab.org/projects/xmldiff/ Logilab.org - XmlDiff]

==== Format Conversion ====

* For [[Wikipedia:OpenDocument|OpenDocument]] converters, please see the [[Wikipedia:List_of_applications_supporting_OpenDocument#Programmatic_support.2C_filters.2C_converters|List of applications supporting OpenDocument]] at Wikipedia.
* [[Firefox ODFReader extension]], still under heavy development
* [http://xml.openoffice.org/filters.html File Format Filters and Transformation]
* [http://andreas.web-graphics.com/quickguide-sxw-xhtml/ Converting OpenOffice.org documents to XHTML strict with Writer2LaTeX, by Andreas Bovens]
* [http://www.indesko.com/en/downloads/ooo2dbk ooo2dbk]: Generating DocBook XML from OpenOffice.org 1.x documents
** [http://www.tldp.org/LDP/LDP-Author-Guide/html/oo2docbook.html OOo to DocBook guide] from LDP
* [http://nothickmanuals.info/doku.php?id=ooodokuwiki Publishing with OOo Writer and DokuWiki] -- internal support since 2.3
* [[Writer2Latex]] for advanced users -- internal support since 2.1

====Dictionaries====

* [[Dictionaries]] Spelling, Hyphenation, and Thesaurus Dictionaries: Download / Installation
* [http://oooconv.free.fr/wikipedia/wikipedia_en.html OOoWikipedia]: Connect OpenOffice.org to Wikipedia for dictionary and information lookup
* [http://ooodocs.sourceforge.net/dictinstall/index.html OpenOffice.org Dictionary Installer] (older tool for older versions of OOo)
* [http://ooodi.sourceforge.net/ OOodi - OpenOffice.org Dictionary Installer for Unix]
* [http://lingucomponent.openoffice.org The lingucomponent project]

====Clip Art====

* [http://documentation.openoffice.org/Samples_Templates/User/gallery/index.html Gallery]
* [http://ooextras.sourceforge.net/ OOExtras]
* [http://www.openclipart.org/ Open Clip Art Library]
* [http://srufaculty.sru.edu/david.dailey/public/public_domain.htm Images in the Public Domain]
* [http://earth.prohosting.com/anvils/aboutMe/intro.html OOo Xfig Clipart and Network Icons for OOoDraw by Edward Chan]
* [http://marketing.openoffice.org/art/ OpenOffice.org Art Project]
* [http://www.kfacts.com/oooart/ OOoArt]
* [http://ooo.nicubunu.ro/ Nicu's OpenOffice.org pages]
* [http://hooboo.free.fr/index.php La Mouette et OpenOffice.org]
* [http://ooodocs.sourceforge.net/graphics/ OpenOffice.org Marketing Materials]
* [http://sourceforge.net/project/showfiles.php?group_id=170021&package_id=208656 Downloadable Gallery Extensions from OxygenOffice Professional Project]

===Other Resources and Support Materials===

====General====

* [http://documentation.openoffice.org/ OpenOffice.org's Documentation Project]
* [http://documentation.openoffice.org/manuals/index.html OpenOffice.org User Guide]
* [http://ooodocs.sourceforge.net/ OOoDocs]
* [http://sourceforge.net/project/showfiles.php?group_id=43716 SourceForge.net: Project: OOoDocs: File List]
* [http://documentation.openoffice.org/thirdparty.html OpenOffice.org's Page of Third Party Documentation]
* [http://ooonewsletter.blogspot.com/ The OpenOffice.org Newsletter]
* [http://user.services.openoffice.org OpenOffice.org Community Forum]
* [http://www.kaaredyret.dk/openoffice.html OpenOffice.org Links by Kaaredyret.dk]
* [http://www.kargs.net/openoffice.html OpenOffice.org Resource Page by Steve Karg]
* [http://www.tutorialsforopenoffice.org/ Tutorials for OpenOffice]
* [http://www.edafe.org/openoffice/index.html edafe.org: openoffice.org (esp. pointed toward win users)]
* [http://www.erack.de/bookmarks/O.html Links: OpenSource - OpenOffice.org]
* [http://www.openoffice-support.net/ Tutorials, Manuals, HowTo's and more] - OOo 1.x
* [http://ooo.chbs.dk/links/ OpenOffice.org Links]
* [http://www.ooo-portal.de/ Das deutsche OpenOffice.org Portal]
* [http://ooo.ximian.com/hackers-guide.html Unofficial OpenOffice Hacker's Guide]
* [http://ooolib.sourceforge.net/ OpenOffice.org Utility Library]
* [http://ooqstart.sourceforge.net/ Open Office QuickStarter applet]
* [http://del.icio.us/tag/openoffice del.icio.us/tag/openoffice]
* [http://why.openoffice.org/ Why OpenOffice.org]
* [http://documentation.openoffice.org/manuals/index.html Getting Started with OpenOffice.org 2.0]

====Books====

* OpenOffice.org 2.x books
** [http://www.devguide.net/index.php?q=node/138 OpenOffice.org Calc: Functions & Formulas, First Edition]
** [http://www.amazon.com/OpenOffice-org-2-Guidebook-Solveig-Haugland/dp/0974312029 OpenOffice.org 2 Guidebook]
** [http://www.amazon.com/exec/obidos/ASIN/0672328089 Sams Teach Yourself OpenOffice.org 2, Firefox and Thunderbird for Windows All in One]
** [http://www.lulu.com/content/177729 Getting Started with OpenOffice.org 2.0]
** [http://www.lulu.com/content/690763 OpenOffice.org 2.x Writer Guide]
** [http://www.lulu.com/content/881167 OpenOffice.org 2.x Impress Guide]
** [http://www.lulu.com/content/285709 OpenOffice.org 2.0 Draw Guide]
** [http://www.lulu.com/content/301623 OpenOffice.org 2.0 Migration Guide]
** [http://www.amazon.com/exec/obidos/ASIN/1593270720 Hacking Openoffice.org: Tips, Tricks, and Untold Secrets]
** [http://www.amazon.com/exec/obidos/ASIN/0131879928 Point & Click OpenOffice.org]
** [http://visibooks.com/writer2.html Visibooks Guide to Writer 2.0]
** [http://visibooks.com/calc2.html Visibooks Guide Calc 2.0]
** [http://visibooks.com/impress2.html Visibooks Guide Impress 2.0]
** [http://visibooks.com/base2.html Visibooks Guide Base 2.0]
** [http://www.conciseconceptsinc.com/ A Conceptual Guide to OpenOffice.org 2.0]
** [http://www.cafepress.com/getopenoffice OpenOffice.org and StarOffice Workbooks]
** [http://www.cluesheets.com/ ClueSheets] - Quick Reference Cards for [[StarOffice]] and OpenOffice.org

* OpenOffice.org 1.x books
** [http://www.amazon.com/exec/obidos/ASIN/0131407457 OpenOffice.org 1.0 Resource Kit]
*** [http://www.informit.com/content/downloads/OpenOfficeUpdate.pdf Special Supplement to Changes in OpenOffice.org 1.1] (free PDF download)
** [http://www.amazon.com/exec/obidos/ASIN/0764542222 OpenOffice.org For Dummies]
** [http://www.oreilly.com/catalog/openoffice/ OpenOffice.org Writer: The Free Alternative to Microsoft Word]
** [http://www.hentzenwerke.com/catalog/ooo501.htm OOoSwitch: 501 Things You Wanted to Know About Switching to OpenOffice.org]
** [http://www.samspublishing.com/title/0672326183 Sams Teach Yourself OpenOffice.org All in One]
** [http://www.hentzenwerke.com/catalog/tinyooo.htm The Tiny Guide to OpenOffice.org]
** [http://www.hod-ami.co.il/product.asp?catalog%5Fname=hodami&category%5Fname=Home+and+Office&product%5Fid=59407 עיבוד תמלילים עם OpenOffice 1.x] ([http://www.hod-ami.co.il/images/bookdemo/59407.pdf Sample Chapter])

* [[StarOffice]] books, mostly suitable to OpenOffice.org users
** [http://www.amazon.com/exec/obidos/tg/detail/-/0789728338/ref=pd_sim_books_5/104-9698914-9518356%3fv=glance&s=books Special Edition Using StarOffice 6.0]
** [http://www.amazon.com/exec/obidos/tg/detail/-/0130384739/qid=1038357106/sr=8-4/ref=sr_8_4/103-6157785-3887854%3fv=glance&s=books&n=507846 StarOffice 6.0 Office Suite Companion]

* Linux and OpenOffice.org related books
** [http://www.amazon.com/exec/obidos/ASIN/1886411867 Linux in the Workplace]
** [http://www.amazon.com/gp/product/0131488724 Point & Click Linux]

* XML, OpenOffice.org Macros and Programming
** [http://www.hentzenwerke.com/catalog/oome.htm OpenOffice.org Macros Explained]
** [http://books.evc-cit.info/ OASIS OpenDocument Essentials]

====E Learning====

* [http://training.bytebot.net/ ByteBot.net Training Materials]
* [http://www.desktoplinux.com/news/NS2978835938.html Free online OpenOffice.org support program]
* [http://www.itrainonline.org/itrainonline/mmtk/opensource.shtml ItrainOnline: Resources for Trainers: MMTK: Open Source Software]

====Compatible Applications====

* [http://www.zope.org/Products/CMF/ Content Management Framework (CMF)]
* [http://peccatte.karefil.com/software/Catalogue/CatalogueENG.htm Files Metadata Miner Software]
* [http://gramps.sourceforge.net/ Gramps]
* [http://www.icoya.com/ icoya]
* [http://www.mozilla.org/ Mozilla]
* [http://www.planamesa.com/neojava/en/index.php NeoOffice/J]
* [http://www.opengroupware.org/ OpenGroupware.org]
* [http://plone.org/ Plone]
* [http://www.bezirksreiter.de/PyOpenOffice.htm PyOpenOffice]
* [http://www.scholarsaid.com/ Scholar's Aid]
* [http://www.hj-gym.dk/~hj/writer2latex/ Writer2LaTeX]
* [http://www.logilab.org/projects/xmldiff/ XmlDiff]
* [http://zope.org/ Zope]
* [http://ooop.sf.net/ OxygenOffice Professional]

==Web Site==

===Search===

* [http://www.openoffice.org/ Search Bar in Upper Right Corner]
* [http://support.openoffice.org/search.html OOo Site Search using Google]
* [http://www.openoffice.org/project/www/issues/query.cgi Issue Tracker Query Page]
* [http://darwinwars.com/lunatic/bugs/quickbugs.html Simplified Bug Finder by Andrew Brown]
* [http://www.openoffice.org/mail_list.html Mail List Archives]
* [http://www.openoffice.org/servlets/SearchList?listName=users Search the Users List Archive]
* [http://search.gmane.org/ Gmane Newsgroup Search Page]

===Documentation===

* [http://www.openoffice.org/nonav/servlets/HelpTOC OpenOffice.org's Web Site Help TOC]
* [http://documentation.openoffice.org/ OpenOffice.org's Documentation Project]
* [http://lingucomponent.openoffice.org/download_dictionary.html Spelling, Hyphenation, and Thesaurus Dictionaries: Download / Installation]
* [http://www.openoffice.org/mail_list.html OpenOffice.org's Mail Lists]
* [http://www.openoffice.org/servlets/SummarizeList?listName=users Browse the Users List]
* [http://www.openoffice.org/servlets/SearchList?listName=users Search the Users List Archives]
* [http://development.openoffice.org/index.html OpenOffice.org for Developers]
* [http://api.openoffice.org/docs/DevelopersGuide/DevelopersGuide.htm Developer's Guide]
* [http://udk.openoffice.org/python/python-bridge.html Python-UNO bridge]

===Issue Tracker===

* [http://qa.openoffice.org/issue_handling/project_issues.html OpenOffice.org's Bugs and Issues Info]
* [http://qa.openoffice.org/index.html OpenOffice.org's QA Project]
* [http://www.kegel.com/openoffice/triage.html OpenOffice.org Issues by Dan Kegel]
* [http://www.openoffice.org/project/www/issues/query.cgi Query Page for Existing Issue Reports]
* [http://darwinwars.com/lunatic/bugs/quickbugs.html Simplified Bug Finder by Andrew Brown]
* [http://www.openoffice.org/servlets/SearchList?listName=users Search the Users List Archives]

===Community===

* [http://www.openoffice.org/ OpenOffice.org's Home Page]
* [http://marketing.openoffice.org/index.html OpenOffice.org Marketing Project]
* [http://user.services.openoffice.org OpenOffice.org Community Forum]
* [http://www.openoffice.org/copyright/copyrightapproved.html A list of folks who have filed OOo copyright assignments]
* [http://www.openoffice.org/welcome/credits.html A list fo folks who have contributed to OOo]
* [http://www.openoffice.org/mail_list.html OpenOffice.org's Mail Lists: Browse, Search or Subscribe]
* [http://www.openoffice.org/project/www/issues/query.cgi Issue Tracker Query Page]
* IRC chat channel at irc.freenode.net#openoffice.org

===Projects===

* [http://projects.openoffice.org/index.html Project Descriptions, Leaders, and Links to Project Pages]

===Native Languages===

* [http://lingucomponent.openoffice.org/download_dictionary.html Spelling, Hyphenation, and Thesaurus Dictionaries: Download / Installation]
* [http://ooodocs.sourceforge.net/dictinstall/index.html OpenOffice.org Dictionary Installer] (older tool for older versions of OOo)
* [http://l10n.openoffice.org/all_supported_languages.html l10n - All Supported Languages]
* [http://l10n.openoffice.org/languages.html Localization Contact Table]
* [http://native-lang.openoffice.org/ Native Language Confederation]

=== Third Party Sites ===

* [http://oooauthors.org/ OOoAuthors] for community contributions   on [http://oooauthors.org/en/authors/userguide2/ User Guide] and [http://oooauthors.org/en/FAQs/faqfolder_view FAQ] authoring
* [http://www.digitaldistribution.com/about/lessons/ OpenOffice.org 2.0 lessons in Flash format]
* [http://business.newsforge.com/article.pl?sid=05/11/09/2044220 OpenOffice.org training videos in Flash]
* [http://plan-b-for-openoffice.org Plan-B for OpenOffice.org - Support for non technical users]
* [http://inpics.net/ In Pictures: Online computer tutorials based on pictures]
** [http://inpics.net/writer2.html Writer 2.0 In Pictures]
** [http://inpics.net/calc2.html Calc 2.0 In Pictures]
** [http://inpics.net/impress2.html Impress 2.0 In Pictures]
** [http://inpics.net/base2.html Base 2.0 In Pictures]
* [http://user.services.openoffice.org OpenOffice.org Community Forum]
* [http://ooonewsletter.blogspot.com/ OpenOffice.org Newsletter]
* [http://ooextras.sourceforge.net/ OOExtras: Extras for OpenOffice.org]
* [http://www.taming-openoffice-org.com/ Taming OpenOffice.org]
* [http://openoffice.blogs.com/ OpenOffice.org Tips, Tricks and Ideas]
* [http://mindmeld.cybersite.com.au/ OpenOffice.org Knowledgebase]
* [http://www.whatisopenoffice.org/ What is OpenOffice.org?]
* [http://oooconv.free.fr/wikipedia/wikipedia_en.html OOoWikipedia-Plugin]
* [http://www.gnome.org/projects/ooo/ GNOME/OpenOffice.org]
* [http://kde.openoffice.org/ KDE Integration Project]
* [http://www.opencards.info OpenCards] - A free flashcard learning extension for OpenOffice Impress
* [http://www.OOoNinja.com OpenOffice.org Ninja: Upcoming features, tips, tutorials, news]

===Developer support===

* [http://development.openoffice.org/ OpenOffice.org for Developers]
* [http://planet.go-oo.org/ Planet OpenOffice.org - Developer News]
* [http://perso.wanadoo.fr/moutou/index.html#OOoDoclink UNO automation (in C++)]

[[Category:Build_System]]

Stub build faq

2008-12-29T02:50:31Z

DavidRoss: added Category:Build_System

This page is a stub for the Build FAQ

[http://www.openoffice.org/FAQs/build_faq.html Build FAQ]

http://www.openoffice.org/FAQs/build_faq.html

[[Category:Build_System]]

Stub build faq

2008-12-29T02:49:38Z

DavidRoss: added stub page for build faq

This page is a stub for the Build FAQ
[http://www.openoffice.org/FAQs/build_faq.html Build FAQ]