変数を作成する

問題を報告 ソースを表示 夜間 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

「つくる」変数は、展開可能な文字列変数の特殊なクラスで、 "Subject to 'Make variable'置換」というテキストを使用します。

たとえば、特定のツールチェーン パスを ビルド アクションを実行します。

Bazel では、すべての人が使用できる事前定義された変数が提供されています。 ターゲットとカスタム変数（依存関係ターゲットで定義） 依存するターゲットでのみ利用可能です。

「Make」という言葉を使う理由は、記述されています。つまり、Terraform の構文とセマンティクスが これらの変数はもともと、GNU Make。

使用

属性が「[変数の作成」の対象] とマークされています置換」を使用して、 「kubectl」コマンドを変数 FOO を次のように変更します。

my_attr = "prefix $(FOO) suffix"

つまり、$(FOO) に一致する部分文字列が展開されます。 FOO の値に設定されます。その値が "bar" の場合、 この文字列は、次のようになります。

my_attr = "prefix bar suffix"

FOO が使用側の既知の変数に対応していない場合 Bazel がエラーで失敗します。

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

my_attr = "prefix $@ suffix"

$ を文字列リテラルとして記述する（つまり、変数が 拡張）、$$ と記述します。

事前定義された変数

事前定義の「Make」変数は、 "Make variable" の対象置換する」

特定のビルドセットについて、これらの変数とその値のリストを表示する オプション、実行

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 が特別に利用できる機能は、以下のとおりです。 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: パスの下のパスを示します。 execroot Bazel はビルド アクションを実行します。

    上記の例では、Bazel は、リンク先のディレクトリにあるすべてのビルド アクションを実行します。 （ワークスペース ルートの bazel-myproject シンボリック リンク）で参照します。「 ソースファイル empty.source がパスでリンクされます。 bazel-myproject/testapp/empty.source。その exec パス（ ルートの下のサブパス）は 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。 したがって、exec パスは bazel-out/cpu-opt-exec-hash/bin/testapp/app になります。この追加の接頭辞は、 たとえば、2 つの異なる CPU に対して同じターゲットを 結果が相互に上書きされないようにします。

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

  • rootpath: ビルドされたバイナリが以下に使用できるパス 実行ファイルのサブディレクトリに対して相対的に、実行時に依存関係を検出する 対応するディレクトリに配置されます。 注: この方法は、 --enable_runfiles が有効になっているが、 デフォルトは Windows です。代わりに rlocationpath を使用する サポートしています。

    execpath に似ていますが、構成が削除されます。 使用できます。上の例では、これは両方の empty.source と app は純粋なワークスペース相対値を使用しています パス: testapp/empty.source と testapp/app。

    外部リポジトリ内のファイルの rootpath repo は ../repo/ で始まり、 リポジトリ相対パス。

    これは同じ「1 つの出力のみ」です。execpath として指定します。

  • rlocationpath: 依存関係を見つけるために、ビルドバイナリが runfiles ライブラリの Rlocation 関数に渡すパス runfiles ディレクトリにあるか（使用可能な場合）、 実行ファイル マニフェスト。

    次のものを含まないという点で、rootpath と似ています。 が、常に 1 文字目で始まり リポジトリの名前。上記の例では、 empty.source と app の結果は次のようになります。 パス: myproject/testapp/empty.source と myproject/testapp/app。

    外部リポジトリ内のファイルの rlocationpath repo は repo/ で始まり、 リポジトリ相対パス。

    このパスをバイナリに渡し、 依存関係を見つけるには、runfile ライブラリを使用することをおすすめします。 ランタイム。rootpath と比較すると、 すべてのプラットフォームで機能します。runfiles ディレクトリが できます。

    これは同じ「1 つの出力のみ」です。execpath として指定します。

  • location: execpath または rootpath。展開する属性によって異なります。これは、 Starlark 以前の動作です。よくわからない場合は、おすすめしません。 調整できます。#2475 を参照 をご覧ください。

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

参照されるすべてのラベルが使用ターゲットの srcs に含まれている必要があります。 出力ファイル、または deps です。それ以外の場合、ビルドは失敗します。C++ ターゲットは data のラベルも参照します。

ラベルを正規形式（foo、:foo）にする必要はありません。 //somepkg:foo で問題はありません。

カスタム変数

カスタムの「Make」変数は、 "Make variable" の対象"" という文字列を指定する必要があります。ただし、 その変数を定義している他のターゲットに依存します。

ベスト プラクティスとして、適切なものがない限り、すべての変数はカスタムにする それらをコア Bazel に組み込む理由です。これにより、Bazel がファイルを読み込む必要がなく taret を消費する変数を提供する場合、高コストがかかる 気にする必要はありません

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

以下は C++ ツールチェーン ルールで定義されており、どのルールでも使用可能です。 toolchains = ["@bazel_tools//tools/cpp:current_cc_toolchain"] を設定する 一部のルール（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: C/C++ のフラグの最小セット genrules で使用できるようにします。特に、これには次のフラグが含まれます。 CC が複数のアーキテクチャをサポートしている場合、正しいアーキテクチャを選択してください 構築できます
  • NM: 「nm」実行してみましょう
  • OBJCOPY: C/C++ と同じスイートの objcopy コマンド あります。
  • STRIP: C/C++ と同じスイートの strip コマンド あります。

Java ツールチェーン変数

以下は、Java ツールチェーン ルールで定義されており、どのルールでも使用可能です。 toolchains = ["@bazel_tools//tools/jdk:current_java_runtime"]（または "@bazel_tools//tools/jdk:current_host_java_runtime" を参照してください）。

JDK のほとんどのツールは直接使用すべきではありません。組み込みの Java より高度なアプローチを使用して Java のコンパイルとパッケージ化を行う インターフェース、JAR、ヘッダー、インターフェースなど JAR、高度に最適化された Jar のパッケージングと統合の実装。

これらの変数は、言語の専門家が使う代替メカニズムです。 まれに発生する場合があります。使用したいとお考えの場合は、まず Bazel 開発者に連絡してください。

  • JAVA: 「java」（Java Virtual Private Cloud（VPC） あります。これを回避し、java_binary ルールを使用する 推奨されます。相対パスを指定できます。変更が必要な場合 java を呼び出す前にディレクトリに保存したい場合は、 作業ディレクトリに保存されていることを確認してください。
  • JAVABASE: ファイルを含むベース ディレクトリ Java ユーティリティ。相対パスを指定できます。コンテナには「ビン」があります。 サブディレクトリに作成されます。

Starlark で定義された変数

ルールとツールチェーンのライターは、 完全なカスタム変数を TemplateVariableInfo 接続します。これらに依存するルールは、 これにより、toolchains 属性はその値を読み取ることができます。

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