| <!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>&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 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 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 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 &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 <somefile> | head</pre> |
| Cela devrait donner une ligne '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 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, 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> : 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> |
| (vc_unot) doit être compilé avant<i> vcl\source\glyphs</i> |
| (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/<module>/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, 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->buffer</code> |
| est utile, comme l'est <code>rtlstring->length</code> . 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> |
| et peut-être <code>RTL_TEXTENCODING_ASCII_US</code> pour de vrai ( ?). |
| N'hésitez pas à traiter <code>rtlstring->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 (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 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> : 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 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 &oustring)<br>{<br> rtl::OString ostring;<br><br> ostring = ::rtl::OUStringToOString (oustring, RTL_TEXTENCODING_UTF8);<br> return strdup (ostring.pData->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->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/<length>s theString->buffer</pre> |
| ex pour un string de 20 caractères, nous voulons <br> |
| <pre>x/20s theString->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> && <a |
| href="http://ooo.ximian.com/deliver">deliver</a></pre> |
| puis dans desktop/source/offwrp exécutez<br> |
| <pre>touch wrapper.cxx && 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 < /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 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 <signal.h> 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->mpApp; mais pSVData est un en-ligne local. Pour débugguer |
| cela utilisez la variable globale pImplSVData, ex :<br> |
| <pre>p pImplSVData->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 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&) () from ./libsfx641li.so<br>#3 0x447be151 in SfxMedium::SfxMedium(String const&, 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 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 |
| 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 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 > $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 <Alt><Maj><Ctrl> '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 (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<file-name> 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 < /dev/null > /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:<account-name-here>@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 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" >./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" >./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 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) <path/header><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> </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> |