Informations
de second plan
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 licences et la FAQ.
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.
Ce document est séparé suivant ces différentes sections
Branches
source et branches de sortie (solver)
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 branche source, i.e. la structure du
répertoire qui stocke tout le code source pour la suite bureautique.
La branche solenv 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 bootstrap
créé avec le script configure.
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.
Lorsque vous exécutez bootstrap, le répertoire solver
est créé. Initiallement, le répertoire solver 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 solver.
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 solver.
Vous n'avez pas besoin de la branche source complète, ainsi,
typiquement, un développeur va faire un check out d'une seule branche et va la
compiler complètement.
Pour plus d'informations sur les branches solenv et solver,
voir le projet Tools
Utilisation
de procédures de compilation identiques
Le processus de compilation pour OpenOffice.org est identique sur
toutes les plateformes.
Un outil de conception OpenOffice.org appelé dmake
contrôle le
processus de compilation.
Il y a des makefiles (makefile.mk) et des fichiers de
compilation de
projet prj/build.lst, qui prennent en charge les
interdépendances des
modules et des répertoires à travers la branche source. Les même makefiles
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 makefiles 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.
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.
L'outil dmake est un utilitaire de conception similaire
à GNU make ou
du Workshop Compiler dmake. Cet utilitaire à une syntaxe
irrégulière
mais est disponible à partir des sources sur toutes les plateformes. La
version OpenOffice.org de dmake est une version modifiée
du freeware
original dmake.
Lorsque vous exécutez dmake à partir du répertoire
supérieur de la
branche source, tous les modules sont contruits. Ceci est possible
simplement en exécutant le build -all dans le
répertoire instsetoo. Les commandes de compilation sont
décrites dans une autre documentation.
Il y a beaucoup de dépendances entre les modules, aussi build doit
les
compiler dans un certain ordre. L'outil dmake 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 solver.
Pour plus d'information sur l'outil dmake, voir le projet Tools.
Compilation
des release Engineering
La branche source OpenOffice.org est structurée en projets.
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.
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.
Pour déterminer à quel projet appartient un module, regarder dans les
fichiers CVS/Repository. Par exemple :
froddo: /data2/office
$ cd config_office
froddo: /data2/office/config_office
$ cat CVS/Repository
tools/config_office
Nous vérifions que le répertoire (module) config_office
fait
partie du projet tools.
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 prj/build.lst
par exemple.
froddo: /data2/office/sw/prj
$ cat build.lst
sw sw : connectivity svx stoc uui sch NULL
Nous trouvons que sw dépend de connectivity, etc. Ces modules à leur
tour, dépendent d'autres, créant un arbre large et complexe.
Compilations complètes
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 distcc
et ccache peut conséquemment
allonger le temps de compilation.
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.
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.
Snapshots/Milestone compilations
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 :
- Télécharger le tarball du solver correspondant à la version
et à la plateforme sur laquelle vous souhaitez développer.
- Faites un check out des utilitaires du projet sur la
branche CVS. Cela copie le module svtools dans votre environnement
local.
- Mettez à jour la méthode dans le module svtools
- 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.
- Faites les changements de méthode xyz dans le module
svtools.
- Compilez svtools, cela produit une sortie dans la branche
de
sortie appropriée.
- Dans le modules svx, faites les changements correspondants
aux modifications apportées au svtools.
- Compilez svx, cela produit une sortie dans la branche de
sortie appropriée.
- Testez vos patches
- Un volontaire de la communauté ou le responsable du projet
vérifie vos patches, fait des commentaires ou les approuve
- les patches sont alors committés dans la branche CVS.
Note : un autre projet que vous n'avez pas vérifié peut porter le même
nom de méthode.
Astuces pour éviter de casser une build
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.
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.
Notez que la processus de build compile un répertoire complet et
ensuite construit le répertoire suivant.
Lorsque vous travaillez à l'intérieur d'un module, votre code doit
respecter la structure existante du module, de la manière suivante :
- 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.
- 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.
- 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.
Traduction
Sophie Gautier
Retour à
l'index Labo
|