content/fr/Laboratory/second_plan.html - openoffice-org - Git at Google

 <!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>Informations
 de second plan</b></font></h3>
 Cette section vous fournit des informations de second plan sur le
 processus de compilation de Star/OpenOffice.org. Notez que StarOffice
 et OpenOffice.org sont développés ensemble mais sont deux produits
 différents, pour plus de détails, voir les<a
  href="http://www.openoffice.org/license.html"> licences</a> et la <a
  href="http://www.openoffice.org/FAQs/faq-questions.html#licensing">FAQ</a>.
 Quelques
 parties de StarOffice utilisent du code tiers qui ne
 peut être utilisé avec OpenOffice.org. Des parties de ce code ont
 été remplacées par du code OpenSource et certaines parties restent à
 l'état de futur projet, par exemple la vérification grammaticale.<br>
 Ce document est séparé suivant ces différentes sections<br>
       <ul>
         <li><a href="#Branches_source_et_branche_de_sortie_">Branches
 sources et solver</a></li>
         <li><a href="#Utilisation_de_proc%C3%A9dures_de_compilation">Utilisation
 de procédures de compilations identiques</a></li>
         <li><a href="#Compilation_des_release_Engineering">Compilation
 Release Engineering</a></li>
         <li>Développer dans le projet OpenOffice.org</li>
       </ul>
       <h3><a name="Branches_source_et_branche_de_sortie_"></a>Branches
 source et branches de sortie (solver)<br>
       </h3>
 Les développeurs OpenOffice.org travaillent en parallèle sur toutes les
 plateformes. Le code source pour toutes les plateformes est identique,
 avec des exceptions pour le code de l'interface du système
 d'exploitation et du fenêtrage. Cela vous permet de compiler sur
 différentes plateformes simultanément à partir d'une seule <span
  style="font-weight: bold;">branche source</span>, i.e. la structure du
 répertoire qui stocke tout le code source pour la suite bureautique.<br>
       <br>
 La branche <code>solenv</code> contient les outils d'environnement que
 le processus de compilation utilise, pour toutes les plateformes
 supportées. A l'origine, elle contient également&nbsp; les outils de
 compilation spécifiques à la plateforme. Maintenant, ces outils de
 compilation sont créés à partir d'un script <code>bootstrap</code>
 créé avec le script <code>configure</code>.<br>
       <br>
 Le processus de compilation génère les fichiers à partir de la branche
 source et les copie dans une branche de sortie, i.e une structure de
 répertoire qui stocke tout le code source pour la suite bureautique.<br>
       <br>
 Lorsque vous exécutez <code>bootstrap</code>, le répertoire <code>solver</code>
 est créé. Initiallement, le répertoire <code>solver</code> est vide.
 Le processus de compilation peuple le répertoire. Le processus de
 compilation délivre tous les fichiers binaires, les librairies
 partagées, et les liens dynamiques des librairies au <code>solver</code>.<br>
       <br>
 Lorsque vous souhaitez compiler un projet spécifique, vous n'avez
 besoin
 que des sources du module CVS correspondant et de la branche de sortie <code>solver</code>.
 Vous n'avez pas besoin de la branche source complète, ainsi,
 typiquement, un développeur va faire un check out d'une seule <a
  href="http://tools.openoffice.org/builds">branche</a> et va la
 compiler complètement.<br>
       <br>
 Pour plus d'informations sur les branches <code>solenv </code>et <code>solver</code>,
 voir le <a href="http://tools.openoffice.org/">projet Tools</a><br>
       <h3><a name="Utilisation_de_procédures_de_compilation"></a>Utilisation
 de procédures de compilation identiques</h3>
 Le processus de compilation pour OpenOffice.org est identique sur
 toutes les plateformes.<br>
       <br>
 Un outil de conception OpenOffice.org appelé <code>dmake</code>
 contrôle le
 processus de compilation.<br>
       <br>
 Il y a des <code>makefiles</code> (makefile.mk) et des fichiers de
 compilation de
 projet <code>prj/build.lst</code>, qui prennent en charge les
 interdépendances des
 modules et des répertoires à travers la branche source. Les même <code>makefiles
       </code>sont utilisés pour toutes les
 plateformes. Les macros
 utilisées contrôlent d'éventuelles étapes spécifiques aux plateformes
 dans le processus de compilation. Cela garantie un minimum d'effort
 lors
 du portage vers une nouvelle plateforme dans la mesure où seules les
 macros dans le <code>makefiles </code>ont besoin d'être adaptées. Le
 processus de
 compilation n'a pas besoin de scripts ou de makefiles dépendant des
 plateformes supplémentaires.<br>
       <br>
 Les développeurs Sart/OpenOffice.org on réécrit la plupart des outils
 de compilation pour rendre l'expérience de compilation d'OpenOffice.org
 la plus proche possible de n'importe quelle autre
 compilation de projet OpenSource. Il en résulte que tous les outils
 utilisés lors du processus sont portables. Les développeurs
 OpenOffice.org en ont écrits certains, les autres sont des outils open
 source standards, habituellement des utilitaires GNU.<br>
       <br>
 L'outil <code>dmake </code>est un utilitaire de conception similaire
 à GNU <code>make </code>ou
 du Workshop Compiler <code>dmake</code>. Cet utilitaire à une syntaxe
 irrégulière
 mais est disponible à partir des sources sur toutes les plateformes. La
 version OpenOffice.org de <code>dmake </code>est une version modifiée
 du freeware
 original <code>dmake</code>.<br>
       <br>
 Lorsque vous exécutez <code>dmake </code>à partir du répertoire
 supérieur de la
 branche source, tous les modules sont contruits. Ceci est possible
 simplement en exécutant le <code>build -all</code>&nbsp; dans le
 répertoire <code>instsetoo</code>. Les commandes de compilation sont
 décrites dans une autre <a
  href="http://tools.openoffice.org/build_env_tools.html">documentation</a>.
 Il y a beaucoup de dépendances entre les modules, aussi <code>build </code>doit
 les
 compiler dans un certain ordre. L'outil <code>dmake </code>compile
 les répertoires
 différents dans les modules, il délivre ensuite toutes les entêtes de
 fichier, les entêtes de fichiers générés, les fichiers binaires, les
 librairies partagées, les ressources et ainsi de suite, à la branche <code>solver</code>.<br>
       <br>
 Pour plus d'information sur l'outil <code>dmake</code>, voir le <a
  href="http://tools.openoffice.org/">projet Tools</a>.<br>
       <h3><a name="Compilation_des_release_Engineering"></a>Compilation
 des release Engineering</h3>
 La branche source OpenOffice.org est structurée en projets.<br>
       <br>
 Un projet compile un composant particulier de la suite openoffice.org.
 Par exemple, le projet Writer compile l'application Writer. Un projet
 est une application, une fonction ou simplement un sommaire de classes.
 Un projet peut être subdivisé en modules. Un module est une petite
 unité de la suite qui peut être compilée.<br>
       <br>
 Les modules correspondent au répertoire sous le répertoire de niveau
 supérieur de la branche source. Par exemple, le projet Writer inclut
 les modules : sw, starmath, res, etc.<br>
 Pour déterminer à quel projet appartient un module, regarder dans les
 fichiers CVS/Repository. Par exemple :<br>
       <pre>froddo: /data2/office<br>$ cd config_office<br><br>froddo: /data2/office/config_office<br>$ cat CVS/Repository<br>tools/config_office</pre>
 Nous vérifions que&nbsp; le répertoire (module) <code>config_office</code>
 fait
 partie du projet tools.<br>
       <br>
 Il y a beaucoup de dépendances entre les modules et les modules doivent
 être construits dans un ordre particulier. Les prérequis pour les
 modules sont décrits dans la première ligne du ficheir <code>prj/build.lst</code>
 par exemple.<br>
       <pre>froddo: /data2/office/sw/prj<br>$ cat build.lst<br>sw      sw      :       connectivity svx stoc uui sch NULL</pre>
       <br>
       <br>
 Nous trouvons que sw dépend de connectivity, etc. Ces modules à leur
 tour, dépendent d'autres, créant un arbre large et complexe.<br>
       <h3>Compilations complètes</h3>
 Les développeurs OpenOffice.org réalisent une compilation complète pour
 compiler leurs modules. Une compilation complète recompile également
 tout le code source. Cela peut prendre jusqu'à 16 heures de réaliser
 une compilation complète de OpenOffice.org. Utiliser des outils comme <code>distcc
       </code>et <code>ccache </code>peut conséquemment
 allonger le temps de compilation.<br>
 Pour éviter d'avoir à recompiler une version complète à chaque fois
 qu'un
 changement de code est introduit, il est demandé aux développeurs
 d'introduire uniquement des changements binaires compatibles à moins
 que le responsable du projet ait donné son accord (insérer une méthode
 nouvelle, non virtuelle dans une class C++ serait un exemple d'un tel
 changement binaire compatible). La suite bureautique sera alors
 recompilée comme une version respin avant que la prochaine master soit
 déclarée. Une version respin obéit uniquement à des dépendances weak,
 ie : dépendances à l'intérieur d'un module. Utiliser des dépendances
 weak vous permet, par exemple, de modifier une librairie de base d'un
 fichier head sans avoir besoin de réaliser une compilation complète.
 Dans la mesure où une compilation respin est basée sur des
 modifications
 binaires compatibles, les modules peuvent être construits en parallèle
 et la compilation prend beaucoup moins de temps (quelques heures)
 contrairement à une compilation complète.<br>
       <br>
 Au contraire, les changements binaires incompatibles demandent une
 compilation complète. Pour des raisons d'efficacité, c'est uniquement
 permis avec l'autorisation du responsable du projet.<br>
       <br>
       <h3>Snapshots/Milestone compilations</h3>
 Le passage suivant est une illustration de la façon dont les
 développeurs OpenOffice.org contribuent au projet. Supposons que vous
 souhaitiez&nbsp; mettre à jour une méthode appelée xyz qui est définie
 dans le module svtools. Supposons aussi que le module svx utilise la
 métode xyz. Vous pouvez procéder de la façon suivante :<br>
       <ol>
         <li>Télécharger le tarball du solver correspondant à la version
 et à la plateforme sur laquelle vous souhaitez développer.</li>
         <li>Faites un check out des utilitaires du projet sur la
 branche CVS. Cela copie le module svtools dans votre environnement
 local.</li>
         <li>Mettez à jour la méthode dans le module svtools</li>
         <li>Vérifiez les effets de la mise à jour de la méthode dans
 les autres modules. Vous souhaitez alors vérifier combien d'autres
 modules utilisent la méthode xyz. Cela peut être difficile de
 l'établir. Vous en arrivez à la conclusion que seulement le module svx
 utilise la méthode xyz. Si vous pensez que vous pouvez faire une
 modification compatible, vous pouvez continuer.</li>
         <li>Faites les changements de méthode xyz dans le module
 svtools.</li>
         <li>Compilez svtools, cela produit une sortie dans la branche
 de
 sortie appropriée.</li>
         <li>Dans le modules svx, faites les changements correspondants
 aux modifications apportées au svtools.</li>
         <li>Compilez svx, cela produit une sortie dans la branche de
 sortie appropriée.</li>
         <li>Testez vos patches</li>
         <li>Un volontaire de la communauté ou le responsable du projet
 vérifie vos patches, fait des commentaires ou les approuve</li>
         <li>les patches sont alors committés dans la branche CVS.</li>
       </ol>
 Note : un autre projet que vous n'avez pas vérifié peut porter le même
 nom de méthode.<br>
       <br>
       <h3>Astuces pour éviter de casser une build</h3>
 Lorsque vous développez dans OpenOffice.org, votre code doit respecter
 l'ordre dans lequel les modules sont construits. Autrement, vous
 risquez de créer une dépendance circulaire. Une dépendance circulaire
 est créer, lorsque un module essaye d'utiliser une fonctionnalité d'un
 autre module qui est construit ultérieurement.<br>
       <br>
 Par exemple, si vous modifiez le module sot de manière à ce qu'il
 utilise des entêtes ou des fichiers de librairie dépendants du module
 toolkit. Le module toolkit est construit après le module sot, et dépend
 indirectement de celui-ci. Lorsque le module sot réferre au module
 toolkit, il en devient dépendant et une référence circulaire est créée.
 Cela cassera la compilation et une autre solution devra être trouvée.<br>
       <br>
 Notez que la processus de build compile un répertoire complet et
 ensuite construit le répertoire suivant.<br>
       <br>
 Lorsque vous travaillez à l'intérieur d'un module, votre code doit
 respecter la structure existante du module, de la manière suivante :<br>
       <ul>
         <li>Séparez la compilation des objets des librairies liées.
 Créez des liens dans le répertoire utils le plus possible. Cela vous
 permet également de retrouver facilement la cible des liens. <br>
         </li>
         <li>Pour réduire le temps de compilation, conservez des tailles
 raisonnables pour les sous répertoires de sources, c'est à dire moins
 de 50 fichiers.</li>
         <li>Lorsque plus d'un répertoire utilise une entête ou un
 fichier de librairie, placez le fichier dans le répertoire inc. Lorsque
 vous compilerez, cela apparaîtra dans le répertoire module-name/inc de
 la branche de sortie liée après la phase de sortie du process de
 compilation.</li>
       </ul>
       <br>
       <span
  style="font-weight: bold; font-family: helvetica,arial,sans-serif; color: rgb(255, 255, 255);"></span>Traduction
 Sophie Gautier<br>
       <br>
       <p style="margin-bottom: 0.5cm;"><font
  face="Helvetica, Arial, sans-serif"><a href="indexlabo.html">Retour à
 l'index Labo<br>
       </a></font></p>
 <!-- /Table Navigation Bar --> <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>
	<!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>Informations
	de second plan</b></font></h3>
	Cette section vous fournit des informations de second plan sur le
	processus de compilation de Star/OpenOffice.org. Notez que StarOffice
	et OpenOffice.org sont développés ensemble mais sont deux produits
	différents, pour plus de détails, voir les<a
	href="http://www.openoffice.org/license.html"> licences</a> et la <a
	href="http://www.openoffice.org/FAQs/faq-questions.html#licensing">FAQ</a>.
	Quelques
	parties de StarOffice utilisent du code tiers qui ne
	peut être utilisé avec OpenOffice.org. Des parties de ce code ont
	été remplacées par du code OpenSource et certaines parties restent à
	l'état de futur projet, par exemple la vérification grammaticale.<br>
	Ce document est séparé suivant ces différentes sections<br>
	<ul>
	<li><a href="#Branches_source_et_branche_de_sortie_">Branches
	sources et solver</a></li>
	<li><a href="#Utilisation_de_proc%C3%A9dures_de_compilation">Utilisation
	de procédures de compilations identiques</a></li>
	<li><a href="#Compilation_des_release_Engineering">Compilation
	Release Engineering</a></li>
	<li>Développer dans le projet OpenOffice.org</li>
	</ul>
	<h3><a name="Branches_source_et_branche_de_sortie_"></a>Branches
	source et branches de sortie (solver)<br>
	</h3>
	Les développeurs OpenOffice.org travaillent en parallèle sur toutes les
	plateformes. Le code source pour toutes les plateformes est identique,
	avec des exceptions pour le code de l'interface du système
	d'exploitation et du fenêtrage. Cela vous permet de compiler sur
	différentes plateformes simultanément à partir d'une seule <span
	style="font-weight: bold;">branche source</span>, i.e. la structure du
	répertoire qui stocke tout le code source pour la suite bureautique.<br>
	<br>
	La branche <code>solenv</code> contient les outils d'environnement que
	le processus de compilation utilise, pour toutes les plateformes
	supportées. A l'origine, elle contient également  les outils de
	compilation spécifiques à la plateforme. Maintenant, ces outils de
	compilation sont créés à partir d'un script <code>bootstrap</code>
	créé avec le script <code>configure</code>.<br>
	<br>
	Le processus de compilation génère les fichiers à partir de la branche
	source et les copie dans une branche de sortie, i.e une structure de
	répertoire qui stocke tout le code source pour la suite bureautique.<br>
	<br>
	Lorsque vous exécutez <code>bootstrap</code>, le répertoire <code>solver</code>
	est créé. Initiallement, le répertoire <code>solver</code> est vide.
	Le processus de compilation peuple le répertoire. Le processus de
	compilation délivre tous les fichiers binaires, les librairies
	partagées, et les liens dynamiques des librairies au <code>solver</code>.<br>
	<br>
	Lorsque vous souhaitez compiler un projet spécifique, vous n'avez
	besoin
	que des sources du module CVS correspondant et de la branche de sortie <code>solver</code>.
	Vous n'avez pas besoin de la branche source complète, ainsi,
	typiquement, un développeur va faire un check out d'une seule <a
	href="http://tools.openoffice.org/builds">branche</a> et va la
	compiler complètement.<br>
	<br>
	Pour plus d'informations sur les branches <code>solenv </code>et <code>solver</code>,
	voir le <a href="http://tools.openoffice.org/">projet Tools</a><br>
	<h3><a name="Utilisation_de_procédures_de_compilation"></a>Utilisation
	de procédures de compilation identiques</h3>
	Le processus de compilation pour OpenOffice.org est identique sur
	toutes les plateformes.<br>
	<br>
	Un outil de conception OpenOffice.org appelé <code>dmake</code>
	contrôle le
	processus de compilation.<br>
	<br>
	Il y a des <code>makefiles</code> (makefile.mk) et des fichiers de
	compilation de
	projet <code>prj/build.lst</code>, qui prennent en charge les
	interdépendances des
	modules et des répertoires à travers la branche source. Les même <code>makefiles
	</code>sont utilisés pour toutes les
	plateformes. Les macros
	utilisées contrôlent d'éventuelles étapes spécifiques aux plateformes
	dans le processus de compilation. Cela garantie un minimum d'effort
	lors
	du portage vers une nouvelle plateforme dans la mesure où seules les
	macros dans le <code>makefiles </code>ont besoin d'être adaptées. Le
	processus de
	compilation n'a pas besoin de scripts ou de makefiles dépendant des
	plateformes supplémentaires.<br>
	<br>
	Les développeurs Sart/OpenOffice.org on réécrit la plupart des outils
	de compilation pour rendre l'expérience de compilation d'OpenOffice.org
	la plus proche possible de n'importe quelle autre
	compilation de projet OpenSource. Il en résulte que tous les outils
	utilisés lors du processus sont portables. Les développeurs
	OpenOffice.org en ont écrits certains, les autres sont des outils open
	source standards, habituellement des utilitaires GNU.<br>
	<br>
	L'outil <code>dmake </code>est un utilitaire de conception similaire
	à GNU <code>make </code>ou
	du Workshop Compiler <code>dmake</code>. Cet utilitaire à une syntaxe
	irrégulière
	mais est disponible à partir des sources sur toutes les plateformes. La
	version OpenOffice.org de <code>dmake </code>est une version modifiée
	du freeware
	original <code>dmake</code>.<br>
	<br>
	Lorsque vous exécutez <code>dmake </code>à partir du répertoire
	supérieur de la
	branche source, tous les modules sont contruits. Ceci est possible
	simplement en exécutant le <code>build -all</code>  dans le
	répertoire <code>instsetoo</code>. Les commandes de compilation sont
	décrites dans une autre <a
	href="http://tools.openoffice.org/build_env_tools.html">documentation</a>.
	Il y a beaucoup de dépendances entre les modules, aussi <code>build </code>doit
	les
	compiler dans un certain ordre. L'outil <code>dmake </code>compile
	les répertoires
	différents dans les modules, il délivre ensuite toutes les entêtes de
	fichier, les entêtes de fichiers générés, les fichiers binaires, les
	librairies partagées, les ressources et ainsi de suite, à la branche <code>solver</code>.<br>
	<br>
	Pour plus d'information sur l'outil <code>dmake</code>, voir le <a
	href="http://tools.openoffice.org/">projet Tools</a>.<br>
	<h3><a name="Compilation_des_release_Engineering"></a>Compilation
	des release Engineering</h3>
	La branche source OpenOffice.org est structurée en projets.<br>
	<br>
	Un projet compile un composant particulier de la suite openoffice.org.
	Par exemple, le projet Writer compile l'application Writer. Un projet
	est une application, une fonction ou simplement un sommaire de classes.
	Un projet peut être subdivisé en modules. Un module est une petite
	unité de la suite qui peut être compilée.<br>
	<br>
	Les modules correspondent au répertoire sous le répertoire de niveau
	supérieur de la branche source. Par exemple, le projet Writer inclut
	les modules : sw, starmath, res, etc.<br>
	Pour déterminer à quel projet appartient un module, regarder dans les
	fichiers CVS/Repository. Par exemple :<br>
	<pre>froddo: /data2/office<br>$ cd config_office<br><br>froddo: /data2/office/config_office<br>$ cat CVS/Repository<br>tools/config_office</pre>
	Nous vérifions que  le répertoire (module) <code>config_office</code>
	fait
	partie du projet tools.<br>
	<br>
	Il y a beaucoup de dépendances entre les modules et les modules doivent
	être construits dans un ordre particulier. Les prérequis pour les
	modules sont décrits dans la première ligne du ficheir <code>prj/build.lst</code>
	par exemple.<br>
	<pre>froddo: /data2/office/sw/prj<br>$ cat build.lst<br>sw sw : connectivity svx stoc uui sch NULL</pre>
	<br>
	<br>
	Nous trouvons que sw dépend de connectivity, etc. Ces modules à leur
	tour, dépendent d'autres, créant un arbre large et complexe.<br>
	<h3>Compilations complètes</h3>
	Les développeurs OpenOffice.org réalisent une compilation complète pour
	compiler leurs modules. Une compilation complète recompile également
	tout le code source. Cela peut prendre jusqu'à 16 heures de réaliser
	une compilation complète de OpenOffice.org. Utiliser des outils comme <code>distcc
	</code>et <code>ccache </code>peut conséquemment
	allonger le temps de compilation.<br>
	Pour éviter d'avoir à recompiler une version complète à chaque fois
	qu'un
	changement de code est introduit, il est demandé aux développeurs
	d'introduire uniquement des changements binaires compatibles à moins
	que le responsable du projet ait donné son accord (insérer une méthode
	nouvelle, non virtuelle dans une class C++ serait un exemple d'un tel
	changement binaire compatible). La suite bureautique sera alors
	recompilée comme une version respin avant que la prochaine master soit
	déclarée. Une version respin obéit uniquement à des dépendances weak,
	ie : dépendances à l'intérieur d'un module. Utiliser des dépendances
	weak vous permet, par exemple, de modifier une librairie de base d'un
	fichier head sans avoir besoin de réaliser une compilation complète.
	Dans la mesure où une compilation respin est basée sur des
	modifications
	binaires compatibles, les modules peuvent être construits en parallèle
	et la compilation prend beaucoup moins de temps (quelques heures)
	contrairement à une compilation complète.<br>
	<br>
	Au contraire, les changements binaires incompatibles demandent une
	compilation complète. Pour des raisons d'efficacité, c'est uniquement
	permis avec l'autorisation du responsable du projet.<br>
	<br>
	<h3>Snapshots/Milestone compilations</h3>
	Le passage suivant est une illustration de la façon dont les
	développeurs OpenOffice.org contribuent au projet. Supposons que vous
	souhaitiez  mettre à jour une méthode appelée xyz qui est définie
	dans le module svtools. Supposons aussi que le module svx utilise la
	métode xyz. Vous pouvez procéder de la façon suivante :<br>
	<ol>
	<li>Télécharger le tarball du solver correspondant à la version
	et à la plateforme sur laquelle vous souhaitez développer.</li>
	<li>Faites un check out des utilitaires du projet sur la
	branche CVS. Cela copie le module svtools dans votre environnement
	local.</li>
	<li>Mettez à jour la méthode dans le module svtools</li>
	<li>Vérifiez les effets de la mise à jour de la méthode dans
	les autres modules. Vous souhaitez alors vérifier combien d'autres
	modules utilisent la méthode xyz. Cela peut être difficile de
	l'établir. Vous en arrivez à la conclusion que seulement le module svx
	utilise la méthode xyz. Si vous pensez que vous pouvez faire une
	modification compatible, vous pouvez continuer.</li>
	<li>Faites les changements de méthode xyz dans le module
	svtools.</li>
	<li>Compilez svtools, cela produit une sortie dans la branche
	de
	sortie appropriée.</li>
	<li>Dans le modules svx, faites les changements correspondants
	aux modifications apportées au svtools.</li>
	<li>Compilez svx, cela produit une sortie dans la branche de
	sortie appropriée.</li>
	<li>Testez vos patches</li>
	<li>Un volontaire de la communauté ou le responsable du projet
	vérifie vos patches, fait des commentaires ou les approuve</li>
	<li>les patches sont alors committés dans la branche CVS.</li>
	</ol>
	Note : un autre projet que vous n'avez pas vérifié peut porter le même
	nom de méthode.<br>
	<br>
	<h3>Astuces pour éviter de casser une build</h3>
	Lorsque vous développez dans OpenOffice.org, votre code doit respecter
	l'ordre dans lequel les modules sont construits. Autrement, vous
	risquez de créer une dépendance circulaire. Une dépendance circulaire
	est créer, lorsque un module essaye d'utiliser une fonctionnalité d'un
	autre module qui est construit ultérieurement.<br>
	<br>
	Par exemple, si vous modifiez le module sot de manière à ce qu'il
	utilise des entêtes ou des fichiers de librairie dépendants du module
	toolkit. Le module toolkit est construit après le module sot, et dépend
	indirectement de celui-ci. Lorsque le module sot réferre au module
	toolkit, il en devient dépendant et une référence circulaire est créée.
	Cela cassera la compilation et une autre solution devra être trouvée.<br>
	<br>
	Notez que la processus de build compile un répertoire complet et
	ensuite construit le répertoire suivant.<br>
	<br>
	Lorsque vous travaillez à l'intérieur d'un module, votre code doit
	respecter la structure existante du module, de la manière suivante :<br>
	<ul>
	<li>Séparez la compilation des objets des librairies liées.
	Créez des liens dans le répertoire utils le plus possible. Cela vous
	permet également de retrouver facilement la cible des liens. <br>
	</li>
	<li>Pour réduire le temps de compilation, conservez des tailles
	raisonnables pour les sous répertoires de sources, c'est à dire moins
	de 50 fichiers.</li>
	<li>Lorsque plus d'un répertoire utilise une entête ou un
	fichier de librairie, placez le fichier dans le répertoire inc. Lorsque
	vous compilerez, cela apparaîtra dans le répertoire module-name/inc de
	la branche de sortie liée après la phase de sortie du process de
	compilation.</li>
	</ul>
	<br>
	<span
	style="font-weight: bold; font-family: helvetica,arial,sans-serif; color: rgb(255, 255, 255);"></span>Traduction
	Sophie Gautier<br>
	<br>
	<p style="margin-bottom: 0.5cm;"><font
	face="Helvetica, Arial, sans-serif"><a href="indexlabo.html">Retour à
	l'index Labo<br>
	</a></font></p>
	<!-- /Table Navigation Bar --> <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>