<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title>Labo</title>
  <meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<table border="0" cellpadding="4" width="100%">
  <tbody>
    <tr>
      <td align="left" valign="top" width="100%"><!-- Content -->
      <h3><font face="Helvetica, Arial, sans-serif"><b><br>
Guide du Hacker OpenOffice.org Non Officiel</b></font></h3>
Compiler et hacker OpenOffice.org (OOo) vous fera gravir une pente
assez longue. Heureusement, ce document rendra la courbe
d'apprentissage un peu plus raide et abrupte et vous fournira un bâton
de marche pour vous aider.<br>
Ce document assume que vous utilisez un système Linux habituel pour une
économie de temps. Les vrais hackers utilisent des <a
 href="http://www.gnu.org/">logiciels Libres</a> et n'ont pas le temps
de s'intéresser à du matériel non Libre.<br>
Nous avons pour but de répondre au moins aux questions suivantes :<br>
      <ul>
        <li>Comment je compile OOo ?</li>
        <li>Comment je viens à bout d'itération de développement</li>
        <li>Comment je le débuggue</li>
        <li>Comment j'envois un patch</li>
      </ul>
Si vous avez besoin d'aide pour la compilation de OOo et que vous avez
l'intention de le hacker, merci rejoindre la liste <a
 href="mailto:labo@fr.openoffice.org">ici</a> et d'y poser vos
questions.<br>
      <h3>O. Contenu</h3>
      <ul>
        <li><a href="#1._Obtenir_OOo">1. Obtenir OOo</a></li>
        <li><a href="#2._Compiler_OOo">2. Compiler OOo</a></li>
        <li><a href="#3._Installer_OOo">3. Installer OOo</a></li>
        <li><a href="#4._Ex%C3%A9cuter_OOo">4. Exécuter OOo</a></li>
        <li><a href="#5._Hacker_OOo">5. Hacker OOo</a></li>
        <li><a href="#6._D%C3%A9bugguer_OOo">6. Débuguer OOo</a></li>
        <li><a href="#7._Contribuer_des_patches">7. Contribuer des
patches</a></li>
        <li><a href="#8_Conseils_divers">8. Astuces générales</a></li>
        <li><a href="#9._Liens_utiles">9. Liens utiles</a></li>
        <li><a href="#10_FAQ_non_fr%C3%A9quentes">10. IFAQ</a></li>
        <li>11. Travailler avec nous</li>
      </ul>
Ce processus est discuté en bien plus amples détails dans le <a
 href="http://ooo.ximian.com/detailed-build-guide.html">guide détaillé
de compilation</a>. Nous avons cependant travaillé dur pour rendre ce
process réalisable pour les simples programmeurs mortels, et une simple
description de ce qui suit.<br>
      <h3><a name="1._Obtenir_OOo"></a>1. Obtenir OOo</h3>
      <span style="font-family: helvetica,arial,sans-serif;"></span><span
 style="font-weight: bold; font-family: helvetica,arial,sans-serif; color: rgb(255, 255, 255);"></span><!-- /Table Navigation Bar -->Il
y a un tas de versions compétitives d'OOo et plusieurs choix de
branches, ainsi que de multiples sets de patches. Je vous recommande de
compiler à partir de snapshots CVS, qui sont connues pour compiler et
dont les sets de patchs sont connus pour s'appliquer. Ainsi pour avoir
les sources faites :<br>
      <pre>export CVSROOT=':pserver:anonymous@anoncvs.gnome.org:/cvs/gnome'<br>    cvs login<br>    cvs -z3 checkout -P ooo-build</pre>
Cela vous fournira un copie de la branche ooo-build. Si CVS vous fait
peur, vous devriez obtenir une version récente packagée à partir <a
 href="http://ooo.ximian.com/packages">d'ici</a>. <br>
      <span style="font-weight: bold;">Note</span> : Vous allez devoir
télécharger environ 200 Mo de sources compressées et avoir ~5Go
d'espace pour la dépackager et la compiler.<br>
      <h3><a name="2._Compiler_OOo"></a>2. Compiler OOo</h3>
      <span style="font-weight: bold;">2.1 configure</span><br>
Le processus de compilation est plutôt compliqué, vous avez maintenant
le choix des commandes suivantes et même en les exécutant toutes les
deux, cela ne
posera pas de problèmes.<br>
      <pre>./autogen.sh # the CVS version<br>      ./configure  # the packaged version</pre>
      <br>
Ceci va déterminer quelle branche de snapshot vous voulez compiler ; si
vous avez une autre idée, utilisez l'option --with-tag, par exemple :<br>
      <pre>--with-tag=OOO_1_1_0</pre>
pour une branche en cours.<br>
      <br>
      <span style="font-weight: bold;">2.2 téléchargement</span><br>
Avec un certain temps, vous avez mis à jour votre système à un point où
il a
tous les packages dont vous avez besoin pour commencer la compilation
de OOo (mozilla, libart récent etc. etc.) vous en être rendu au point
où vous pouvez télécharger les sources. Pour faire cela, après un
configure réussit, tapez simplement :<br>
      <pre>./download</pre>
et attendez.<br>
      <span style="font-weight: bold;">make </span><br>
C'est le bit taxant - tapez<br>
      <pre>make</pre>
et n'oubliez pas de presser entré. Il est fort possible que vous
souhaitiez une sortie des logs, alors pourquoi pas<br>
      <pre>make 2&gt;&amp;1 | tee /tmp/log</pre>
      <h3><a name="3._Installer_OOo"></a>3. Installer OOo</h3>
Le résultat d'une compilation parfaite est un set d'installation zippé
situé dans <br>
      <pre>build/$TAG/instsetoo/unxlngi4.pro/01/normal/</pre>
ou similiaire. Puis exécutez le programme setup à partir de là pour
l'installation, exemple :<br>
      <pre>/opt/OOInstall</pre>
pour installer. Il est possible que pour faire cela, vous deviez
d'abord effacer votre&nbsp; fichier<br>
      <pre>~/.sversionrc</pre>
L'ayant installée, vous avez envie de la hacker en liant votre tronc
compilée directement à l'image installée, ainsi en recompilant un sous
répertoire source, vous pouvez simplement réexécuter OOo. Cela peut
rendre votre version/cycle de test&nbsp; indisponible pendant plusieurs
dizaine de minutes. Pour faire cela faites :<br>
      <pre>bin/linkoo /opt/OOInstall /opt/ooo-build/build/OOO_1_1_2</pre>
NB : voir aussi les <a href="#linkoo">limitations linkoo</a><br>
      <h3><a name="4._Exécuter_OOo"></a>4. Exécuter OOo</h3>
Maintenant positionnez-vous dans :<br>
      <pre>/opt/OOInstall/program</pre>
et faites<br>
      <pre>source ./env</pre>
cela paramétrera votre shell (bash) pour exécuter OOo directement. Puis
simplement<br>
      <pre>soffice.bin</pre>
C'est mieux que d'exécuter soffice, ou un script wrapper dans la mesure
où il est très facile d'attacher le débuggueur.<br>
      <pre>gdb soffice.bin</pre>
      <span style="font-weight: bold;">Note</span> : n'utilisez pas <br>
      <pre>./soffice.bin</pre>
pour d'obscures raisons cela ne marche pas du tout<br>
      <span style="font-weight: bold;">Note </span>: vous devez
exécuter le ooo-wrapper basé sur OOo avant cela, pour
que ~/.sversionrc soit paramètré correctement d'abord, autrement
exécuter&nbsp; soffice.bin vous enverra dans l'outil de setup du GUI.
Faites juste un <br>
      <pre>oowriter</pre>
avant de commencer<br>
      <h3><a name="5._Hacker_OOo"></a>5. Hacker OOo</h3>
      <span style="font-weight: bold;">5.0. Mon premier hack</span><br>
Bon - nous avons compilé et exécuté OOo et nous voulons nous prouver
qu'il est en fait possible de le hacker. Donc, dans un nouveau
terminal, faites ceci :<br>
      <pre>cd build/$TAG<br>      . ./LinuxIntelEnv.Set.sh<br>      cd vcl</pre>
Maintenant pour faire un hack à vcl/source/window/toolbox2.cxx, je
suggère d'ajouter (par exemple) un <br>
      <pre>nPos = 0</pre>
n'importe où avant le m_aItems.insert dans ToolBox::InsertItem( const
ResId &amp;ResId...) puis sauvegardez<br>
Vous êtes toujours dans vcl/ oui ? alors tapez 'build debu=true';
attendez que le texte défilant s'arrête; (5 secondes ?) maintenant
re-exécutez <br>
      <pre>soffice -writer</pre>
vous devriez voir ce qui arrive<br>
      <span style="font-weight: bold;">Note</span> : ceci assume que
vous avez soigneusement suivi les étapes précédentes, <span
 style="font-style: italic;">notamment</span> le linkoo dans la <a
 href="#3._Installer_OOo">section
3</a><br>
      <span style="font-weight: bold;">Note </span>: pour un hacking
quotidien vous préférerez exécuter 'build' à
l'intérieur du tronc source. N'exécutez pas 'make' au niveau
supérieur<br>
      <pre>ooo-build/</pre>
du répertoire ou vous allez (très certainement) effacer toutes les
modifications que vous avez faites et déprimer. Cela vaut le coup de
faire une copie 'out of line' de <br>
      <pre>build/OOO_1_1_2</pre>
quelque part voir<a href="#10_FAQ_non_fr%C3%A9quentes"> ici</a> pour
une aide de relocalisation de la version<br>
      <br>
      <span style="font-weight: bold;">5.1 Lire le manuel sympa</span><br>
Avec le pouvoir de C++ , vous allez pouvoir vous prendre la tête très
facilement (et implicitement) cf <em>Holub, Rules for C and C++
programming, McGraw-Hill, 95</em><br>
Le meilleur moyen de vous préparer à la bataille est de lire le guide
du codage OpenOffice.org <a
 href="http://tools.openoffice.org/CodingGuidelines.sxw">ici</a> et
pour ceux qui se perdent facilement c'tor/d'tor est le raccourci de
constructor / destructor.<br>
      <br>
      <span style="font-weight: bold;">5.2 Soumettre un patch</span><br>
Il est rarement clair de savoir dans quel module réside un patch dans
bugzilla. Un moyen rapide de s'y retrouver est de faire :<br>
      <pre>cvs status &lt;somefile&gt; | head</pre>
Cela devrait donner une ligne&nbsp; 'Repository Revision:' avec un
chemin, le second fragment est le nom du projet.<br>
      <br>
      <span style="font-weight: bold;">5.3 Hacker l'installeur</span><br>
Dans la mesure où l'image de l'installeur détruit l'image (exécutable)
temporaire de setup dans <tt>/tmp/sv001.tmp</tt>, vous devez
l'empêcher de le faire. Exécutez setup / install avec l'option
-dontdeletetemp.<br>
      <br>
      <span style="font-weight: bold;">5.4 Hacker d'autres parties</span><br>
Ayant une installation qui fonctionne, la meilleure façon de lui
ajouter
vos hacks est de mettre un lien symbolique de <tt>program/lib<em>foo</em>641li.so</tt>
à la build que vous venez juste de construire le plus sûrement vers <tt><em>foo</em>/unxlngi4.pro/lib/</tt>
, puis de redémarrer la suite et vos changements devraient être
incorporés<br>
      <br>
Par exemple, disons que vous voulez : 'sal' le System Abstraction Layer
et vous avez installé OOO_STABLE_1 dans /opt/OOInstall, vous
devez&nbsp; faire :<br>
      <pre>cd /opt/OOInstall/program<br>mkdir backup<br>mv libsal.so.3.0.1 backup<br>ln -s /opt/OpenOffice/OOO_STABLE_1/sal/unxlngi4.pro/lib/libsal.so.3.0.1 .</pre>
      <br>
      <span style="font-weight: bold;">5.5 Comprendre D'make (man)</span><br>
Alors que le système de compilation est similaire à beaucoup d'autres
systèmes, il est en même temps légèrement différent. La vue d'ensemble
est que chaque module est <span style="font-style: italic;">compilé</span>,
et qu'ensuite le résultat est <span style="font-style: italic;">délivré</span>
dans le <a href="http://www.openoffice.org/dev_docs/source/solver.html">solver</a>.
Chaque module est compilé en fonction de l'entête dans le solver.
Ainsi, il y a quelques intrications :<br>
      <ul>
        <li><i>build</i> : ce script perl <i>solenv/bin/build.pl </i>est
utilisé en conjonction avec <a href="#build.lst">prj/build.lst</a>
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.</li>
        <li><i>deliver</i> : ce script perl <i>solenv/bin/deliver.pl</i>
installe les entêtes, et les librairies (etc.) dans le solver comme
l'en informe <a href="#d.lst">prj/d.lst</a>. 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.</li>
      </ul>
      <span style="font-weight: bold;">5.5.1 Répertoires standards</span><br>
Il y a plusieurs répertoires standards et fichiers dans la plupart des
modules qui constituent OO.o, en voici quelques-uns des plus utiles.<br>
      <ul>
        <li><span style="font-weight: bold;">prj </span><br>
        </li>
        <ul>
          <li><i>build.lst</i> : cela liste les répertoires qui
doivent être faites,&nbsp; les commentaires '^#'sont permis, l'ordre de
cette liste est sans importance voir les <a href="#build.lst">détails</a>,
il est dicté par les
opérations de '<span style="font-style: italic;">builds</span>'<br>
          </li>
          <li><i>d.lst</i> : ce fichier décrit le processus <span
 style="font-style: italic;">deliver</span>, voir les <a href="#d.lst">détails</a></li>
        </ul>
        <li><span style="font-weight: bold;">util</span> :
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 <span
 style="font-style: italic;">makefile.mk</span>, c'est en général le
dernier répertoire construit dans un projet.</li>
        <li><span style="font-weight: bold;">inc</span> :&nbsp; 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 <span
 style="font-style: italic;">prj/d.lst</span>)</li>
      </ul>
Il y a également plusieurs types de fichiers qui sont (ou ne sont pas)
intéressants :<br>
      <ul>
        <li><span style="font-weight: bold;">makefile.rc</span> : ils
sont tous plus ou moins redondants et peuvent ignorés sans problème</li>
        <li><span style="font-weight: bold;">makefile.mk</span> :
ceux-la au contraire sont le fichiers 'dmake' qui sont utilisés pour
compiler chaque répertoire source.</li>
      </ul>
      <span style="font-weight: bold;"><a name="build.lst"></a>5.5.2
build.lst</span><br>
Au premier coup d'oeil, build.lst à l'air inquiétant <br>
      <pre>vc      vcl : nas freetype psprint rsc sot ucbhelper unotools sysui NULL<br>vc      vcl                      usr1   -       all     vc_mkout NULL<br>vc      vcl\source\unotypes      nmake  -       all     vc_unot NULL<br>vc      vcl\source\glyphs        nmake  -       all     vc_glyphs vc_unot NULL</pre>
      <br>
aussi nous devons essayer de décortiquer ce qui se passe ici, qui n'est
en fait pas si bizarre qu'il n'y paraît au premier coup d'oeil. En
premier, les listes sont terminées par le string 'NULL'. Chaque ligne
est préfixée par un raccourci qui est significatif.<br>
      <ul>
        <li>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.</li>
        <li>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.</li>
        <li>Les lignes suivantes décrivent des dépendances internes des
répertoires du projet et ressemblent à :<br>
          <pre>[shortcut] [path to dir to build] nmake - [flags] [unique-name] [deps...] NULL<br>vc           vcl\source\glyphs    nmake -   all     vc_glyphs   vc_unot   NULL<br></pre>
          <br>
          <span style="font-style: italic;">shortcut</span> n'est pas
utilisé ; <span style="font-style: italic;">flags </span>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'.<br>
          <i>unique-name</i> c'est un nom magique, utilisé par les
autres lignes pour décrire une dépendance interne. <i>deps...</i>
n'importe quel nombre de noms des autres répertoires dans ce fichier
qui doit être compilé avant celui-là.</li>
      </ul>
Ainsi pour le cas de vcl, nous voyons que <i>vcl\source\unotypes</i>&nbsp;
(vc_unot) doit être compilé avant<i> vcl\source\glyphs</i>&nbsp;
(vc_glyphs) C'est <span style="font-weight: bold;">important</span> de
comprendre que l'ordre de la liste est ~
sans importance, et qu'à la place d'une simple liste ordonnée, nous
avons un système de dépendances internes plus complexe : cela contraste
avec la plupart des autres sytèmes make.<br>
      <br>
Il y a également de la documentation <a
 href="http://tools.openoffice.org/tools/build.html">ici</a> à ce sujet.<br>
      <br>
      <a name="d.lst"></a>5.5.3 d.lst<br>
La syntaxe de d.lst est plus facile à comprendre que celle de
build.lst, il ommet des actions par défaut comme copier build.lst dans <i>inc/&lt;module&gt;/build.lst</i>.<br>
Une ligne de la forme : <br>
      <pre>[action]: [arguments]<br>mkdir:    %_DEST%\inc%_EXT%\external</pre>
où si '[action]' est ommis, l'action 'copy' sera prise par défaut. Les
actions typiques sont <i>copy</i>, <i>mkdir</i>, <i>touch</i>, <i>hedabu</i>,
      <i>dos</i> and <i>linklib</i><br>
L'action 'hedabu' est particulièrement intéressante, dans la mesure où
il reformate cosmétiquement les entêtes pour les faire rétrécir pendant
l'installation (sinon, elle ressemble beaucoup à l'action copy)<br>
Pendant l'action, des variables de macros diverses sont étendues,
quelques-unes sont :<br>
      <ul>
        <li>%__SRC% â€” nom du répertoire de la distribution ex. <i>unxlngi4.pro</i></li>
        <li> %_DEST% â€” chemin absolue du solver ex. <i>/opt/OpenOffice/OOO_STABLE_1/solver/641/unxlngi4.pro</i>
        </li>
        <li> %_EXT% â€” chemin (inusuel) pour avoir un update mineur
ex.
641.1, typically used to version every base sub-directory.</li>
      </ul>
Typiquement cependant,&nbsp; si vraiment vous avez besoin d'ajouter une
règle (cf copies implicites de répertoire), elle sera de la forme <br>
      <pre>..\%__SRC%\inc\sal\*.h %_DEST%\inc%_EXT%\sal\*.h</pre>
NB : les chemins relatifs sont relatifs au répertoire 'prj/'<br>
      <br>
      <span style="font-weight: bold;">5.6 Itérations rapides</span><br>
Il existe plusieurs manières de venir à bout des itérations de
développement, le meilleur moyen est d'utiliser <a
 href="#3._Installer_OOo">linkoo</a> pour lier
symboliquement la librairie de l'install set directement dans votre
tronc compilé. Ainsi vous pouvez simplement recompiler un sous
répertoire, ex .<br>
      <pre>vcl</pre>
en exécutant<br>
      <pre>build</pre>
et en réexécutant soffice.bin<br>
      <br>
      <span style="font-weight: bold;">5.7 Puis-je avoir un char *,
s'il vous plaît ?</span><br>
OOo contient à peine 6 strings de wrappers, aussi les implémentations C
présentent peu d'intérêt<br>
      <ul>
        <li><code>rtl_String :</code> sal/inc/rtl/string.h<br>
string 'Normal' plus une référence de comptage <code>rtlstring-&gt;buffer</code>&nbsp;
est utile, comme l'est <code>rtlstring-&gt;length</code>&nbsp; . 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 <code>RTL_TEXTENCODING_UTF8</code>&nbsp;
et peut-être <code>RTL_TEXTENCODING_ASCII_US</code> pour de vrai ( ?).
N'hésitez pas à traiter&nbsp; <code>rtlstring-&gt;buffer</code> comme
votre char * préféré.</li>
        <li><code>OString</code> : sal/inc/rtl/string.hxx<br>
Un simple rtl_String <code></code> sal/inc/rtl/string.hxx enveloppé
dans une classe, vous pouvez utiliser <code>ostring.pData</code> pour
avoir un rtl_String&nbsp; (c'est public) . <code>OString</code> a des
méthodes raisonnablement utiles si vous en avez besoin.</li>
        <li><code>rtl_uString</code> : sal/inc/rtl/ustring.h<br>
string 'Normal' Unicode similaire à rtl_String&nbsp; 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.</li>
        <li><code>OUString</code> : sal/inc/rtl/ustring.hxx<br>
un rtl_uString enveloppé dans une classe. C'est ce qu'utilise la
plupart du code OOo pour passer les strings</li>
        <li><code>String</code>&nbsp; : tools/inc/string.hxx<br>
C'est une classe de string obsolète, aliasée à 'UniString'. Elle a un
certain nombre de limitations comme An rtl_uString&nbsp; enveloppé à
l'intérieur d'une classe. C'est ce qu'utilise la plupart du code OOo
pour passer les strings</li>
      </ul>
Dans la mesure où un homme réel utilise des strings <code>char * </code>encodés
en UTF-8, pour utiliser n'importe quel système d'API comme 'printf'
vous devez extraire un <code>char * </code>de <code>OUString</code>,
utilisez ceci :<br>
      <pre>static char *<br>gimme_utf8_please (const rtl::OUString &amp;oustring)<br>{<br>  rtl::OString ostring;<br><br>  ostring = ::rtl::OUStringToOString (oustring, RTL_TEXTENCODING_UTF8);<br>        return strdup (ostring.pData-&gt;buffer);<br>}</pre>
et l'inverse :<br>
      <pre>static rtl::OUString<br>complicate_things_into_ucs2_please (const char *utf8_string)<br>{<br>  rtl::OString ostring;<br><br>        ostring = rtl::OString (utf8_string);<br>  return rtl::OStringToOUString (ostring, RTL_TEXTENCODING_UTF8);<br>}</pre>
      <br>
Si vous souhaitez juste imprimer un string pour des besoins de
debuggage, vous voudrez sans doute lire <a href="#printout">ceci</a> .<br>
      <br>
      <span style="font-weight: bold;"><a name="5.7.2"></a>5.7.2
Examiner les strings de GDB</span><br>
Nous avons déjà vu que OOo n'utilise pas les strings <code>char *</code>
modestes. Si vous pensez que c'est assez compliqué quand vous écrivez
du
code, attendez d'avoir à le débugguer. Voilà comment avoir vos strings
de gdb/dbx qui n'utilisent pas nativement unicode.<br>
      <ul>
        <li>à partir de la branche cvs cws_srx645_ooo112fix1 vous
pouvez utiliser<br>
          <pre>(gdb) print dbg_dump(sWhatEver)</pre>
pour imprimer le contenu de
UniString/ByteStrin/rtl::OUString/rtl::Ostring quel que soit le type
lorsque vous débugguez du code C++ vois <a
 href="http://qa.openoffice.org/issues/show_bug.cgi?id=17295">l'issue
17295</a> pour les détails.</li>
      </ul>
Alternativement, si ce support n'est pas encore dans votre version OOo
alors...<br>
      <ul>
        <li>rtl_String : met le doigt dessus</li>
        <li>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.</li>
        <li>OString : <span style="font-style: italic;">p str-&gt;pData</span></li>
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 :<br>
        <pre>p *theString; # grab the length (2nd field)<br>x/&lt;length&gt;s theString-&gt;buffer</pre>
ex pour un string de 20 caractères, nous voulons <br>
        <pre>x/20s theString-&gt;buffer</pre>
      </ul>
      <ul>
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<br>
      </ul>
      <pre id="printout">::rtl::OString tmpStr = OUStringToOString (<i>MyOUString</i>, RTL_TEXTENCODING_UTF8);<br>fprintf (stderr, "String is '%s'\n", tmpStr.getStr());<br><br></pre>
      <span style="font-weight: bold;"><a name="linkoo"></a>5.8
Limitations linkoo</span><br>
Bien que trés puissant, linkoo a un certain nombre de limitations dues
à la façon dont OOo est assemblé. Il y a deux sortes de problèmes :<br>
      <ul>
        <li>Un comportement bizarre des liens - ie si vous liez
symboliquement une librairie, il suit le lien à l'exécution et finit
dans
la confusion</li>
        <ul>
          <li>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,</li>
          <li>libcgmgr2.so - cela doit être copié depuis
configmgr/unxlgni4.pro/lib à chaque fois, sinon la configuration ne
peut être chargée,</li>
        </ul>
        <li>contruction bizarre d'une librairie interne</li>
        <ul>
          <li>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 :<br>
            <pre><a href="http://ooo.ximian.com/build">build</a> &amp;&amp; <a
 href="http://ooo.ximian.com/deliver">deliver</a></pre>
puis dans desktop/source/offwrp exécutez<br>
            <pre>touch wrapper.cxx &amp;&amp; dmake</pre>
            <br>
          </li>
        </ul>
      </ul>
      <h3><a name="6._Débugguer_OOo"></a>6. Débugguer OOo</h3>
Cette section assume que vous utilisez gdb à partir d'une console<br>
      <br>
      <span style="font-weight: bold;">6.1 Compiler avec des symboles
de débuggage</span><br>
OOo inclus la possibilité d'ajouter du code de débuggage par module,
vial la commande <tt>build debug=true </tt>dans chaque module.
Malheureusement, ce n'est pas recommandé de l'exécuter pour l'ensemble
du projet, en plus d'inclure des symboles de débuggage vitaux, il
inclut également des tas d'assertions, des warnings et d'autres
vérifications variées.<br>
Ainsi si vous voulez des symboles de débuggage pour tout, vous devez
hacker plusieurs makefiles pour ajouter les symboles de débuggage [NB
cela rendra les binaires de OOo ~1Mo plus petits et la branche
complète de build envrion 8 Go aussi faites y attention] appliquez ce
patch :<br>
      <pre>--- solenv/inc/unxlngi4.mk<br>+++ solenv/inc/unxlngi4.mk<br>@@ -92,18 +92,18 @@ cc=gcc<br> # do not use standard header search paths<br> # if installed elsewhere<br> .IF "$(BUILD_SOSL)"!=""<br>-CFLAGS=<br>+CFLAGS=-g<br> .ENDIF<br> CFLAGS+=-fmessage-length=0 -c $(INCLUDE)<br> # flags for the C++ Compiler<br>-CFLAGSCC= -pipe -mcpu=pentiumpro<br>+CFLAGSCC= -g -pipe -mcpu=pentiumpro<br> # Flags for enabling exception handling<br> CFLAGSEXCEPTIONS=-fexceptions -fno-enforce-eh-specs<br> # Flags for disabling exception handling<br> CFLAGS_NO_EXCEPTIONS=-fno-exceptions<br> <br> # -fpermissive should be removed as soon as possible<br>-CFLAGSCXX= -pipe -mcpu=pentiumpro -fno-for-scope -fpermissive -fno-rtti <br>+CFLAGSCXX= -g -pipe -mcpu=pentiumpro -fno-for-scope -fpermissive -fno-rtti <br> <br> # HACK: enable Hamburg developers to build on glibc-2.2 machines but compile vs. glibc-2.1 headers<br> .IF "$(BUILD_SOSL)"==""</pre>
      <br>
Bien sûr, sans les symboles de débuggage gdb devient encore plus
inutile. Pour appliquer le patch copiez et collez la partie ci-dessus
dans /tmp/foo et dans le répertoire de base.<br>
      <pre>patch -p0 &lt; /tmp/foo</pre>
      <span style="font-weight: bold;">6.2 Positionner des points de
rupture</span><br>
Dû à un niveau assez élevé de plantages dans gdb, il est à peu près sûr
que positionner des points de ruptures avant l'exécution ne
fonctionnera pas, aussi le meilleur schéma est de <br>
      <pre>gdb ./soffice<br>break main<br>run # don't forget the arguments here<br># ... traps in main ...<br>break osl_readFile<br>continue</pre>
      <br>
Bien sûr cela ne marchera jamais si le code est implémenté dans un
librairie qui est dlopened plus tard, ce qui arrive pour une vaste
majorité du code de OOo. Aussi vous devez&nbsp; attraper le chargement
du code et alors mettre les points de rupture dedans. Pour faire cela
appliquez un point de rupture dans osl_psz_loadModule et souffrez.<br>
Alternativement si vous pouvez instrumenter le code, c'est plutôt
facile d'ajouter #include &lt;signal.h&gt; et mettez un (SIGSTOP);
quelque part dans le code qui sera attrapé dans le débuggueur.<br>
      <br>
      <span style="font-weight: bold;">6.3 Commencer au début</span><br>
Nous commençons dans 'main' avec un wrapper sal, cela appelle
vcl/source/app/svmain.cxx(SVMain). Cela invoque Main dans
pSVData-&gt;mpApp; mais pSVData est un en-ligne local. Pour débugguer
cela utilisez la variable globale pImplSVData, ex :<br>
      <pre>p pImplSVData-&gt;maAppData</pre>
Cette méthode 'Main' est typiquement : desktop/source/app/app.cxx (Main)<br>
      <br>
      <span style="font-weight: bold;">6.4 Examiner strings</span><br>
Le char * modeste (que gdb peut afficher nativement) est évité dans le
monde des objets en le wrappant avec différentes classes innombrables
que gdb ne comprend pas. Le pire, dans pas mal de cas
il est extrèmement difficile même d'imprimer le string, une des
conséquences qui a fait que nous avons pris la décision d'utiliser un
encodade ucs-2. Il y a aussi des classes string à la fois variables et
invariables.<br>
Merci de lire la <a href="#5.7.2">section 5.7.2</a> pour savoir
comment les strings marchent
dans OOo et pour avoir des indications de débuggage.<br>
      <br>
      <span style="font-weight: bold;">6.5 Permettre une compilation
dans le bon ordre</span><br>
Les dépendances de compilation des modules sont vraiment cruciales pour
obtenir une version propre. Lorsque vous tapez 'build' dans un module,
la compilation examine d'abord prj/build.list, ex neon/prj/build.lst :<br>
      <pre>xh      neon  :  soltools external expat NULL</pre>
cela signifie que 'soltools, 'external' et 'expat' doivent être
compilés et délivrés correctement avant que neon ne puisse être
compilé. Occasionnellement ces règles peuvent être brisées et personne
ne s'en aperçoit avant un moment.<br>
      <br>
      <span style="font-weight: bold;">6.6 Cela plante, mais seulement
dans gdb</span><br>
Vraiment sympa, vous avez lié symboliquement
desktop/unxlngi4.pro/bin/soffice à soffice.bin dans votre tronc
d'install, n'est-ce pas ? Cela marche correctement si vous ne faites
que l'exécuter, mais il semble que gdb défait les liens symbolique
et&nbsp; passe un lien complètement qualifié come argv[0], qui ne
permet pas d'atteindre le binaire dans le chemin, il assigne alors le
chemin du programme de base comme
/opt/OpenOffice/OOO_STABLE_1/desktop/unxlngi4.pro/bin et commence à
rechercher (ex applicat.rdb) dedans. Bien sûr quand il n'arrive pas à
trouver les informations de setup, il plante silencieusement à quelques
kilomètres du problème d'origine.<br>
      <br>
      <span style="font-weight: bold;">6.7 Cela plante, mais ne plante
pas</span><br>
Pour des raisons diverses, les détecteurs de signal sont attrapés et la
vie peut devenir plutôt confuse, ainsi le mieux pour les compileurs est
d'appliquer quelque chose comme ça :<br>
      <pre>--- sal/osl/unx/signal.c<br>+++ sal/osl/unx/signal.c<br>@@ -188,6 +188,8 @@ static sal_Bool InitSignal()<br>             bSetILLHandler = sal_True;<br>        }<br> <br>+       bSetSEGVHandler = bSetWINCHHandler = bSetILLHandler = bDoHardKill = sal_False;<br>+<br>        SignalListMutex = osl_createMutex();<br> <br>        act.sa_handler = SignalHandlerFunction;</pre>
NB. trailing space<br>
      <br>
      <span style="font-weight: bold;">6.8.1 Je ne peux trouver le code
à partir de la trace</span><br>
Quelques méthodes, décrites pour avoir un liage spécial, comme cette
clé, peuvent être utilisées dans les callbacks ; typiquement elle a un
préfixe 'LinkStub', et cherche ainsi la dernière partie de
l'identifiant dans une recherche de texte libre ex <br>
      <pre>IMPL_LINK( Window, ImplHandlePaintHdl, void*, EMPTYARG )</pre>
compile la méthode 'LinkStubImplHandlePaintHdll'.<br>
      <br>
      <span style="font-weight: bold;">6.9 Comment puis-je recompiler
seulement les fichiers que je vois dans
la trace</span><br>
Souvent lorsque vous exécutez gdb dans une compilation non débugguée,
vous ne pouvez vous permettre d'attendre et recompiler (par exemple)
tout oowriter. Aussi nous avons créé une petite aide perl avec laquelle
vous pouvez couper et coller les noms de methode/classe qui vous
intéressent à partir du stack, et cela touchera juste les fichiers
contenant ces strings pour faciliter une recompilation. Voici un flux
de travail typique de débuggage.<br>
      <pre>gdb ./soffice.bin<br>...<br>    bt<br>#0  0x40b4e0a1 in kill () from /lib/libc.so.6<br>#1  0x409acfe6 in raise () from /lib/libpthread.so.0<br>#2  0x447bcdbd in SfxMedium::DownLoad(Link const&amp;) () from ./libsfx641li.so<br>#3  0x447be151 in SfxMedium::SfxMedium(String const&amp;, unsigned short, unsigned char, SfxFilter const*, SfxItemSet*) ()<br>   from ./libsfx641li.so<br>#4  0x448339d3 in getCppuType(com::sun::star::uno::Reference<com::sun::star::document::ximporter> const*) () from ./libsfx641li.so<br>...<br>    quit<br>    cd base/OOO_STABLE_1/sfx2<br>    ootouch SfxMedium<br>    build debug=true</com::sun::star::document::ximporter><br></pre>
Ainsi tous les fichiers référençant/implémentant quelque chose avec
SfxMedium seront touchés et recompilés avec des symboles de débuggage.<br>
      <br>
      <span style="font-weight: bold;">6.10 Comment puis recompiler
tous les fichiers dans un répertoire source</span><br>
Si vous souhaitez recompiler le code seulement dans vore répertoire
courrant, vous pouvez utiliser la cible killobj dmake pour enlever les
fichiers objets :<br>
      <pre>  dmake killobj<br>      dmake</pre>
      <br>
      <span style="font-weight: bold;">6.11 Cela plante toujours dans
sal_XErrorHdll</span><br>
Vous êtes victime d'un rapport d'erreur X asynchrone <br>
      <pre>export SAL_SYNCHRONIZE=1</pre>
rendra le traffic de X syncrhone et rapportera l'erreur par la méthode
qui l'a causé, cela rendra également OOo beaucoup plus lent et le
timing différent.<br>
      <br>
      <span style="font-weight: bold;">6.12 Il échoue silencieusement à
charger mez fichiers word</span><br>
Coalan a suggéré : mettez un point de rupture sur le dessus de
ww8par.cxx&nbsp; et la queue de SwWW8ImplReader::LoadDoc et confirmez
que le document va aussi loin que le fichier d'import.<br>
Un endroit facile et humain pour mettre un point de rupture est&nbsp;
dans SwWW8ImplReader::ReadPlainChars vous pouvez voir des tas de text
au moment ou ils sont lus. Alternativement
SwWW8ImplReader::ReadPlainChars à chaque paragraphe qui est inserré.<br>
      <br>
      <span style="font-weight: bold;">6.13 Comment est-ce que
j'utilise une console de débuggage ?</span><br>
Ainsi OOo contient une importante infrastructure de débuggage, vous
pouvez la voir<a href="http://ooo.ximian.com/images/debug-window.png">
ici</a> Malheureusement l'activer n'est pas trivial. Premièrement, rien
n'est compilé dans une compilation de produit, aussi nous devons
recompiler des parties centrales du code OOo comme des compilations
non-produit et nous devons&nbsp; réexécuter linkoo pour lier ces
nouvelles compilations dans notre set.<br>
Tous d'abord, créer un fichier de débuggage d'Environnement, je
l'appelle LinuxIntelEnv.Set.debug<br>
      <pre>TMPFILE=~/.Env.Set.debug<br><br># Purge .pro bits<br>sed 's/\.pro//g' LinuxIntelEnv.Set.sh &gt; $TMPFILE<br>. $TMPFILE<br>rm $TMPFILE<br><br># Clobber product parts<br>unset PRODUCT PROSWITCH PROFULLSWITCH <br></pre>
Maintenant faites<br>
      <pre>source ./LinuxIntelEnv.Set.debug</pre>
cela met en place votre environnement pour une build non productive.<br>
cd vcl; build dbgutil=true --all linkoo<br>
Maintenant - exécutez simplement OOo et quand c'est en plein travail,
pressez &lt;Alt&gt;&lt;Maj&gt;&lt;Ctrl&gt; 'D' dans cet ordre, cela
devrait provoquer l'affichage d'une fenêtre de débuggage. Les options
de débuggage sont sauvés par la suite dans le fichier .dgbsv.init pour
la prochaine exécution, vous pouvez en contrôler l'emplacement avec :<br>
      <pre>export DBGSV_INIT=$(HOME)/.dbgsv.init</pre>
ex : c'est (malheureusement) un fichier binaire<br>
      <br>
      <span style="font-weight: bold;">6.14 Debuggage Excel
Interroperabilité</span><br>
C'est assez facile, editez sc/source/filter/inc/biffdump.hxx,
definissez EXC_INCL_DUMPER à 1 et recompilez 'sc'. Faites aussi une
copie de sc/source/filter/escel/biffrecdumper.ini vers ~. Puis exécutez<br>
      <br>
et vous devriez avoir un foo.txt avec les données de débuggage à
l'intérieur. Si vous n'obtenez rien, vous devez trouver/appliquer
sc-biffdump.diff à partire <a
 href="http://qa.openoffice.org/issues/show_bug.cgi?id=25430">d'ici</a>
      <br>
      <h3><a name="7._Contribuer_des_patches"></a>7. Contribuer des
patches</h3>
      <span style="font-weight: bold;">7.1 Style diff</span><br>
Utilisez toujours des diffs unifiés 'cvx -z3 diff -u' dans la mesure où
ils sont plus lisibles types de diff&nbsp; (et sensible) qui se lisent
et d'appliquent.<br>
      <span style="font-weight: bold;"><br>
7.2 Quelques interactions</span><br>
Cela semble une bonne idée de travailler sur la manière la meilleure
pour implémenter votre fix, et/ou d'en discuter avec un ou deux
développeurs avant tout. Une des meilleures façon est de poster sur
dev@openoffice.apache.org (labo@fr.openoffice.org pour le français) ou de
regarder sur IRC irc.libera.chat sur le cannal #openoffice. IRC
est un moyen de communication vraiment pauvre, mais mieux que pas de
communication du tout. Voir <a
 href="http://ooo.ximian.com/name-account.html">ici</a> pour savoir qui
est qui.<br>
      <span style="font-weight: bold;"><br>
7.3 Création de patch ooo-buidl</span><br>
Voir <a href="http://ooo.ximian.com/ooo-build.html#section-2.2">ici</a>
pour plus d'informations sur notre infrastructure de patchage<br>
      <br>
      <span style="font-weight: bold;">7.4 soumettre un bug</span><br>
Voir <a href="http://ooo.ximian.com/bug.html">ici</a> pour une
interface saine/hackers pour IssueZilla
d'OpenOffice.org<br>
Dans la mesure où l'on peut toujours connaître le propriétaire d'un
module en vérifiant le tag ADMIN_FILE_ OWNER il y a un petit outil dans
ooo-build : bin/owner&lt;file-name&gt; qui vous aide à
interagir/e-mailer au sujet d'un module donné, c'est mieux d'assigner
ces bugs spécifiques à cette personne.<br>
      <h3><a name="8_Conseils_divers"></a>8 Conseils divers</h3>
      <span style="font-weight: bold;">8.1 Obtenir un accompte OOo CVS</span><br>
Voici le process pour obtenir un accompte CVS pour le serveur CVS, les
compte ooo-build sont maintenus <a
 href="http://ooo.ximian.com/ooo-build.html#section-2.5.1">différemments</a>
Pour connaître comment le processus de soumission d'issue marche, voir
l'issue #7270. Une fois votre compte créé, vous devez ouvrir un tunnel
pour sécuriser le server CVS, quelque chose comme :<br>
      <pre>ssh -f -2 -P -L 2401:localhost:2401 tunnel@openoffice.org sleep 1400 &lt; /dev/null &gt; /dev/null<br></pre>
Vous devez ensuite changer CVSROOT pour pointer sur votre machine
locale, dans la mesure où c'est le point final du tunnel :<br>
      <pre>:pserver:mmeeks@localhost:/cvs<br></pre>
Votre nom de compte et mot de passe seront les mêmes que ceux que vous
utilisez pour rentrer des bugs dans le système Source Cast. Logguez
vous et... vous vous apercevrez rapidement que vous devez migrer vos
paramètre CVS sur le serveur, pour faire cela sans perdre de place avec
des checkouts répétés :<br>
      <pre>bin/re-root /path/to/checkout ":pserver:&lt;account-name-here&gt;@localhost:/cvs"<br></pre>
Bien sûr, pour faire un commit, vous devez avoir des privilèges liés au
projet et vous battre avec la bureaucracie.<br>
      <br>
      <span style="font-weight: bold;">8.2 Utiliser patch/diff</span><br>
Patch/diff sont des outils merveilleux, cependant les gens fournissent
souvent des données qui provoquent la confusion et qu'il est très
difficile de corriger. Voici quelques astuces pour remettre les choses
dans l'ordre <br>
      <ul>
        <li>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]</li>
        <li>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.</li>
        <li>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.</li>
        <li>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.</li>
      </ul>
      <span style="font-weight: bold;">8.3 Make clean</span><br>
Utilisez dmake clean dans le répertoire supérieur. Dans les versions
pre HEAD il n'y avait pas de cible 'clean' donc à la place vous devez
faire quelque chose comme (ce que fait dmake clean maintenant)<br>
      <pre>find -name 'unxlngi4.pro' -exec rm -Rf {} \;<br></pre>
      <span style="font-weight: bold;">8.4 setup CVS</span><br>
Pour une utilisation efficace de la largeur de bande passante, générez
des diffs
sensibles par défaut et suivez le cours, vous devez avoir ceci dans
votre ~/.cvsrc.<br>
      <pre>cvs -z3 -q<br>diff -upN <br>update -dP<br>checkout -P<br>status -v <br></pre>
      <span style="font-weight: bold;">8.5 Ajouter des fichiers
d'entêtes à une compilation.</span><br>
Pour ajouter des entêtes de fichier dans
external/ assurez-vous que vous les listez dans external/prj/d.lst pour
qu'ils soient copiés dans le répertoire
solver/641/unxlngi4.pro/inc/external pendant la compilation.<br>
      <br>
      <span style="font-weight: bold;">8.6 Trouver où hacker</span><br>
Il y a souvent des éléments GUI utilisés près des trucs que vous
essayez de localiser/fixer. Trouvez alors des string suffisemment
inutilisés et recherchez les dans la recherche de texte LXR, cela
devrait revéler un identifiant relatif à ce string ex : SID_AUTOFORMAT
ou FN_NUM_BULLET_ON. Une fois cela obtenu, faites une nouvelle
recherche de texte pour ce string et vous trouverez l'usage [ ou une
définition chainée à quelque chose d'autre]. Par exemple, pour les
menus/barre d'outils la fonctionnalité est habituellement dans une
définition case ex : case SID_AUTOFORMAT:...<br>
      <h3><a name="9._Liens_utiles"></a>9. Liens utiles</h3>
9.1 www.openoffice.org<br>
Alors que la structure initiale d'openoffice.org ne semble pas orientée
hackers, il y a beaucoup de <a
 href="http://www.openoffice.org/documentation.html">documentation</a>
utile si vous la cherchez un peu.<br>
Pour les nouvelles sur OOo et une perspective distincte sur OOo voir ooodocs.org<br>
      <br>
9.2 Archives de patch<br>
En produisant différentes versions d'OpenOffice.org, différents
projects ont produits des patchs (plutôt nombreux) pour OOo.
Heureusement, ils commencent à être triés à un meilleur rythme, aussi
aucun patch ne doit être nécessaire dans HEAD pour le compiler, de la
même manière beaucoup sont allés dans OOO_STABLE_1. Il peut être utile
de les utiliser tous ou certains néanmoins.<br>
      <ul>
        <li><a href="http://ooo.ximian.com/">Ximian</a> OOo patches et
outils de compilation /snpashots sont tous disponibles sous forme de <a
 href="http://ooo.ximian.com/packages">packages</a> ou de <a
 href="http://ooo.ximian.com/patches">patches</a>.</li>
        <li>Les <a href="http://www.linux-debian.de/openoffice/">pages
          </a>d'aide <a href="http://www.debian.org/">Debian</a>, avec
des patches. Et aussi le <a
 href="http://cvs.debian.org/oo-deb/debian/?cvsroot=debian-openoffice">CVS
          </a>Debian.</li>
        <li><a
 href="http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/OpenOffice.org/">archive
patch</a> de <a href="http://www.linux-mandrake.com/">Mandrake</a> OOo</li>
        <li>patches de portage OOo <a
 href="http://www.freebsd.org/cgi/cvsweb.cgi/ports/editors/openoffice/#dirlist">FreeBSD</a></li>
        <li>les fichiers specs Red Hat (basés sur ceux de Mandrake)
sont aussi intéressants à lire à partir de leur <a
 href="http://rawhide.redhat.com/pub/redhat/linux/rawhide/SRPMS/SRPMS/openoffice-1.0.1-6.src.rpm">SRPM</a>.</li>
        <li>les personnes qui veulent localiser OOo devraient étudier
les <a
 href="ftp://ftp.linux.cz/pub/linux/people/pavel_janik/OpenOffice.org_1.0.1_CZ/build-13/build/Patches">patches
          </a>de Pavel Janik</li>
      </ul>
      <h3><a name="10_FAQ_non_fréquentes"></a>10 FAQ (non fréquentes)</h3>
Comme personne ne m'a jamais demandé cela, I just made them up to
astro-turf a bit (safer, wipe-clean, more durable questions).<br>
      <br>
      <span style="font-weight: bold;">10.1 Pourquoi les branches comme
'mws_srx644' ont des nombres bizarre à l'intérieur</span><br>
En consultant des oracles variés, des entrailles, etc, il transpire
qu'en théorie ces nombres sont incrémentés chaque semaine, ils sont
freezés chaque semaine&nbsp; ainsi que le solver et l'environnement de
développement. Cependant, dans un temps plus récent, le processus de
solidification d'une simple build pour une version plus large a pris
plus lontemps qu'une semaine créant un dilemne et un tag mixé
alphanumériquement. Le mws signifie 'Master Workspace'.<br>
      <br>
      <span style="font-weight: bold;">10.2 Pourquoi la build nécessite
Java ?</span><br>
Essentiellement, il semble qu'il y a beaucoup de fichiers XML impliqués
dans l'enregistrement des composants et d'autres services divers. Il
apparaît qu'utiliser Java est juste une façon aisée de faire simplement
ces manipulations. Aussi Java peut-être utilisé gentiment pendant
l'exécution s'il est sur la machine.<br>
Mais à partir du tag SRC680_m44 il y a un <a
 href="http://www.openoffice.org/issues/show_bug.cgi?id=28773">script
python alternatif</a> inclut pour remédier au probleme de process de
ces fichiers XML utilisés pour l'enregistrement, aussi, il est possible
de compiler des versions après cette date sans java, donc votre choix
variera suivant que la compilation par défaut se fait avec java.<br>
      <br>
      <span style="font-weight: bold;">10.3 Pourquoi [t]csh est cassé ?</span><br>
C'est plutôt énigmatique, des cassages particulièrement curieux
semblent venir de la façon de piper les commandes dans stdin de façon
crucialement différente de la façon de les mettre dans tty aussi :<br>
      <pre>echo 'echo #define DLL_NAME "libsch641li.so" &gt;./foo.hxx' | /bin/tcsh -s</pre>
échoue à faire quoi que ce soit alors que taper la même chose dans le
shell fonctionne correctement. Encore plus bizarrement<br>
      <pre>tcsh -fc 'echo #define DLL_NAME "libsch641li.so" &gt;./foo.hxx'<br></pre>
fait les choses correctement. Voir aussi <a
 href="http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/">csh</a>.<br>
      <br>
      <span style="font-weight: bold;">10.4.1 Je viens juste d'essayer
de faire un re-locate de la compilation
pourquoi cela ne marche-t-il pas ?</span><br>
La réponse simple est : vous devez exécuter :<br>
      <pre>bin/relocate /path/to/new/build<br></pre>
Un réponse plus complexe est :<br>
Bon, en assumant que vous avez re-configuré les choses
(LinuxIntelEnv.Set aura besoin de chemins modifiant aussi et
ré-important dans votre shell) ensuite cela dépend grandement des
chemins non relatifs ambigus, codés dans de nombreux fichiers
générés/compilés, particulièrement les fichiers (dépendant) '.dpc*' .
Essayez :<br>
      <pre>find -name '*.dpc*' -exec rm {} \;</pre>
Le stlport fait vraiment des trucs cassés, vous aurez donc besoin
d'éditer le 'stl_gcc.h' à l'intérieur du solve/ et de replacer les deux
instances de chemins ici (voir inc/stl/config/stl_gcc.h)<br>
      <br>
      <span style="font-weight: bold;">10.5 CVS dit 'Fatal error
aborting. [acc] no suche user', pourquoi ?</span><br>
Bien sûr il est possible que votre nom d'utilisateur ne soit pas
enregistré, souvent, cela signifie simplement que ~/.cvspass a été
perdu et/ou que vous ne vous êtes pas loggués dans cvs, logguez-vous et
répétez la commande.<br>
      <br>
      <span style="font-weight: bold;">10.6 Que signifie '.pro' dans
'unxlngi4.pro' </span><br>
      <span style="font-style: italic;">Product</span>, n'est-ce pas
évident ?<br>
      <br>
      <span style="font-weight: bold;">10.7 A quoi ressemble vraiment
OpenOffice.org ?</span><br>
Aujourd'hui, j'ai trouvé une photographie de lui sur mon système, je
l'ai mise ici :<br>
      <br>
      <br>
      <img alt="layers" src="layers.png"
 style="width: 485px; height: 330px;"><br>
      <br>
      <span style="font-weight: bold;">10.8 Comment puis-je prendre une
copie d'écran de OOo ?</span><br>
OOo fait des choses vraiment étranges avec les ressources X, ainsi des
applications habituels de copie d'écran n'arrive pas à prendre de
photos. ImageMagick 'import' fait cependant un bon travail.<br>
      <pre>import foo.png<br></pre>
à partir de la console ou<br>
à la place. NB à moins que vous ne vouliez que vous souhaitiez votre
monde tout petit, vous devez afficher des grandes icônes de barre
d'outils d'abord.<br>
      <br>
      <span style="font-weight: bold;">10.9 J'essaye de compiler avec
gcc sur un préfixe avec BUILD dedans,
pourquoi cela plante ?</span><br>
C'est dû à de très sérieux crack fumeux en cours dans stlport.
Essentiellement, il y&nbsp; a des entêtes principales désagréables et
elles veullent être capable de retomber sur les entêtes précédents
(avec le même nom) - ainsi elles ont a coder le chemin en dur. Pour
éviter d'avoir à faire cela dans de multiples endroits, elles utilisent
un #define, le #define a une marcor expansion faite sur lui. Ainsi si
votre préfixe gcc contient un élément qui est une macro, vous êtes fait
:<br>
config de l'entête stlport :<br>
      <pre>#define _STLP_NATIVE_INCLUDE_PATH \<br>        /home/michael/ximian-desktop/ooo/BUILD/ooo/include/c++/3.2.2</pre>
stlport helpful macros:
      <pre># define _STLP_MAKE_HEADER(path, header) &lt;path/header&gt;<br># define _STLP_NATIVE_CPP_C_HEADER(header)  \<br>        _STLP_MAKE_HEADER(_STLP_NATIVE_INCLUDE_PATH,header)</pre>
and finally stlport cunning native include:
      <pre>#include _STLP_NATIVE_CPP_C_HEADER(foo)</pre>
      <p> Net result: </p>
      <pre>      g++ ... -D<b>BUILD</b>=<b>7663</b> ...<br>      ...<br>from /home/michael/ximian-desktop/ooo/<b>BUILD</b>/ooo/OOO_1_0_2/xml2cmp/source/xcd/main.cxx:62:<br>/home/michael/ximian-desktop/ooo/<b>BUILD</b>/ooo/OOO_1_0_2/solver/641/unxlngi4.pro/inc/stl/cstddef:35:46:<br>/home/michael/ximian-desktop/ooo/<b>7663</b>/ooo/include/c++/3.2.2/cstddef: No such file or directory<br></pre>
      <span style="font-weight: bold;">10.10 A quoi sret la description
des composants UNO XML ?</span><br>
Pas grand chose, souvent installé, mais plutôt non utilisés<br>
      <br>
      <span style="font-weight: bold;">10.11 Pourquoi le code est si
moche</span><br>
Les auteurs doivent utiliser un éditeur vraiment étrange. Il pense que
les tabs stops sont toutes les 4 colonnes. Evidemment le fichier
s'affiche mal dans les éditeurs Unix qui savent que le tab sont large
de 4 characteres.<br>
S'il vous arrive d'utiliser <a
 href="http://www.gnu.org/software/emacs/">a Real Editor</a>, nous
avons des lunettes roses à vous vendre. Collez le contenu de <a
 href="http://ooo.ximian.com/emacs.el">http://ooo.ximian.com/emacs.el</a>
dans votre .emacs ou chargez le avec une ligne comme celle-ci : <tt>(load
"/path/to/that/file.el")</tt> . N'oubliez pas d'adapter
my-openoffice-path-regexp à vos besoins.<br>
      <h3>11. Travailler avec nous</h3>
Voir le document <a href="http://ooo.ximian.com/ooo-build.html">About
ooo-build</a><br>
      <br>
Traduction Sophie Gautier<br>
      <br>
      <a href="indexlabo.html"><span
 style="font-family: helvetica,arial,sans-serif;">Retour à l'index Labo</span></a><br>
      <br>
      </td>
    </tr>
    <tr>
      <td align="right" valign="bottom">
      <p>&nbsp;</p>
<!-- Copyrights -->
      <p><small>OpenOffice.org native tongue concept and francophone
project are built for you with pride by Guy Capra (Alomphega).<br>
This fr project is also led and maintained by Sophie Gautier.</small></p>
<!-- /Copyrights --> </td>
    </tr>
  </tbody>
</table>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>