B2G ソースの .userconfig ファイルに bash コードを記入することで、ビルドプロセスのある面をカスタマイズできます。この記事では、変更により達成できることと、その方法について見ていきます。
.userconfig ファイルは、ソースコード管理下に入らないので、ソースツリーを更新しても上書きされることはありません。これは、B2G ツリーのルート に作成する必要があります。つまり、flash.sh、build.sh などと同一のディレクトリに置きます。このファイルは、config やビルドを始める前に追加しておく必要があります。
.userconfig ファイルは、(存在する場合) load-config.sh スクリプトから実行され、このスクリプトは以下のスクリプトから実行されます: setup.sh から呼び出される flash.sh と build.sh、run-gdb.sh、run-emulator.sh、tools/mach_b2g_bootstrap.py。run-*.sh スクリプトは、ビルドする Gecko の場所を決めるのに .userconfig を使います。mach_b2g_boostrap.py スクリプトは、すべての B2G に関連する mach コマンドによって使われます。
重要: .userconfig ファイルは、ホームディレクトリではなく、B2G ソースディレクトリのルートに置いてください。
Gecko のソースツリーを変更する
デフォルトでは、github のツリーからクローンされた gecko ツリーがビルドに使用されます。mozilla-inbound、または mozilla-central を使用したい人もいるでしょう。これを行うにはソースの複製を好きな場所に作っておいてから、.userconfig ファイルに GECKO_PATH を設定する行を追加します。例えば:
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}"
注記: カスタムされた Gecko を Mac OS X でビルドする場合、mozilla-central のディレクトリは大文字小文字を区別するファイルシステムである必要があります。そうでないと GECKO_PATH が無視されます。ファイルシステムが大文字小文字を区別するかどうかをチェックするには、ターミナルウィンドウで次のコマンドを実行します:
echo -n This file system is case->tmp; echo -n in>>TMP; echo sensitive>>tmp; cat tmp
B2G_DIR を上記のように取得しておくと、.userconfig でハードコードされたパスを扱わなくて済みます。
Gaia の設定を変更する
時には、Gaia の設定を変更できるようにしたいことがあるでしょう。例えば、ユーザビルドで adb を有効にするなど。gaia の Makefile は、build/settings.py の呼び出し時に --override build/custom-settings.json のパラメータを渡すので、custom-settings.json ファイルに {"devtools.debugger.remote-enabled": true} を書き込む bash を書くことができます。ここでは、custom-settings.json の変更は、必要でない限り避けるようにします。実際は custom-settings.json.new に書いておき、内容が custom-settings.jsonと異なる場合に置き換えます。
export GAIA_PATH=${GAIA_PATH:-$(cd gaia; pwd)}
export CUSTOM_SETTINGS="${GAIA_PATH}/build/config/custom-settings.json"
cat > "${CUSTOM_SETTINGS}.new" <<eof -f="" "${custom_settings}"="" {"devtools.debugger.remote-enabled":="" [[="" eof="" true}="" cmp="" ${custom_settings}="" &&="" "${custom_settings}.new"="" ]]="" if="">& /dev/null; then
rm "${CUSTOM_SETTINGS}.new"
else
mv "${CUSTOM_SETTINGS}.new" "${CUSTOM_SETTINGS}"
fi
</eof>
もう一つの簡単な方法は、Gaia 作業ディレクトリ内の build/config/custom-prefs.js ファイルを設定することです。これは、B2G ディレクトリ内にいる場合、gaia/build/config/custom-prefs.js となります。Gaia Build System Primer, Customizing the preferences を参照してください。
注記: 現在のビルドは GAIA_PATH を起点とする異なるディレクトリを見るほどスマートではありません。GECKO_PATH の動作とは異なります。Gaia の別々のクローンを使用したいときは、そのフォルダから 手動で make を実行 してください。
異なる種類のビルドを作成する
.userconfig に様々なオプションをセットすることで、makeコマンドを実行しながら、自動的に異なる種類のGaiaビルドを作成できます ―― この章ではいくつかの異なるオプションを扱います。
注記: ビルド時の make コマンドに異なるオプションを付けることで、ビルド中に動的に多数の異なるビルドオプションをセットできます。完全なリファレンスは、make オプションのリファレンス のを参照してください。
製品ビルドや開発ビルドを作成する
別の製品ビルド (ユーザに届ける最終のアプリのビルド) や、開発ビルド (付加的なテストアプリやその他のエンジニアリング機能を含むビルド) を作成するには、次の行を .userconfigに追加してください:
PRODUCTION=1
これで勝手に製品ビルドが作成されます。これは、production make オプションをセットすることで、オンザフライに実現することもできます。
あるいは、エンジニアリング機能の様々なレベルを設定するヴァリアントもあります。
VARIANT=user VARIANT=userdebug VARIANT=eng
これらのヴァリアントの違いは次の通りです:
- eng の variant は、デフォルトアプリを
/dataに置きます。その他多数のテスト目的のアプリを user/userdebug に含めます。また、デフォルトで Marionette が有効になるため、テストが実行できます。これは、variant が指定されない場合の既定値です。 - userdebug の variant は、アプリを
/systemに置きます。デフォルトで Marionette が有効になるため、テストが実行できます。アップデータが有効になるため、over-the-air (OTA/FOTA) 更新が入手できます。 - user の variant は、デフォルトアプリを
/systemに置きます。アップデータが有効になるため、over-the-air (OTA/FOTA) 更新が入手できます。
注記: user と userdebug は両方とも、ローカルで実機/エミュレータ用にビルドする場合、暗黙的に PRODUCTION=1 が設定されます。
補足: make production は、ユーザ版の Gaia をビルドして端末に焼く確かな方法です。VARIANT は、Gaia の Nightly や B2G デスクトップ用にビルドする時に指定します。
デバッグビルドを作成する
デバッグビルドを作るには、.userconfig ファイルに次の行を追加します:
export B2G_DEBUG=1
これは、ビルド時に DEBUG=1 make オプションを含めることでも、オンザフライに実現できます。
プロファイリング用ビルドを作成する
プロファイリングを有効にする (組み込みの (SPS) プラットフォームプロファイラで最良の結果を得るため) には、.userconfig ファイルに次の行を追加して再ビルドします:
export B2G_PROFILING=1
重要: B2G_NOOPT と同時に設定してはいけません。これは意味のない結果になります！
最適化を無効にする
オプティマイザ (デバッグを容易にするビルドの作成) を無効にするには、.userconfig ファイルに次の行を追加して再ビルドします:
export B2G_NOOPT=1
はじめてガイド (FTU) を無効にする
ビルドとリフレッシュを何度も行う場合、FTU アプリが毎回起動する鬱陶しいかもしれません。.userconfig ファイルに次の行を追加することで、これを無効にできます:
export NOFTU=1
これは、ビルド時に NOFTU=1 make オプションを含めることで、オンザフライに実現できます。
アップデータと更新ツールをビルドする
デフォルトでは、アップデータと更新ツールは userdebug と user ビルドでのみビルドされます。
アップデータと関連ツールを強制的にビルドするには、.userconfig ファイルに次の行を追加してください:
export B2G_UPDATER=1
Gaia 開発者モードを有効にする
アプリの開発や gaia をハックする計画がある場合、様々な役立つ設定を自動的にセットして、端末で用意に作業できます。例えば、自動的にリモートデバッグ機能を有効にし、デバッグ接続開始時にプロンプトを無効にすることができます。
必要な設定は、.userconfig ファイルに次の export 文を追加するだけです:
export DEVICE_DEBUG=1
Valgrind を有効にする
Valgrind は、アプリのメモリやスレッドの問題をデバッグするのに役立つデバッグツールです。Valgrind を実行するための詳細情報は、Debugging B2G using valgrind を参照してください。
B2G 下で Valgrind を使用するには、.userconfig に次の export 文を追加します:
export B2G_VALGRIND=1
既定のホストコンパイラの変更方法
GCC 4.7 以降を既定のコンパイラとして使用する最近のディストリビューションでは、ビルド可能にするため、選んだプラットフォームに応じて古いバージョンを指定する必要があります。そうするには .userconfig ファイルに次の 2 行を追加します。CC と CXX 変数を、別の C と C++ コンパイラを使うように設定します。例えば Ubuntu 12.10 で GCC 4.6 を使うには次のようにします:
export CC=gcc-4.6 export CXX=g++-4.6
または、ソースからビルドしたバージョンを使っている場合、実行ファイルへのフルパスを記述します:
export CC=/opt/gcc-4.6.4/bin/gcc export CXX=/opt/gcc-4.6.4/bin/g++
独自の Gecko オブジェクトツリーの場所を指定する
gecko ソースツリーとその他のビルドオプションを一旦変更した場合、オブジェクトが格納される場所も変更したくなるでしょう (つまり、例えば全てのデバッグ用オブジェクトを非デバッグ用オブジェクトのツリーと別にするなど)。次のようにします:
export GECKO_OBJDIR=${GECKO_PATH}/objdir-gonk-debug
${GECKO_PATH} を使うと、異なる gecko ツリー (例: central, beta, aurora など) を切り替えるのが楽になります。
デバッグオブジェクトと非デバッグオブジェクトの両方を保持する
.userconfig ファイルを使用して、デバッグビルドとリリースビルドを、毎回全部ビルドすることなく切り替えることができます。
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}"
echo コマンドは、現在の設定を表示します。デバッグビルドとリリースビルドを切り替えるには、7 行目の B2G_DEBUG の値を変更するだけです。