Guide du Hacker OpenOffice.org Non Officiel

• Comment je compile OOo ?
• Comment je viens à bout d'itération de développement
• Comment je le débuggue
• Comment j'envois un patch

O. Contenu

• 1. Obtenir OOo
• 2. Compiler OOo
• 3. Installer OOo
• 4. Exécuter OOo
• 5. Hacker OOo
• 6. Débuguer OOo
• 7. Contribuer des patches
• 8. Astuces générales
• 9. Liens utiles
• 10. IFAQ
• 11. Travailler avec nous

1. Obtenir OOo

export CVSROOT=':pserver:anonymous@anoncvs.gnome.org:/cvs/gnome'
    cvs login
    cvs -z3 checkout -P ooo-build

2. Compiler OOo

./autogen.sh # the CVS version
      ./configure  # the packaged version

--with-tag=OOO_1_1_0

./download

make

make 2>&1 | tee /tmp/log

3. Installer OOo

build/$TAG/instsetoo/unxlngi4.pro/01/normal/

/opt/OOInstall

~/.sversionrc

bin/linkoo /opt/OOInstall /opt/ooo-build/build/OOO_1_1_2

4. Exécuter OOo

/opt/OOInstall/program

source ./env

soffice.bin

gdb soffice.bin

./soffice.bin

oowriter

5. Hacker OOo

cd build/$TAG
      . ./LinuxIntelEnv.Set.sh
      cd vcl

nPos = 0

soffice -writer

ooo-build/

build/OOO_1_1_2

cvs status <somefile> | head

cd /opt/OOInstall/program
mkdir backup
mv libsal.so.3.0.1 backup
ln -s /opt/OpenOffice/OOO_STABLE_1/sal/unxlngi4.pro/lib/libsal.so.3.0.1 .

• build : ce script perl solenv/bin/build.pl est utilisé en conjonction avec prj/build.lst pour s'assurer que chaque module qui est nécessaire est compilé en premier. La compilation détourne les dépendances interne des modules et compile chaque module avec une paire chdir, dmake.
• deliver : ce script perl solenv/bin/deliver.pl installe les entêtes, et les librairies (etc.) dans le solver comme l'en informe prj/d.lst. De façon crucial, cela permet de s'assurer que la date de chacun des fichiers qui sont installés dans le solver est la même que celle dans le répertoire du module. Cela permet de s'assurer qu'il n'y a pas, (particulièrement pour les entêtes) de dépendances en cascade déclenchant des recompilations dans les autres modules.

• prj
  
• build.lst : cela liste les répertoires qui doivent être faites,  les commentaires '^#'sont permis, l'ordre de cette liste est sans importance voir les détails, il est dicté par les opérations de 'builds'
  
• d.lst : ce fichier décrit le processus deliver, voir les détails
• util : typiquement, le répertoire util est chargé en agrégeant ensemble les sous-répertoires pour chaque sous-module dans une seule grande librairie, ajoutant des dépendances de librairies system, compilant les fichiers ressours pour le GUI, etc. Tout le travail est décrit dans makefile.mk, c'est en général le dernier répertoire construit dans un projet.
• inc :  les entêtes publiques sont typiquement séparées dans un répertoire 'inc', cela les installera dans le solver par la phase 'deliver' (en utilisant prj/d.lst)

• makefile.rc : ils sont tous plus ou moins redondants et peuvent ignorés sans problème
• makefile.mk : ceux-la au contraire sont le fichiers 'dmake' qui sont utilisés pour compiler chaque répertoire source.

vc      vcl : nas 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

• La première ligne active contient un ':', cela décrit le fait que ce projet (vcl) dépend des autres modules 'nas', 'freetype', 'psprint' etc. qui doivent être construits en premier. C'est pour les dépendances inter-projet.
• Nous avons ensuite une ligne redondante 'usr1' [pour le fun ?], en fait seulement les lignes contenant le string magique 'nmake' sont valides après cela.
• Les lignes suivantes décrivent des dépendances internes des répertoires du projet et ressemblent à :
  

  [shortcut] [path to dir to build] nmake - [flags] [unique-name] [deps...] NULL
  vc           vcl\source\glyphs    nmake -   all     vc_glyphs   vc_unot   NULL
  

  
  shortcut n'est pas utilisé ; flags détermine sur quelle plateforme porte la compilation, en général un simple code de caractère de plateforme : 'dnpum' 'u' étant Unix. Le plus haut on est dans le système, le plus on trouvera de matériel avec le drapeau 'all'.
  unique-name c'est un nom magique, utilisé par les autres lignes pour décrire une dépendance interne. deps... n'importe quel nombre de noms des autres répertoires dans ce fichier qui doit être compilé avant celui-là.

[action]: [arguments]
mkdir:    %_DEST%\inc%_EXT%\external

• %__SRC% — nom du répertoire de la distribution ex. unxlngi4.pro
• %_DEST% — chemin absolue du solver ex. /opt/OpenOffice/OOO_STABLE_1/solver/641/unxlngi4.pro
• %_EXT% — chemin (inusuel) pour avoir un update mineur ex. 641.1, typically used to version every base sub-directory.

..\%__SRC%\inc\sal\*.h %_DEST%\inc%_EXT%\sal\*.h

vcl

build

• rtl_String : sal/inc/rtl/string.h
  string 'Normal' plus une référence de comptage rtlstring->buffer  est utile, comme l'est rtlstring->length  . Ce string a déjà été converti dans un set de caractère particulier, voir sal/inc/rtl/textenc.h : les seuls cas intéressants sont RTL_TEXTENCODING_UTF8  et peut-être RTL_TEXTENCODING_ASCII_US pour de vrai ( ?). N'hésitez pas à traiter  rtlstring->buffer comme votre char * préféré.
• OString : sal/inc/rtl/string.hxx
  Un simple rtl_String sal/inc/rtl/string.hxx enveloppé dans une classe, vous pouvez utiliser ostring.pData pour avoir un rtl_String  (c'est public) . OString a des méthodes raisonnablement utiles si vous en avez besoin.
• rtl_uString : sal/inc/rtl/ustring.h
  string 'Normal' Unicode similaire à rtl_String  et référence de comptage aussi bien. Cependant celui-ci vient toujours avec un encodage UCS-2, sans doute pour être compatible avec des choix Java douteux.
• OUString : sal/inc/rtl/ustring.hxx
  un rtl_uString enveloppé dans une classe. C'est ce qu'utilise la plupart du code OOo pour passer les strings
• String  : tools/inc/string.hxx
  C'est une classe de string obsolète, aliasée à 'UniString'. Elle a un certain nombre de limitations comme An rtl_uString  enveloppé à l'intérieur d'une classe. C'est ce qu'utilise la plupart du code OOo pour passer les strings

static char *
gimme_utf8_please (const rtl::OUString &oustring)
{
  rtl::OString ostring;

  ostring = ::rtl::OUStringToOString (oustring, RTL_TEXTENCODING_UTF8);
        return strdup (ostring.pData->buffer);
}

static rtl::OUString
complicate_things_into_ucs2_please (const char *utf8_string)
{
  rtl::OString ostring;

        ostring = rtl::OString (utf8_string);
  return rtl::OStringToOUString (ostring, RTL_TEXTENCODING_UTF8);
}

• à partir de la branche cvs cws_srx645_ooo112fix1 vous pouvez utiliser
  

  (gdb) print dbg_dump(sWhatEver)

  pour imprimer le contenu de UniString/ByteStrin/rtl::OUString/rtl::Ostring quel que soit le type lorsque vous débugguez du code C++ vois l'issue 17295 pour les détails.

• rtl_String : met le doigt dessus
• String : note : la décl' de cela utilise la macro 'UniString' pour embrouiller les lecteurs. Heureusement, par programmation, nous pouvons passer un String à un OUString de façon transparente.
• OString : p str->pData
OUString, rtl_uString (un super truc de Kevin Hendricks) la façon la plus rapide et la plus simple de débarasser d'un string est de faire :


p *theString; # grab the length (2nd field)
x/<length>s theString->buffer

ex pour un string de 20 caractères, nous voulons


x/20s theString->buffer

cela devrait imprimer le string comme une collection restreinte avec la valeur ASCII des caractères gentiment disposée dans une colonne. Pour imprimer, de façon programmée un OUString (ou String) vous avez besoin

::rtl::OString tmpStr = OUStringToOString (MyOUString, RTL_TEXTENCODING_UTF8);
fprintf (stderr, "String is '%s'\n", tmpStr.getStr());

• Un comportement bizarre des liens - ie si vous liez symboliquement une librairie, il suit le lien à l'exécution et finit dans la confusion
• soffice.bin - cela doit être copié depuis desktop/unxlngi4.pro/bin/soffice à chaque fois que vous entrez dans un cycle de développement, autrement le débuggage est confus,
• libcgmgr2.so - cela doit être copié depuis configmgr/unxlgni4.pro/lib à chaque fois, sinon la configuration ne peut être chargée,
• contruction bizarre d'une librairie interne
• les fichiers de filtre ont une détection de code, ex sc/source/ui/app/sclib.cxx(ScDLL::DetectFilter) qui est compilé dans une librairie statique, installée puis lié dans libwrp dans desktop/source/offwrp. Pour recompiler dans 'sc' exécutez :
  

  build && deliver

  puis dans desktop/source/offwrp exécutez
  

  touch wrapper.cxx && dmake

  
  

6. Débugguer OOo

--- solenv/inc/unxlngi4.mk
+++ solenv/inc/unxlngi4.mk
@@ -92,18 +92,18 @@ cc=gcc
 # do not use standard header search paths
 # if installed elsewhere
 .IF "$(BUILD_SOSL)"!=""
-CFLAGS=
+CFLAGS=-g
 .ENDIF
 CFLAGS+=-fmessage-length=0 -c $(INCLUDE)
 # flags for the C++ Compiler
-CFLAGSCC= -pipe -mcpu=pentiumpro
+CFLAGSCC= -g -pipe -mcpu=pentiumpro
 # Flags for enabling exception handling
 CFLAGSEXCEPTIONS=-fexceptions -fno-enforce-eh-specs
 # Flags for disabling exception handling
 CFLAGS_NO_EXCEPTIONS=-fno-exceptions
 
 # -fpermissive should be removed as soon as possible
-CFLAGSCXX= -pipe -mcpu=pentiumpro -fno-for-scope -fpermissive -fno-rtti 
+CFLAGSCXX= -g -pipe -mcpu=pentiumpro -fno-for-scope -fpermissive -fno-rtti 
 
 # HACK: enable Hamburg developers to build on glibc-2.2 machines but compile vs. glibc-2.1 headers
 .IF "$(BUILD_SOSL)"==""

patch -p0 < /tmp/foo

gdb ./soffice
break main
run # don't forget the arguments here
# ... traps in main ...
break osl_readFile
continue

p pImplSVData->maAppData

xh      neon  :  soltools external expat NULL

--- 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;

IMPL_LINK( Window, ImplHandlePaintHdl, void*, EMPTYARG )

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 const*) () from ./libsfx641li.so
...
    quit
    cd base/OOO_STABLE_1/sfx2
    ootouch SfxMedium
    build debug=true

  dmake killobj
      dmake

export SAL_SYNCHRONIZE=1

TMPFILE=~/.Env.Set.debug

# Purge .pro bits
sed 's/\.pro//g' LinuxIntelEnv.Set.sh > $TMPFILE
. $TMPFILE
rm $TMPFILE

# Clobber product parts
unset PRODUCT PROSWITCH PROFULLSWITCH 

source ./LinuxIntelEnv.Set.debug

export DBGSV_INIT=$(HOME)/.dbgsv.init

7. Contribuer des patches

8 Conseils divers

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

:pserver:mmeeks@localhost:/cvs

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

• Si vous n'êtes pas sûr du tout, exécutez les patchs avec --dry-run d'abord, cela donnera l'apparence de faire l'action de patcher, mais en fait ne le fera pas [ cela peut donner de faux résultats avec des inter-dépendances compliquées de patches, mais c'est très utile]
• Utilisez plus particulièrement le patch -p0, 0 signifie le nombre d'éléments de patchs à dépouiller depuis de début de chemin de fichier que le diff pointe.
• Quand cela plante et que vous n'avez que la moitié du patch qui s'applique et que vous souhaitez revenir à un truc propre, à la fois supprimez les fichiers et faites un cvs update, ou repatchez avec l'option '-R' pour annuler l'effet.
• Parfois, utiliser diff entre les modules avec beaucoup de modification des espaces rend le patch plus difficile à lire, le flag '-w' de (cvs) diff rend les choses plus faciles.

find -name 'unxlngi4.pro' -exec rm -Rf {} \;

cvs -z3 -q
diff -upN 
update -dP
checkout -P
status -v 

9. Liens utiles

• Ximian OOo patches et outils de compilation /snpashots sont tous disponibles sous forme de packages ou de patches.
• Les pages d'aide Debian, avec des patches. Et aussi le CVS Debian.
• archive patch de Mandrake OOo
• patches de portage OOo FreeBSD
• les fichiers specs Red Hat (basés sur ceux de Mandrake) sont aussi intéressants à lire à partir de leur SRPM.
• les personnes qui veulent localiser OOo devraient étudier les patches de Pavel Janik

10 FAQ (non fréquentes)

echo 'echo #define DLL_NAME "libsch641li.so" >./foo.hxx' | /bin/tcsh -s

tcsh -fc 'echo #define DLL_NAME "libsch641li.so" >./foo.hxx'

bin/relocate /path/to/new/build

find -name '*.dpc*' -exec rm {} \;

import foo.png

#define _STLP_NATIVE_INCLUDE_PATH \
        /home/michael/ximian-desktop/ooo/BUILD/ooo/include/c++/3.2.2

# define _STLP_MAKE_HEADER(path, header) <path/header>
# define _STLP_NATIVE_CPP_C_HEADER(header)  \
        _STLP_MAKE_HEADER(_STLP_NATIVE_INCLUDE_PATH,header)

#include _STLP_NATIVE_CPP_C_HEADER(foo)

Net result:

      g++ ... -DBUILD=7663 ...
      ...
from /home/michael/ximian-desktop/ooo/BUILD/ooo/OOO_1_0_2/xml2cmp/source/xcd/main.cxx:62:
/home/michael/ximian-desktop/ooo/BUILD/ooo/OOO_1_0_2/solver/641/unxlngi4.pro/inc/stl/cstddef:35:46:
/home/michael/ximian-desktop/ooo/7663/ooo/include/c++/3.2.2/cstddef: No such file or directory

11. Travailler avec nous

OpenOffice.org native tongue concept and francophone project are built for you with pride by Guy Capra (Alomphega).
This fr project is also led and maintained by Sophie Gautier.