mozilla
Vos résultats de recherche

    Se préparer pour la premiere construction de B2G

    Avant de pouvoir construire B2G, vous devez cloner le dépôt et configurer votre arborescence. Cet article explique comment faire.

    En fonction de votre connexion internet, l'étape de configuration prend un certain nombre d'heures pour télécharger les fichiers nécessaires à la construction de FirefoxOS (avec une connexion médiocre de 150 kbps, le téléchargement de gigaoctets du dépôts Android peut prendre des dizaines d'heures). L'attente n'est pas aussi amusante que l'action, donc après avoir lu cette page et une fois lancé le script de configuration, pensez à utiliser ce temps pour mettre en place et tester le Firefox OS simulator,  commencez à vous familiariser avec la documentation pour les développeurs d'applications y compris la conception et la construction d'une application, et à vous familiariser avec les informations sur les étapes à venir.

    Vous devriez peut-être avoir prévu une tâche à côté , ou un ami avec lequel aller prendre un café, pendant que vous exécutez la config de B2G. Cela peut prendre un peu de temps (la configuration dure environ 45 min avec une connexion rapide, la compilation dure environ 30 min sur un Core i7 avec 8 Go de RAM).

    Si vous utilisez OS X pour compiler Firefox OS pour un Flame, rendez-vous sur la page Compiler Firefox OS pour un Flame sur OS X.

    Cloner le dépot  B2G

    La première étape, avant de pouvoir commencer votre première compilation, consiste à cloner le dépôt B2G. On ne récupèrera pas tout le code mais uniquement les outils de compilation et les utilitaires de configuration. La majeure partie du code de B2G se situe au sein du dépôt principal de Mozilla qui est un dépôt Mercurial.

    Pour cloner le dépôt, utiliser git avec la commande suivante :

    git clone git://github.com/mozilla-b2g/B2G.git

    Après le clonage (qui ne devrait prendre qu'une minute avec une connexion rapide), déplacez vous dans le répertoire B2G :

    cd B2G
    
    

    Configurer B2G pour votre appareil

    Important : Rappelez-vous que seuls les appareils fonctionnant sous Android 4 (alias Ice Cream Sandwich) et les plate-formes basées sur celui-ci sont pris en charge (c'est le cas des appareils actuels fonctionnant sur Firefox OS). Veuillez vérifier que votre téléphone fonctionne réellement avec ICS, sinon cette étape échouera très probablement, car certains pilotes sont tirés de dispositifs non-Nexus. Aussi, si vous devez flasher votre appareil avec ICS, gardez à l'esprit que certains concentrateurs USB ne fonctionnent pas bien avec des outils de flash, il faudra peut-être utiliser un port USB intégré directement à votre ordinateur.
    Important : si vous effectuez la compilation sur Ubuntu 12.10 + ou Fedora, vous devrez spécifier GCC 4.6 comme compilateur par défaut après avoir récupéré les sources de B2G afin que le processus fonctionne (ces distributions utilisent GCC 4.7 par défaut). Lire Changer le compilateur par défaut pour savoir comment faire.
    Note : Avant toute chose, assurez-vous de lire TOUTES les instructions ci-dessous. Vous pourrez ainsi vous assurer de bien comprendre ce que vous faites et que vous utilisez les bonnes commandes parmi celles listées !

    Une fois que vous avez récupéré le système de construction B2G de base, vous devez le configurer pour le périphérique sur lequel vous prévoyez de l'installer. Pour obtenir une liste des périphériques pris en charge, vous pouvez utiliser l'utilitaire config.sh - exécutez la commande suivante à partir du répertoire B2G :

    ./config.sh
    

    Cela permet d'afficher une liste des périphériques pris en charge, comme suit :

    Usage: ./config.sh [-cdflnq] (device name)
    Flags are passed through to |./repo sync|.
    
    Valid devices to configure are:
    - galaxy-s2
    - galaxy-nexus
    - nexus-4
    - nexus-s
    - nexus-s-4g
    - otoro
    - unagi
    - inari
    - keon
    - peak
    - leo
    - hamachi
    - helix
    - wasabi
    - tara
    - pandaboard
    - emulator
    - emulator-jb
    - emulator-x86
    - emulator-x86-jb
    

    Si votre appareil n'est pas répertorié, vous devriez arrêter dès maintenant et nous aider à porter B2G pour votre appareil ou attendre que quelqu'un d'autre le fasse. Bien entendu, si vous êtes en mesure d'aider à porter B2G pour votre appareil, nous en serons ravi, ainsi que les autres personnes qui souhaitent utiliser B2G sur cet appareil !

    Note : Vous pouvez aussi consulter la page Appareil Firefox OS Phones.

    Note : Configurer et compiler B2G pour un Keon sur un Mac NE FONCTIONNE PAS. Vous aurez besoin d'utiliser Linux lors de la compilation de la version de cet appareil.
    Note : Si pour une raison quelconque, vous voulez construire contre une version spécifique de Gecko, voir Building against a custom Gecko avant de poursuivre. Si vous voulez construire une branche autre que la valeur par défaut pour votre périphérique (par exemple, pour construire une version spécifique de B2G), voir Building a branch. Note : la branche par défaut varie selon l'appareil et n'est pas nécessairement la branche principale (trunk).

    Il serait temps pour une pause-café, car à ce moment-là, vous ferez votre premièr chargement de tout le code nécessaire pour construire Boot to Gecko. L'exécution de l'étape de configuration de l'appareil, comme indiqué ci-dessous peut prendre un certain temps, vous pouvez l'arrêter en appuyant sur Ctrl-C et la redémarrer à un moment ultérieur. Si vous pensez qu'une partie du processus peut avoir été terminée sans avoir été completée, exécutez './repo sync' pour réparer les éventuels problèmes.

    Configurer la compilation de B2G pour un appareil mobile

    À ce stade, connectez votre appareil s'il n'est pas déjà connecté, le processus de configuration en aura besoin pour accéder.

    Si votre appareil a été inscrit dans les résultats présentés ci-dessus, vous pouvez commencer le processus de configuration en exécutant config.sh à nouveau, cette fois en spécifiant le nom de votre appareil. Par exemple, pour construire le Samsung Google Nexus S, vous devez taper:

    ./config.sh nexus-s
    

    Note : Si vous obtenez une erreur semblable à :

    UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 9: ordinal not in range(128)

    Cela peut être dû aux caractères accentués ou non supportés dans le chemin absolu vers le répertoire courant (par exemple '/home/username/Téléchargements/B2G/'). Pour résoudre ce problème, il faut déplacer le dépôt B2G dans un autre répertoire. Cf. http://stackoverflow.com/questions/18049320/repo-init-unicodedecodeerror-on-ubuntu-13-04

    Sur OS X, un erreur similaire peut se produire :

    File "/Path/to/B2G/.repo/repo/git_refs.py", line 155, in _ReadLoose1
        ref_id = ref_id.decode()
    UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 578: ordinal not in range(128)

    Une des méthodes permettant de résoudre cette erreur est de modifier la ligne 155 du fichier git_refs.py situé dans '/chemin/vers/B2G/.repo/repo' :

    ref_id=ref_id.decode() vers ref_id=ref_id.decode('latin-1')

    Note : Si vous obtenez une erreur semblable à fatal: manifest 'nexus-s.xml' not available, vous pouvez préciser la branche à utiliser. Voir Building a branch pour plus de détails.
    Note : Si la configuration échoue avec un message semblable à error: manifest required for this command -- please run init, il se peut que le fichier ne manifeste n'ait pas été créé correctement (c'est le fichier B2G/.repo/manifest.xml). Pour cela, relancer config.sh, si vous configurez un nouvel appareil, vous pouvez ajouter le chemin de votre manifeste comme option pour le script config.sh :
    ./config.sh <device> -m path/to/manifest.

    Au début de la configuration, vous devrez peut-être définir votre identité (celle utilisée par git) ainsi que votre choix pour l'utilisation de la couleur. Le processus reprendra après ces choix. En ce qui concerne la configuration de la couleur, vous pouvez généralement choisir 'y' (ce qui correspond à un build qui permettra d'afficher des couleurs).

    Note : config.sh peut parfois échouer lors des étapes liées à git :

    Fetching projects:  95% (118/124)
    error: Exited sync due to fetch errors

    Cette erreur est provoquée par un problème de connexion au dépôt Android. Vous pouvez alors relancer config.sh. Après un certain temps, le téléchargement reprendra où il s'était arrêté. Cela peut se reproduire plusieurs fois, et il faudra relancer le téléchargement à chaque fois jusqu'à ce que tout les projets soient récupérés.

    Configurer une compilation à partir d'une sauvegarde système

    Si votre téléphone n'a plus Android installé et que votre arborescence B2G ne contient pas les blobs binaires, mais vous avez effectué une sauvegarde de la partition /system, vous pourrez construire une version à partir de la sauvegarde système :

    ANDROIDFS_DIR=<chemin absolu vers le répertoire parent du répertoire system> ./config.sh <target>
    

    Par défaut, le système de compilation considèrera un chemin par défaut comme backup-inari/system (selon la configuration de l'appareil). Si vous déplacez les fichiers de la sauvegarde dans ce répertoire, il ne sera pas nécessaire de spécifier le chemin dans les options de config.sh.

    Si votre téléphone a toujours fonctionné sous Firefox OS et n'a jamais exécuté Android, vous pouvez toujours copier la partition /system depuis l'appareil vers les emplacements adéquats — les fichiers obtenus seront corrects.

    Configurer la compilation B2G pour un émulateur

    Si vous préférez construire un émulateur plutôt qu'une image pour un téléphone, vous devez spécifier emulator* pour avoir un émulateur d'appareil ARM, ou emulator-x86* pour émuler un appareil fonctionnant avec une architecture x86. La deuxième option sera plus rapide mais ne correspond pas à l'architecture des appareils cibles et n'est donc pas autant maintenue que son équivalent ARM : c'est pourquoi il est découragé de l'utiliser.

    Pour construire un émulateur d'appareil avec Android Jellybean et une architecture ARM, il suffit d'utiliser la commande suivante :

    ./config.sh emulator-jb
    

    Au début de la configuration il est possible que vous ayez besoin de configurer les options de pour les couleurs. Dans la plupart des cas il convient de répondre 'y' pour oui (ce qui permettra d'afficher des couleurs dans le simulateur).

    À cet étape vous devriez être prêt à démarrer la compilation. Si vous avez besoin d'informations détaillées, vous pourrez les trouver dans les paragraphes suivants.

    Attention : sur un Linux 64 bits, compiler un émulateur peut ne pas fonctionner.

    Note : Les développeurs utilisant Mac OS X 10.9 ou supérieur devront spécifier l'option emulator-jb ou emulator-kk. En effet, l'émulateur pour Android Ice Cream Sandwich (ICS) ne peut pas être compilé sur Mac OS X 10.9. Voir les prérequis pour Mac OS X pour plus d'informations à ce sujet.

    Compiler en utilisant une version personalisée de Gecko

    Il est possible de compiler Boot to Gecko avec une version différente de celle par défaut (définie dans le fichier de manifeste). Vous pouvez modifier la version de Gecko à utiliser en modifiant le fichier .userconfig. Par exemple, si vous souhaitez compiler une version utilisant mozilla-central :

    export GECKO_PATH=/chemin/vers/mozilla-central
    export GECKO_OBJDIR=/chemin/vers/mozilla-central/objdir-gonk
    

    Note : Sous Mac OS X, le répertoire mozilla-central doit se situer dans un système de fichiers sensible à la casse.

    Cette étape peut être réalisée avant ou après avoir récupéré le dépôt (avant l'exécution de config.sh). Grâce à plusieurs fichiers .userconfig, vous pouvez aussi conserver différentes versions (avec le débogage ou non, etc.). Vous pouvez stocker des paramètres différents dans chacun des différents fichiers et créer un lien symbolique (symlink) vers le fichier que vous souhaitez utiliser au moment de la compilation.

    Pour plus d'informations, voir la page Modifier la version de Gecko utilisée.

    Construire B2G à partir d'une branche spécifique

    Si vous voulez contruire à partir d'une branche différente de celle par défaut (elle n'est pas nécessairement nommée master !), vous aurez besoin de préfixer votre appel à config.sh avec le nom de la branche :

    BRANCH=nom-de-la-branche ./config.sh <appareil>

    Les noms des branches sont généralement logiques et suivent les noms des produits/versions : v1-train, v1.0.0, v1.0.1, v1.1, v1.1.0hd, v1.2, v1.3, v1.4, v2.0... Par exemple, si vous voulez construire B2G Firefox 1.2 pour l'émulateur ARM, vous pouvez utiliser la commande :

    BRANCH=v1.2 ./config.sh emulator

    Si vous avec déjà lancé config.sh, vous pouvez voir le nom des branches en allant dans le répertoire B2G/.repo/manifests et en exécutant "git branch -a". Le nom de la branche correspond au dernier composant :

      remotes/origin/master -> master
      remotes/origin/v1-train -> v1-train
    

    Pour plus d'informations sur les différentes personnalisations, vous pouvez consulter l'article Personnaliser votre version grâce au fichier .userconfig.

    Copier votre arborescence B2G vers une autre machine

    Si vous avez déjà préparé une arborescence complète pour B2G et que vous devez changer de machine, il vous suffit de migrer toute l'arborescence vers un emplacement sur la nouvelle machine. Pour cela il suffit de monter le système de fichier de votre ancienne machine sur la nouvelle et de faire :

    rsync -a source/ destination/
    

    source correspond au chemin vers la racine de l'arborescence (avec la barre oblique / à la fin), dest correspond au chemin de destination de la copie (avec le / à la fin !).

    N.B. : Si vous copiez les fichiers à partir d'une machine avec une architecture différente n'oubliez pas d'éxécuter './build.sh clean' avant de démarrer la compilation. SInon, vous risquez de rencontrer des problèmes de compilation.

    Vous pouvez maintenant consulter la page sur la compilation.

    Mettre à jour votre arborescence B2G

    Quand le répertoire est mis à jour vers une nouvelle version de Gecko, vous pourrez mettre à jour votre arborescence. Pour ce faire, utilisez les commandes suivantes :

    git fetch origin
    git checkout origin/master

    Vous pouvez vérifier que les commandes ont réussi avec :

    git show HEAD

    Puis en vérifiant que la modification indiquée par la commande correspond à celle donnée par :

    https://github.com/mozilla-b2g/B2G/commits/master

    Prochaine étape

    Si tout s'est bien déroulé, vous pouvez passer à la compilation de Firefox OS.

    Étiquettes et contributeurs liés au document

    Contributors to this page: SphinxKnight, Hamadr, Goofy, copinmalin, nounoursheureux
    Dernière mise à jour par : SphinxKnight,
    Masquer la barre latérale