変数を作成する

mapfile SRCS <<< "$$(sed -e 's/ /\\n/g' <<'genrule_srcs_expansion'
$(SRC)
genrule_srcs_expansion
) を書き込んでから、後続のコマンドラインで $(SRCS) の代わりに "$$\{SRCS[@]}" を使用します。より堅牢なオプションは、代わりに Starlark ルールを記述することです。



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

  事前定義された変数 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 の 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/ で始まり、その後にリポジトリ相対パスが続きます。
    

      これは、execpath と同じ「出力は 1 つのみ」という要件を満たしています。
  

  

    

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

      これは rootpath と同様に構成接頭辞を含みませんが、常にリポジトリの名前で始まる点が異なります。上記の例では、
      empty.source と app は myproject/testapp/empty.source と 
      myproject/testapp/app のパスになります。
    

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

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

      これは、execpath と同じ「出力は 1 つのみ」という要件を満たしています。
  

  

    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:toolchain_type"] を設定するルールで使用できます。java_binary などの一部のルールでは、ルール定義に C++ ツールチェーンが暗黙的に含まれています。これらの変数は自動的に継承されます。


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


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


  
ABI: C++ ABI バージョン。

  
 AR: クロスツールの「ar」コマンド。
  
 C_COMPILER:
    C/C++ コンパイラの識別子（例: llvm）。
  
  

    
CC: C および C++ コンパイラ コマンド。
    

      CC_FLAGS は常に CC と組み合わせて使用することを強くおすすめします。そうしないと、ご自身の責任で操作することになります。
  
  
CC_FLAGS: genrule で使用可能な C/C++ コンパイラの最小限のフラグセット。特に、CC が複数のアーキテクチャをサポートしている場合に、正しいアーキテクチャを選択するためのフラグが含まれています。


  
 DUMPBIN: Microsoft Visual Studio の Microsoft COFF バイナリ ファイル ダンプツール（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 で定義された変数の例をご覧ください。