Customisation avec le fichier .userconfig

Le fichier .userconfig n'est pas vérifié dans le contrôle du code source, donc vos changements ne seront pas effacés quand vous mettrez a jour votre arbre source. Il a besoin d'être créé dans la base de l'arbre du B2G; qui est dans le même dossier que flash.sh, build.sh, etc... Vous devriez ajouter ceci avant de lancer votre config et de construire vos étapes.

Le fichier .userconfig, s'il existe, est créé de source par le script load-config.sh qui est lui même créé de source par ces scripts : flash.sh, build.sh (Par setup.sh), run-gdb.sh, run-emulator.sh et tools/mach_b2g_bootstrap.py. Le script run-*.sh l'utilise pour déterminer où vous devez avoir Gecko. Le script mach_b2g_boostrap.py est utilisé par toutes commandes mach en rapport avec le B2G.

Changer l'arbre source de Gecko

Par defaut, la construction utilise l'arbre source de gecko, qui est cloné d'un autre arbre de source depuis Github. Certaines personnes préfèrent utiliser mozilla-inbound, ou mozilla-central. Pour faire ceci, créez votre clone là où vous le désirez et ajoutez une ligne dans votre .userconfig qui met en place GECKO_PATH, par exemple :

export B2G_DIR=${B2G_DIR:-$(cd $(dirname $0); pwd)}
echo "B2G_DIR = ${B2G_DIR}"

export GECKO_PATH=${B2G_DIR}/mozilla-inbound
echo "GECKO_PATH = ${GECKO_PATH}"

echo -n This file system is case->tmp; echo -n in>>TMP; echo sensitive>>tmp; cat tmp

Changer les paramètres de Gaia

Parfois, vous aimeriez pouvoir changer les paramètres de Gaia. Par exemple, autoriser adb dans une construction utilisateur.

<!-- cette partie reste à traduire

The gaia Makefile passes in --override build/custom-settings.json when calling build/settings.py, so we can write some bash which will write {"devtools.debugger.remote-enabled": true} into the custom-settings.json file. We try to avoid changing custom-settings.json if we don't need to, so we actually write into custom-settings.json.new and if the contents differ from custom-settings.json then we'll replace it.

-->

export GAIA_PATH=${GAIA_PATH:-$(cd gaia; pwd)}
export CUSTOM_SETTINGS="${GAIA_PATH}/build/config/custom-settings.json"
cat > "${CUSTOM_SETTINGS}.new" <<EOF
{"devtools.debugger.remote-enabled": true}
EOF
if [[ -f ${CUSTOM_SETTINGS} ]] && cmp "${CUSTOM_SETTINGS}" "${CUSTOM_SETTINGS}.new" >& /dev/null; then
  rm "${CUSTOM_SETTINGS}.new"
else
  mv "${CUSTOM_SETTINGS}.new" "${CUSTOM_SETTINGS}"
fi

Une autre façon plus simple de configurer consiste à utiliser le fichier build/config/custom-prefs.js présent dans le répertoire de Gaia, c'est-à-dire dans gaia/build/config/custom-prefs.js si vous êtes dans le répertoire B2G. Voir aussi Personnaliser les réglages utilisateurs Gaia.

Créer des modèles de builds

Vous pouvez créer plusieurs types de compilations automotiques de Gaia avec la commande make en pramaétrant le fichier .userconfig - cette section dénombre quelques options.

Creating production and engineering builds

To create different production builds (built with the final apps you'd want users to see) and engineering builds (built with additional test apps and other engineering features), you can add the following lines into .userconfig:

PRODUCTION=1

On its own, this creates a production build. This can also be achieved on the fly by setting the production make option.

Alternatively, there are variants, which set various levels of engineering capabilities:

VARIANT=user

VARIANT=userdebug

VARIANT=eng

The differences between these variants are as follows:

• The eng variant places the default apps in /data and includes many more apps than user/userdebug, for testing purposes. It also has Marionette enabled by default so you can run tests. This is the default value if no variant is specified.
• The userdebug variant puts apps in /system, has Marionette enabled by default so you can run tests, and has the updater enabled, so you can get over-the-air (OTA/FOTA) updates.
• The user variant places the default apps in /system and has the updater enabled, so you can get over-the-air (OTA/FOTA) updates.

Creating a debug build

To build a debug build, put the following line in your .userconfig file:

export B2G_DEBUG=1

This can be achieved on the fly at build time by including the DEBUG=1 make option.

Creating a profiling build

To enable profiling (for best results with the built-in (SPS) platform profiler), add the following to your .userconfig file then rebuild:

export MOZ_PROFILING=1

Disabling the optimizer

To disable the optimizer (which may create builds that are easier to debug), add the following to your .userconfig file then rebuild:

export B2G_NOOPT=1

Disabling First Time User experience

If you build and reflash a lot, going through the First Time User experience constantly can be annoying. You can disable this by adding the following to your .userconfig:

export NOFTU=1

This can be achieved on the fly at build time by including the NOFTU=1 make option.

Enabling Gaia developer mode

If you plan to develop apps or hack gaia, you can automatically set various usefull settings and preferences to ease working with the device. For example, it will automatically enable the remote debugging feature and disable the prompt when an incoming debugging connection starts.

What you need is the following export added to your .userconfig:

export DEVICE_DEBUG=1

Enabling Valgrind

Valgrind is useful for debugging memory or threading issues with your application. For more information on running valgrind, see Debugging B2G using valgrind [en-US].

To use valgrind under B2G, add the following to your .userconfig:

export B2G_VALGRIND=1

Changing the default host compiler

On some recent distributions which use GCC 4.7 or later as the default compiler you will need to specify an older version in order to be able to build, to do so add two lines to your .userconfig file setting the CC and CXX variables to set the alternate C and C++ compilers respectively. For example to set the GCC 4.6 compiler on Ubuntu 12.10 use:

export CC=gcc-4.6
export CXX=g++-4.6

Or if you're using a version built from sources provide the full path to the exectuables:

export CC=/opt/gcc-4.6.4/bin/gcc
export CXX=/opt/gcc-4.6.4/bin/g++

Specifying a custom Gecko object tree location

Once you start changing gecko source trees and other build options, you may want to also modify where your objects get stored (so, for example, all of your debug objects go into a different tree from your non-debug objects). So you might do something like:

export GECKO_OBJDIR=${GECKO_PATH}/objdir-gonk-debug

Using ${GECKO_PATH} makes it easy to switch between different gecko trees (eg: central, beta, aurora, etc).

Keeping both debug and non-debug objects

You can use your .userconfig file to switch back and forth between debug and release builds without having to rebuild everything each time!

export B2G_DIR=${B2G_DIR:-$(cd $(dirname $0); pwd)}
echo "B2G_DIR = ${B2G_DIR}"

export GECKO_PATH=${B2G_DIR}/mozilla-inbound
echo "GECKO_PATH = ${GECKO_PATH}"

export B2G_DEBUG=1
echo "B2G_DEBUG = ${B2G_DEBUG}"

export GECKO_OBJDIR=${GECKO_PATH}/objdir-gonk
if [[ "${B2G_DEBUG}" != "0" ]]; then
  export GECKO_OBJDIR=${GECKO_OBJDIR}-debug
fi
if [[ "${GECKO_PATH/*mozilla-inbound*/mozilla-inbound}" == "mozilla-inbound" ]]; then
  export GECKO_OBJDIR=${GECKO_OBJDIR}-m-i
fi
echo "GECKO_OBJDIR = ${GECKO_OBJDIR}"

The echo commands help remind you what your current settings are. To switch between debug and release builds, simply change the value of B2G_DEBUG on line 7.