Builder

NOTA BENE: Traduction du manuel de Builder du 2 Mai 2010. Sylvestre a été autorisé par Kaj de Vos pour le traduire (voir forum : http://forum.syllable.org/), toutefois aucun membre de l'équipe de Syllable ne l'a supervisé.

1. Introduction

2. Comment installer Builder sur Syllable ?

- 2.1
- 2.2 Configurer Builder
- 2.3 Désinstaller et mettre à jour Builder

3. Démarrer avec la commande "build"

- 3.1 Syntaxe de la commande
- 3.2 Modes opératoires
- 3.3 Journaux de construction
- 3.4 Construire une application native
- 3.5 Construire un logiciel tiers
- 3.5.1 A propos des recettes de construction (recipes)
- 3.5.2 Installer les sources
- 3.5.2.2 Appliquer des correctifs (patch) aux sources
- 3.5.3 La construction
- 3.6 Construire un module système
- 3.6.1
- 3.6.2 Installer les sources
- 3.6.3 Construire un module
- 3.7 Construire plusieurs modules
- 3.7.1
- 3.7.2 Écrire un fichier "profile"
- 3.7.3 Fichiers "profile" prédéfinis
- 3.8 Construire un ensemble de paquets
- 3.9 Construire le système de base de Syllable

4. Créer vos propres paquets

5. Problèmes connus et limitations

1 Introduction

Cette documentation s'applique à la version 0.11.x du logiciel Builder pour les systèmes d'exploitation Syllable. Si vous rencontrez des problèmes ou avez des des remarques pertinentes, je serais intéressé d'en entendre parler (voir les coordonnées).

2 Comment installer Builder sur Syllable ?

2.1

Veuillez noter que le système de construction (Builder) est écrit avec le langage de programmation Ruby, vous devez donc avoir l'interpréteur Ruby d'installé. Reportez-vous au paquet Ruby pour Syllable pour les instructions d'installation.

Maintenant, pour l'installation de Builder. Vous devez installer une version qui correspond à votre système. Il y a deux choix de téléchargement, une pour la version bureau (Desktop) et une pour la version serveur (Server) de Syllable.

Dans le cas de Builder, il n'y a pas grandes différences entre les deux, toutefois ils sont configurés différemment.

Si vous avez téléchargé ce logiciel dans un paquet ayant l’extension "ressource" , vous devriez avoir décompressé ce paquet ainsi:

unzip Builder-0.7.63.i586.resource

ou d'une façon similaire. Ce paquet contient des fichiers CVS, vous pouvez donc le mettre à jour par Internet. Cela permettra de s'assurer que vous possédez la dernière version, avec les dernières définitions du paquet. Il est également possible d'obtenir Builder manuellement depuis le dépôt CVS de Syllable.

L'emplacement de Builder dans le serveur CVS pour Syllable est ici:

/syllable/system/apps/utils/Builder/

Le logiciel est contenu dans le répertoire "Builder". Il peut être installé n'importe où. Dans Syllable, il est généralement installé sous "/ressources/". Si vous l'avez décompressé ou copié ailleurs, tapez:

mv Builder /resources/

Vous pourriez avoir à devenir administrateur (super user) avant:

Puis tapez:

package register Builder

Cela créera les liens pour que Syllable soit capable de l'utiliser.

2.2 Configurer Builder

Si vous installez manuellement Builder à partir du serveur CVS de Syllable, vous devrez savoir que la configuration par défaut est pour Syllable version bureau (desktop). Si vous installez Builder depuis ce serveur CVS, vous devez enadapter la configuration depuis le fichier:

Builder/settings

Il y a aussi d'autres options de configuration dedans que vous pouvez changer. Ce fichier est un fichier texte avec un contenu structuré. vous pouvez l'éditer avec n'importe quel éditeur de texte, mais vous devrez faire attention à en respecter la structure. Tous les fichiers, que Builder utilise pour stocker ses données propres, ont cette même structure de base.

Vous pouvez également utiliser Builder sur des systèmes Linux autre que Syllable serveur (et probablement sur d'autres systèmes POSIX, (mais cela n'a pas été encore testé). Un moyen simple de le faire est de l'installer dans votre répertoire personnel (home) et d'ajouter le programme Builder à votre variable d'environnement (PATH). De cette façon, vous n'aurez pas besoin d'être administrateur (root) pour l'utiliser. Vous devrez également adapter le fichier de configuration avec les paramètres qui correspondent à votre situation.

Maintenant vous devriez être capable d'utiliser Builder

2.3 Désinstaller et mettre à jour Builder

Si jamais vous souhaitez supprimer Builder, suivez ces étapes. Encore une fois, vous pourriez avoir à devenir administrateur d'abord, tapez:

Ensuite, vous devez supprimer les liens de Builder avec Syllable.

package unregister Builder

Pour supprimer les fichiers appartenant a Builder, tapez:

rm -r /resources/Builder

Garder Builder à jour est facile si vous avez une connexion internet.

Il suffit de faire:

build update

build log

Cela requière que vous ayez installé le programme CVS. Si vous avez fait vos propres modifications sur des fichiers dans Builder, vous devriez toujours vérifier les journaux d'enregistrement (log) des conflits et les résoudre s'il y a lieu.

3 Démarrer avec la commande "build"

3.1 Syntaxe de la commande

Builder s'utilise avec une seule commande: build

Pour voir toutes les utilisations possibles de cette commande, tapez:

build help

Les diverses options de la commande "build" fournissent une boite à outils pour construire différents types de paquets logiciels. Certaines des options sont plus souvent utilisées que d'autres. Certaines ne sont généralement pas directement appelées, mais elles sont utilisées en interne par Builder.

3.2 Modes opératoires

Builder peut travailler de différentes façons. Il peut construire un module logiciel seul ou plusieurs modules en même temps, aussi il fait la distinction entre construire le système d'exploitation Syllable lui même ou construire une application externe. Quel mode de construction à utiliser est déterminé par la manière et l'endroit où la commande "build" est appelée.

Un seul module est construit en passant en paramètre le chemin (PATH) où le module réside à la commande "build". Plusieurs modules sont construits en passant le nom d'un profil, qui est une liste de modules logiciels. s'il y a un conflit entre le nom d'un module unique et un profil, veillez à inclure une barre oblique dans le nom du répertoire du module pour le distinguer. Vous

pouvez le faire en s'assurant qu'il y a un slash à la fin, ex:

build example/

ou encore en incluant le répertoire courant dans le chemin, ex:

build ./example

Lorsque la commande "build" est appelée à partir d'un répertoire de travail nommé "system", elle présuppose qu'elle doit construire le système de base de Syllable. Ceci est le répertoire racine de l'arborescence de Syllabe dans son référentiel CVS. Dans ce mode, plusieurs fonctions sont exécutées, de différentes manières, aussi si vous construisez une application autonome, assurez-vous de ne pas le faire à partir d'un répertoire nommé "system".

3.3 Journaux de construction

Toutes les variantes de la commande "build" n'effectuent pas des tâches de construction, mais celles qui le font, sont visibles sous plusieurs formes.Durant l'exécution, les informations de progression et les messages d'erreur sont affichés à l'écran; afin de donner un meilleur aperçu du processus (c'est à dire, "stderr" est envoyé à l'écran comme d'habitude, mais "stdout" ne l'est pas). Le reste de la sortie standard (stdout) est enregistrée dans un fichier journal (log). Pour voir l'historique de la dernière opération de construction qui a été effectuée, tapez:

build log | less

(l'affichage est généralement assez long, aussi il est plus confortable de le visionner grâce à un logiciel tel que "less"). Si vous construisez plusieurs modules, vous pouvez vouloir avoir un résumé des résultats, sans pour autant voir tous les processus, pour cela tapez:

build log summary

Lors de la construction de plusieurs modules, Builder ne s'arrête pas à un module qui ne se serait pas construit avec succès. Pour voir une liste des modules en échec, tapez:

build log failures

3.4 Construire une application native

Le cas le plus simple dans la construction d'un module logiciel, pour autant que Builder soit concerné, est celui d'une application native à Syllable. le code source de l'application doit être autonome, et doit être conforme aux spécifications que Builder attend d'une application native. Dans cette situation, Builder n'apporte pas vraiment plus qu'une compilation classique qui appelle manuellement la commande "make", de fait vous pourriez préférer cette méthode. Cependant, il forme la base pour des opérations plus utiles.

Vous devez placer le code source dans un répertoire qui a typiquement le même nom que l'application. Supposons que la racine répertoire de l'application s’appelle "example".

La première étape dans sa construction serait alors de taper:

build example

Si vous avez placé l'application dans un sous-répertoire, "applications" par exemple, alors tapez:

build applications/example

Regardez la sortie pour voir exactement quelles opérations sont effectuées par Builder. Il va nettoyer le code source, le configurer, puis essayez de le compiler. Si vous voulez voir le processus sur la sortie standard, tapez:

build log | less

Si la construction s'est terminé avec succès, vous pouvez éventuellement faire une batterie de tests (si l'application en a) ainsi:

build test example

Si tout s'est bien passé, vous pouvez l'installer. Vous pourriez avoir à devenir administrateur (super user), aussi tapez:

Puis tapez:

build install example

3.5 Construire un logiciel tiers

3.5.1 A propos des notices de construction (recipes)

Faire un paquet d'un logiciels tiers, sous-entendant que le logiciel n'est pas originaire à Syllable, mais qu'il a été porté depuis un autre système. Cela ressemble beaucoup à la construction d'un module natif. Ici, Builder commence à devenir utile. [...] Pour ce faire, Builder a besoin d'une description de ces différences, elles sont écrites sous la forme de quelque chose qui s'apparente à une notice (le fichier "recipe").

Builder contient un certain nombre de notices (recipes) pour les paquets qui ont déjà été porté sur Syllable, donc si vous construisez un de ces paquetages prédéfinis, vous n'avez pas à vous soucier de son fichier "recipe". Si vous essayez de construire un paquet qui n'est pas connue de Builder, il est encore possible que la procédure de défaut de construction soit en mesure de le construire. La procédure par défaut est orientée vers des procédures couramment utilisées pour compiler les logiciels, et en particulier vers les procédures de compilation avec les outils du projet GNU (http://www.gnu.org). Si la procédure par défaut ne réussit pas, vous aurez à trouver un fichier "recipe" pour cela ou à en écrire un vous-même. Un cas courant est d'essayer de construire une version plus récente d'un paquet qui a été porté auparavant. Dans cette situation, il y a de bonnes chances que le fichier "recipe" de l'ancienne version fonctionne. Dans tous les cas, se référer au chapitre "Créer vos propres paquets ".

3.5.2 Installer les sources

3.5.2.1

Vous pouvez installer le code source d'un logiciel tiers manuellement, d'une manière similaire à la façon dont vous mettriez les sources d'un module natif en place. Vous allez probablement obtenir les sources de ce logiciel sous la forme d'une archive compressée, que vous décompresseriez à l'endroit où vous voudriez construire le paquet. Cependant, Builder peut faire ce travail pour vous. Il suffit de déposer ces sources dans le répertoire

/resources/Builder/sources/

Lorsque vous demandez à Builder de construire un paquet dont les sources ne sont pas installées, il va les chercher à cet endroit pour les décompresser automatiquement. Ceci est très utile lorsque vous effacez régulièrement les sources afin de nettoyage. Tant que les sources sont dans Builder, alors ces sources seront restaurées suivant les besoins.

Encore mieux, si le paquet a un fichier "recipe" qui définit un téléchargement et si vous avez le programme cURL d'installé, alors Builder va télécharger les sources et les placer dans le répertoire "/sources/" directement. cURL est inclus dans les systèmes d'exploitation Syllable, de sorte vous n'ayez rien de plus à faire (sauf si vous utilisez Builder sur un autre système d’exploitation).

3.5.2.2 Appliquer des correctifs (patch) aux sources

En plus des notices de construction (recipes) décrites précédemment, la définition d'une recette pour un logiciel tiers peut également contenir des correctifs qui sont nécessaires à Syllable. Ces correctifs seront automatiquement appliqués aux sources quand vous autoriserez Builder à décompresser les sources officielles du logiciel. Si vous installez ces sources vous-même, appliquation de ces correctifs est de votre responsabilité. Cependant, vous pouvez toujours indiquer explicitement à Builder d'appliquer tous les correctifs qu'il possède ainsi:

build patch example

3.5.3 La construction

Tel que mentionné précédemment, la construction d'un package logiciel tiers ressemble beaucoup à la construction d'un module natif. Le nom du répertoire qui contient le code source aura généralement le même numéro de version que les sources. La première étape de sa construction se ferait ainsi par exemple:

build example-1.2

Si vous voulez voir la sortie standard du processus, tapez:

build log | less

Si l'application comprend une suite de tests, faites:

build test example-1.2

Pour installer le paquet, vous pourriez avoir à devenir administrateur, tapez:

L'installation se fait ainsi:

build install example-1.2

Les paquets de logiciels tiers seront installés dans leurs propres sous-répertoires (/resources/répertoire). Le gestionnaire de paquets de Syllable se chargera d'enregistrer le paquet dans syllable.

L'installation et l'enregistrement peut être annulé ainsi:

build uninstall example-1.2

Si vous voulez distribuer le paquet, vous pouvez construire un paquet afin de distribution pendant que le paquet est installé sur la machine, alors tapez:

build package example-1.2

Le paquet à distribuer sera généré dans votre répertoire de travail. Prenez soin de ne pas distribuer toutes les données sensibles que les applications peuvent avoir écrites dans leur propres répertoires alors qu'elles étaient un cours d'exécution. Si vous voulez être certain de cela, vous devez construire le paquet à distribuer immédiatement après l'installation du programme, avant sa première utilisation.

3.6 Construire un module système

3.6.1

Afin de clarifier les choses, un module système est un module propre à Syllable, construit dans le contexte de l'arborescence des sources pour le système de base de Syllable. Builder déduit ce contexte à partir d'un répertoire de travail nommé "system". En conséquence, le nom de chemin que vous utilisez pour désigner les modules que vous voulez construire doit être relatif à ce répertoire "system".

Builder mettra en place un certain nombre de variables d'environnement qui seront utilisées par ce module système. Cela suppose que l'arborescence des sources contienne le code source complet de Syllable, et en particulier les fichiers des en-têtes des fonctions systèmes. Builder créera également une nouvelle structure de répertoires dans laquelle le module pourra être installé.

La finalité de cette arborescence servira à créer une image système pour une nouvelle version de Syllable.

Bien que Builder fasse un certain nombre de préparatifs pour la construction d'un module système, il est toujours de votre responsabilité de vous assurer du bon déroulement des choses. Les modules systèmes ont souvent besoin des en-têtes des fonctions systèmes et des bibliothèques. Celles ci ont tendance à changer quand Syllabe évolue, ce qui peut empêcher la construction si les différentes versions ne sont pas compatibles. Par défaut, lors de la compilation de logiciels dans le répertoire "system", les en-têtes de l'arbre des sources de Syllable sont utilisées. Ceci peut être délicat, et il n'y a pas vraiment de solutions "clefs en main" pour y faire face.

3.6.2 Installer les sources

Généralement, les sources de Syllable et celles du module à construire sont installés à partir de CVS. Si le module est un paquet logiciel tiers; alors les mêmes considérations, qui ont été décrites dans la section pour la construction d'un paquet logiciel tiers, s'appliquent. Builder va décompresser et appliquer les correctifs, s'il le peut. Vous êtes libre de modifier l'arborescence, aussi longtemps que vous savez ce que vous faites.

3.6.3 Construire un module

Les commandes pour la construction d'un module système ne sont pas différents de celles pour les applications autonomes, ex:

build example

Installer le module sur un système en fonctionnement se fait ainsi:

build install example

Toutefois, la modification de votre système "a chaud" peut être dangereux. Les modules peuvent être construits et installés en une seule fois dans une zone de transit.

image example

va installer le module dans la zone de transit où une arborescence partielle de Syllable existe. Cette aire est située dans le sous-répertoire "stage/image/" du répertoire "system". D'ici, vous pouvez inspecter les résultats de la construction et déplacer les fichiers dans votre système en fonctionnement de façon sélective.

3.7 Construire plusieurs modules

3.7.1

Plus d'un module peut être traité en une commande avec Builder. Ceci est fait en passant le nom d'un fichier "profile" à la commande "build", au lieu d'un chemin du module.

Par exemple, pour construire un certain nombre de modules,tapez:

build example-profile

Le système de construction reconnaît un nom de "profile" car il ne contient pas de slash (/), par opposition au chemin du module.

Un "profile" contient une liste de modules. Tous les modules dans le "profile" seront traités séquentiellement. Les journaux d'enregistrement (log) contiennent toutes les informations sur le déroulement de la construction, même si un ou plusieurs modules ont échoué.

Vous pouvez obtenir la liste des modules d'un "profile" en tapant:

build modules example-profile

Vous pouvez tester tous les modules d'un "profile" d'une traite ainsi:

build test example-profile

Vous pouvez tous les installer en une fois ainsi:

build install example-profile

Un fichier "profile" peut contenir des modules natifs et tiers. De la façon dont ils sont traités correspond à ce qui a été décrit plus haut, dans leur sections respectives. A cause de cela la commande:

build uninstall example-profile

et la commande:

build package example-profile

auront des effets différents, selon ce que les modules, décrits dans le fichier "profile", sont des applications autonomes ou des parties du système de base de Syllable.

3.7.2 Écrire un fichier "profile"

Les fichiers "profile" se trouvent dans Builder ici:

/resources/Builder/profiles/

Un fichier "profile" est un simple fichier texte que vous pouvez écrire vous-même. Veuillez consulter les fichiers existants comme exemples. Les commentaires sont autorisés; ils doivent commencer par un point-virgule (;).

3.7.3 Fichiers "profile" prédéfinis

Builder contient certains fichiers "profile" prédéfinis qui peuvent être utiles. Certains de ces fichiers sont générés automatiquement par Builder lui-même. Après une commande de construction, le fichier nommé "failures" contiendra une liste des modules qui ont échoué. Ceci est très pratique si vous construisez une longue liste de modules où certains d'entre eux ont des erreurs. Vous pouvez tapez:

build log failures

pour montrer le journal (log) des modules en défauts lors de votre dernière commande. Après correction, tapez:

build failures

cela va relancer la procédure de construction sur les seuls modules qui ne s'étaient pas construits correctement. Cela fonctionnera même si vous avez invoqué la commande "build" sur des modules autonomes, ceci tout en faisant des corrections, car les fichiers "failures" ne sont mis à jour que lorsque vous travaillez avec un fichier "profile". La procédure peut être répétée jusqu'à ce que tous les modules soient corrigés.

Un autre fichier auto-généré que vous pouvez utiliser s’appelle "last". Ce fichier contient toujours le dernier fichier "profile" que la commande "build" a utilisé.

3.8 Construire un ensemble de paquets

Builder est capable de produire un groupe de paquets, à distribuer, composé de plusieurs paquets de logiciels tiers. Par exemple, Builder contient un fichier "profile" nommé "dev-pack", pour les développeurs. Celui ci est une collection de logiciels tiers couramment utilisés par les développeurs. Vous pouvez le construire ainsi:

build dev-pack

Pour installer une telle liste de paquets vous feriez:

build install dev-pack

(Dans ce cas ci, c'est légèrement plus compliqué, parce que le "dev-pack" contient plusieurs paquets qui sont dépendants les uns des autres pour se construire et parfois même pour s'installer, comme "make, binutils et GCC". Vous aurez à remplacer ces paquets avec précaution et individuellement.)

Quand vous serez satisfait de cet ensemble de paquets, vous pourrez les déplacer ici:

/resources/Builder/distributions/

puis faire:

build pack dev-pack

cela créera un groupe de paquets, à distribuer, dans votre répertoire de travail qui contiendra tous les paquets logiciels inclus dans le fichier "profile" ainsi que leur documentation.

3.9 Construire le système de base de Syllable

Au moment de la rédaction, il n'est pas possible de donner des instructions définitives pour la construction du système de base de Syllable. Bien que Builder soit capable de faire cela, Builder évolue au fil du temps avec le développement de Syllable, car Syllable est un travail en cours. Par ailleurs, si vous essayez de construire à partir des sources CVS, vous rencontrerez très probablement des échecs de compilation. Ces problèmes apparaissent entre deux versions de Syllable.

Ceci dit, voici une description de la façon dont le système est construit. pour démarrer, il y a un grand nombre de conditions préalables que vous avez à remplir pour réussir. Voici une liste des paquets que vous devez installer (sujet à changement et liste probablement incomplète). La plupart d'entre eux sont disponibles sous forme de paquets binaires, mais pour certains vous allez devoir les construire à partie des sources.

Les sources:

- Pour Syllable (Desktop), le code source

La Collection de paquets:

- Shell Essentials

- Network Necessities

- Developer's Delight

- The Perl Pit

Le paquet

- CMake

Il ya plusieurs fichiers "profile" qui définissent une liste de tous les modules du système de base. Pour Syllable (desktop) Procédez ainsi (tapez):

cd system

image syllable

build log failures

image base

build log failures

image gui-base

build log failures

image gui

build log failures

image desktop

build log failures

image finish-su

build log failures

image finish

build log failures

cd stage/image

build scrub

cd ../..

construct distro SyllableDesktop 1.0 i586

La dernière commande "construct", est un outil supplémentaire inclus avec Builder qui va séparer le système de base des fichiers de développement et créer des paquets pour chacun d'eux.

C'est pratiquement pareil pour Syllable serveur, faites:

cd system

image linux

build log failures

image base

build log failures

image gui-linux

build log failures

image gui-base

build log failures

image server

build log failures

image linux-finish

build log failures

cd stage/image

sudo build scrub

cd ../..

sudo construct distro SyllableServer 1.0 i486

Durant ce temps, vous devrez corriger les échecs de compilation, en utilisant , entre autres, des techniques lues de ce manuel. Ayez de la patience et faites le à vos risques et périls. [...]

Surtout pour Syllable version bureau (desktop); bien plus que la procédure décrite au-dessus est nécessaire pour arriver à un système complet. Nous utilisons des scripts complémentaires pour mettre en place l'environnement de construction et manipuler Builder. Ces scripts sont dans le dépôt CVS de Syllable ici:

/syllable/system/build-tools/scripts/auto-build/

Bien que ces scripts automatisent le processus; ils sont aussi un travail en progrès, développés en même temps que Syllable. Ils visent à nous aider à produire la prochaine version de développement de Syllable.

4 Créer vos propres paquets

Pour intégrer un logiciel tiers avec Builder, en vue de l'installer sur Syllable ,vous devez écrire un fichier "recipe". La documentation relative à cela à besoin d'être écrite, mais il y a un exemple, à jour, des spécifications de la syntaxe à utiliser, dans le fichier "Builder/packages/skeleton.recipe"

Pour obtenir des exemples de "recipe", veuillez étudier ceux déjà existants dans:

Builder/packages/

5 Problèmes connus et limitations

Builder est un travail en cours. Il est développé avec Syllable, de sorte que des changements et des améliorations sont faits en continu. Par conséquent, il est préférable d'utiliser une version récente, ou au moins une version qui corresponde au logiciel que vous voulez construire.

6 Contact information

Builder a été écrit par Kaj de Vos, ceci basé sur les travaux de Kristian Van Der Vliet. Vous pouvez reporter les problèmes ou apporter des correctifs sur le forum:

http://forum.syllable.org

La dernière version de Builder peut être téléchargée depuis le site internet Syllable, dans la partie téléchargements ou depuis le dépôt CVS.