変数を作成する

• 次のコマンドを実行します。
• 事前定義された変数
• 事前定義された genrule 変数
• 事前定義されたソース/出力パス変数
• カスタム変数

「Make」変数は、 「Make 変数の置換の対象」としてマークされた属性で使用できる、特別なクラスの展開可能な文字列変数です。

たとえば、特定のツールチェーン パスを ユーザーが作成したビルド アクションに挿入するために使用できます。

Bazel には、すべての ターゲットで使用できる事前定義変数と、依存関係ターゲット で定義され、それらに依存するターゲットでのみ使用できるカスタム変数があります。

「Make」という用語が使用される理由は歴史的なものです。これらの変数の構文とセマンティクスは、元々 GNU Make と一致するように設計されていました。

次のコマンドを実行します。

_「Make 変数の置換の対象」_としてマークされた属性は、次のように「Make」変数 FOO を参照できます。

my_attr = "prefix $(FOO) suffix"

つまり、$(FOO) に一致するサブ文字列は FOO の値に展開されます。その値が "bar" の場合、最終的な文字列は次のようになります。

my_attr = "prefix bar suffix"

FOO が使用するターゲットに認識されている変数に対応していない場合、Bazel はエラーで失敗します。

名前が @ などの文字以外の記号である「Make」変数は、かっこなしで ドル記号のみを使用して参照することもできます。次に例を示します。

my_attr = "prefix $@ suffix"

$ を文字列リテラルとして書き込む（つまり、変数の展開を防ぐ）には、$$ と記述します。

事前定義された変数

事前定義された「Make」変数は、任意のターゲットの 「Make 変数の置換の対象」としてマークされた任意の属性で参照できます。

特定のビルド オプションのセットに対するこれらの変数のリストとその値を確認するには、次を実行します。

bazel info --show_make_env [build options]

大文字で始まる出力行を確認します。

事前定義された変数の例をご覧ください。

ツールチェーン オプション変数

• COMPILATION_MODE： fastbuild、dbg、opt。（詳細 ）

パス変数

• BINDIR: ターゲット アーキテクチャ用に生成されたバイナリ ツリーのベース。

  クロスコンパイルをサポートするため、ホスト アーキテクチャで ビルド中に実行されるプログラムには別のツリーが使用される場合があります。

  genrule 内からツールを実行する場合は、パスを取得する推奨される方法は $(execpath toolname) です。ここで、toolname は genrule の tools 属性にリストされている必要があります。

• GENDIR: ターゲット アーキテクチャ用に生成されたコードツリーのベース。

マシン アーキテクチャ変数

• TARGET_CPU: ターゲット アーキテクチャの CPU（k8 など）。

事前定義された genrule 変数

以下は genrule's cmd 属性で特別に使用でき、 通常、その属性を機能させるために重要です。

事前定義された genrule 変数の例をご覧ください。

• OUTS: genrule の outs リスト。出力ファイルが 1 つしかない場合は、 `$@` を使用することもできます。$@
• SRCS: genrule の srcs リスト（より正確には、srcs リスト内のラベルに対応するファイルのパス名）。ソースファイルが 1 つしかない場合は、$< を使用することもできます。
• <: 単一ファイルの場合は SRCS。それ以外の場合は ビルドエラーが発生します。
• @: 単一ファイルの場合は OUTS。それ以外の場合はビルドエラーが発生します。 ビルドエラーが発生します。

• RULEDIR: ターゲットの出力ディレクトリ。つまり、genfiles ツリーまたは bin ツリーの下にあるターゲットを含むパッケージの名前に対応するディレクトリ。 //my/pkg:my_genrule の場合、my/pkg で終わります。 //my/pkg:my_genrule の出力がサブディレクトリにある場合でも、

• @D: 出力ディレクトリ。outs にエントリが 1 つある場合、このエントリはそのファイルを含むディレクトリに展開されます。複数のエントリがある場合、genfiles ツリー内のパッケージのルート ディレクトリに展開されます。すべての出力ファイルが同じサブディレクトリにある場合でも。

  注: @D ではなく RULEDIR を使用してください。RULEDIR はセマンティクスが単純で、出力ファイルの数に関係なく同じように動作します。

  genrule で一時的な中間ファイルを生成する必要がある場合（コンパイラなどの他のツールを使用した結果など）、@D に書き込み（/tmp にも書き込み可能）、終了する前に削除する必要があります。

  特に、入力を含むディレクトリへの書き込みは避けてください。読み取り専用のファイル システムにある可能性があります。そうでない場合でも、ソースツリーが破損します。

事前定義されたソース/出力パス変数

事前定義された変数 execpath、execpaths、 rootpath、rootpaths、location、および locations はラベル パラメータ（$(execpath //foo:bar) など）を受け取り、そのラベルで示されるファイルパスを置き換えます。

ソースファイルの場合、これはワークスペース ルートからの相対パスです。 ルールの出力であるファイルの場合、これはファイルの出力パス です（以下の出力ファイルの説明を参照）。

事前定義されたパス変数の例をご覧ください。

• execpath: Bazel がビルド アクションを実行する execroot の下のパスを示します。

  上記の例では、Bazel はワークスペース ルートの bazel-myproject シンボリック リンクでリンクされたディレクトリ内のすべてのビルド アクションを実行します。ソースファイル empty.source はパス bazel-myproject/testapp/empty.source にリンクされています。したがって、その実行パス（ルートの下のサブパス）は testapp/empty.source です。これは、ビルド アクションがファイルを見つけるために使用できるパスです。

  出力ファイルも同様にステージングされますが、サブパス bazel-out/cpu-compilation_mode/bin（またはツールの出力の場合は bazel-out/cpu-opt-exec-hash/bin）も接頭辞として付けられます。上記の例では、 //testapp:app は show_app_output's tools 属性に表示されるため、ツールです。したがって、その出力ファイル app は bazel-myproject/bazel-out/cpu-opt-exec-hash/bin/testapp/app に書き込まれます。 したがって、実行パスは bazel-out/cpu-opt-exec-hash/bin/testapp/app です。この追加の接頭辞 により、同じビルドで 2 つの異なる CPU に対して同じターゲットをビルドしても、結果が互いに上書きされることはありません。

  この変数に渡されるラベルは、1 つのファイルを表す必要があります。ソースファイルを表すラベルの場合、これは自動的に true になります。ルールを表すラベルの場合、ルールは 1 つの出力を生成する必要があります。これが false の場合、またはラベルの形式が正しくない場合、ビルドはエラーで失敗します。

• rootpath: ビルドされたバイナリが、メイン リポジトリに対応する runfiles ディレクトリのサブディレクトリを基準として、実行時に依存関係を見つけるために使用できるパスを示します。注: これは、 --enable_runfiles が有効になっている場合にのみ機能します。これは、デフォルトでは Windows では有効になっていません。クロスプラットフォーム サポートには、代わりに rlocationpath を使用してください。

  これは execpath に似ていますが、上記の設定接頭辞が削除されています。上記の例では、 empty.source と app の両方がワークスペース相対 パス testapp/empty.source と testapp/app を使用します。

  外部リポジトリ repo 内のファイルの rootpath は、../repo/ で始まり、その後に リポジトリ相対パスが続きます。

  これには、"出力は 1 つのみ" という要件が execpath と同じです。

• rlocationpath: ビルドされたバイナリが runfiles ライブラリの Rlocation 関数に渡して、実行時に依存関係を見つけることができるパス。runfiles ディレクトリ（使用可能な場合）または runfiles マニフェストを使用します。

  これは、rootpath に似ていますが、構成接頭辞が含まれていないという点で異なります。ただし、常にリポジトリの名前で始まる点が異なります。上記の例では、 empty.source と app は、次の パスになります: myproject/testapp/empty.source と myproject/testapp/app.

  外部リポジトリ repo 内のファイルの rlocationpath は、repo/ で始まり、その後に リポジトリ相対パスが続きます。

  このパスをバイナリに渡し、runfiles ライブラリを使用して ファイル システム パスに解決する方法は、実行時に依存関係を見つけるための 推奨される方法です。rootpath と比較して、すべてのプラットフォームで動作し、runfiles ディレクトリが使用できない場合でも動作するという利点があります。

  これには、"出力は 1 つのみ" という要件が execpath と同じです。

• location: 展開される属性に応じて、execpath または rootpath のシノニム。これは Starlark 以前の動作であり、特定のルールで何を行うかを理解していない限り、おすすめしません。詳細については、#2475 をご覧ください。

execpaths、rootpaths、rlocationpaths、 、locations は、それぞれ execpath、 、rootpath、rlocationpath、location、 の複数形です。複数の出力を生成するラベルをサポートしています。その場合、 各出力はスペースで区切ってリストされます。出力がゼロのルールと形式が正しくない ラベルは、ビルドエラーを生成します。

参照されるすべてのラベルは、使用するターゲットの srcs、 出力ファイル、または deps に表示される必要があります。そうしないと、ビルドは失敗します。C++ ターゲットは data のラベルを参照することもできます。

ラベルは正規フォームである必要はありません。foo、:foo および //somepkg:foo はすべて有効です。

カスタム変数

カスタムの "Make" 変数は、 "Make 変数の置換の対象"としてマークされた任意の属性で参照できますが、 これらの変数を 定義する他のターゲットに依存するターゲットでのみ参照できます。

ベスト プラクティスとして、Bazel のコアに組み込む正当な理由がない限り、すべての変数をカスタムにする必要があります。これにより、Bazel は、ターゲットが気にしない可能性のある変数を供給するために、負荷の高い依存関係を読み込む必要がなくなります。

C++ ツールチェーン変数

以下は C++ ツールチェーン ルールで定義され、 を設定する任意のルールで使用できます。toolchains = ["@bazel_tools//tools/cpp:current_cc_toolchain"] java_binary などの一部のルールでは、ルール定義に C++ ツールチェーンが暗黙的に 含まれています。これらの変数は自動的に継承されます。

組み込みの C++ ルールは、「コンパイラを実行する 」よりもはるかに高度です。複数のプラットフォームで高速に実行されるテストと同時に、*SAN、ThinLTO、 モジュールあり/なし、慎重に最適化されたバイナリなど、多様なコンパイル モードをサポートするために、組み込みルールでは、内部で生成される可能性のある複数のアクションごとに、正しい入力、出力、コマンドライン フラグが設定されるように最大限の努力が払われています。

これらの変数は、言語の専門家がまれに使用するフォールバック メカニズムです。 使用する場合は、まず Bazel デベロッパーにお問い合わせください。

• ABI: C++ ABI バージョン。
• AR: crosstool の「ar」コマンド。
• C_COMPILER: C/C++ コンパイラの識別子（llvm など）。

• CC: C コンパイラと C++ コンパイラのコマンド。

  常に CC と組み合わせて CC_FLAGS を使用することを強くおすすめします。そうしない場合は、自己責任で行ってください。

• CC_FLAGS: genrule で使用できる C/C++ コンパイラの最小限のフラグセット。特に、これは 正しいアーキテクチャを選択するためのフラグが含まれています。CC複数の アーキテクチャをサポートしている場合。
• DUMPBIN：Microsoft Visual Studio の Microsoft COFF Binary File Dumper（dumpbin.exe）。
• NM: crosstool の「nm」コマンド。
• OBJCOPY: C/C++ コンパイラと同じスイートの objcopy コマンド。
• STRIP: C/C++ コンパイラと同じスイートの strip コマンド。

Java ツールチェーン変数

以下は Java ツールチェーン ルールで定義され、 toolchains = ["@rules_java//toolchains:current_java_runtime"]（または "@rules_java//toolchains:current_host_java_runtime" ホスト ツールチェーン相当の場合）を設定する任意のルールで使用できます。

JDK のほとんどのツールは直接使用しないでください。組み込みの Java ルールでは、インターフェース Jar、ヘッダー インターフェース Jar、高度に最適化された Jar パッケージングとマージの実装など、アップストリーム ツールでは表現できない、はるかに高度な Java コンパイルとパッケージング のアプローチが使用されています。

これらの変数は、言語の専門家がまれに使用するフォールバック メカニズムです。 使用する場合は、まず Bazel デベロッパーにお問い合わせください。

• JAVA: 「java」コマンド（Java 仮想 マシン）。これは避けて、可能な場合は代わりに java_binary ルール を使用してください。相対パスの場合があります。`java` を呼び出す前にディレクトリを変更する必要がある場合は、変更する前に作業ディレクトリをキャプチャする必要があります。
• JAVABASE: Java ユーティリティを含むベース ディレクトリ。相対パスの場合があります。「bin」 サブディレクトリがあります。

Starlark で定義された変数

ルールとツールチェーンの作成者は、 完全にカスタムの変数を 定義できます。TemplateVariableInfo プロバイダを返すことで。` toolchains` 属性を介してこれらに依存するルールは、その値を読み取ることができます。

Starlark で定義された変数の例をご覧ください。