行動
ビルド中に実行するコマンド。たとえば、アーティファクトを入力として受け取り、他のアーティファクトを出力として生成するコンパイラの呼び出しです。 コマンドライン引数、アクションキー、環境変数、宣言された入出力アーティファクトなどのメタデータが含まれます。
関連情報: ルールに関するドキュメント
アクション キャッシュ
実行されたアクションと作成した出力のマッピングを保存するディスク上のキャッシュ。このキャッシュキーはアクション キーと呼ばれます。Bazel のインクリメンタリティ モデルのコア コンポーネント。キャッシュは出力ベース ディレクトリに保存されるため、Bazel サーバーの再起動後も存続します。
アクション グラフ
アクションと、これらのアクションが読み取って生成するアーティファクトのメモリ内グラフ。グラフには、ソースファイルとして存在するアーティファクト(ファイル システム内など)や、BUILD
ファイルに記述されていない、生成された中間/最終アーティファクトが含まれる場合があります。分析フェーズで生成され、実行フェーズで使用されます。
アクション グラフ クエリ(aquery)
ビルドアクションに対してクエリを実行できるクエリツール。これにより、ビルドルールが実際の作業ビルドにどのように変換されるかを分析できます。
操作キー
アクションのキャッシュキー。アクション メタデータに基づいて計算されます。このメタデータには、アクションに応じて実行されるコマンド、コンパイラ フラグ、ライブラリの場所、またはシステム ヘッダーが含まれる場合があります。Bazel が、個々のアクションを確定的にキャッシュに保存または無効にできるようにします。
分析フェーズ
ビルドの 2 番目のフェーズ。BUILD
ファイルで指定されたターゲット グラフを処理して、メモリ内にアクション グラフを生成します。これにより、実行フェーズ中に実行するアクションの順序が決まります。このフェーズでは、ルールの実装が評価されます。
アーティファクト
ソースファイルまたは生成されたファイル。「ツリー アーティファクト」と呼ばれるファイルのディレクトリにすることもできます。
アーティファクトは複数のアクションに入力される可能性がありますが、生成できるアクションは 1 つまでです。
ファイル ターゲットに対応するアーティファクトはラベルでアドレス指定できます。
Aspect
依存関係内に追加のアクションを作成するためのルールのメカニズム。たとえば、ターゲット A が B に依存している場合、依存関係エッジを上から B にトラバースするアスペクトを A に適用し、B で追加のアクションを実行して追加の出力ファイルを生成して収集できます。これらの追加のアクションはキャッシュに保存され、同じアスペクトを必要とするターゲット間で再利用されます。aspect()
Starlark Build API 関数で作成します。たとえば、IDE 用のメタデータの生成や、lint チェック用のアクションの作成に使用できます。
関連情報: アスペクトに関するドキュメント
アスペクト比
アスペクトを他のアスペクトの結果に適用できる合成メカニズム。たとえば、IDE で使用する情報を生成するアスペクトは、proto から .java
ファイルを生成するアスペクトに適用できます。
アスペクト A
をアスペクト B
に適用するには、B
が provides
属性でアドバタイズするプロバイダが、A
がその required_aspect_providers
属性で宣言しているものと一致する必要があります。
属性
ルールのパラメータ。ターゲットごとのビルド情報を表現するために使用します。例として、srcs
、deps
、copts
があります。これらは、それぞれターゲットのソースファイル、依存関係、カスタム コンパイラ オプションを宣言します。特定のターゲットで使用できる属性は、ルールタイプによって異なります。
.bazelrc
Bazel の構成ファイル。起動フラグとコマンドフラグのデフォルト値の変更と、--config
フラグを使用して Bazel コマンドラインでまとめて設定できるオプションの共通のグループを定義します。Bazel は、複数の bazelrc ファイル(システム全体、ワークスペースごと、ユーザーごと、またはカスタムの場所)の設定を組み合わせることができます。また、bazelrc
ファイルは、他の bazelrc
ファイルから設定をインポートすることもできます。
Blaze
Bazel の Google 内部バージョン。モノリポジトリ用の Google の メインのビルドシステムです
BUILD ファイル
BUILD
ファイルは、ビルドするソフトウェア出力、その依存関係、ビルド方法を Bazel に指示するメインの構成ファイルです。Bazel は、BUILD
ファイルを入力として受け取り、そのファイルを使用して依存関係のグラフを作成し、中間および最終ソフトウェア出力のビルドに必要なアクションを導出します。BUILD
ファイルは、ディレクトリおよび BUILD
ファイルを含まないサブディレクトリをパッケージとしてマークし、rules によって作成されたターゲットを含むことができます。ファイル名を BUILD.bazel
にすることもできます。
BUILD.bazel ファイル
BUILD
ファイルをご覧ください。同じディレクトリ内の BUILD
ファイルよりも優先されます。
.bzl ファイル
Starlark で作成されたルール、マクロ、定数を定義するファイル。これらは、load()
関数を使用して BUILD
ファイルにインポートできます。
グラフの作成
Bazel がビルドして走査する依存関係グラフ。 ターゲット、構成済みターゲット、アクション、アーティファクトなどのノードが含まれます。リクエストされた一連のターゲットが依存するすべてのアーティファクトが最新であることが検証されると、ビルドは完了とみなされます。
ビルド設定
Starlark で定義された構成部分。遷移は、ビルド設定を指定してサブグラフの構成を変更できます。コマンドライン フラグ(ビルドフラグとも呼ばれます)としてユーザーに公開される場合。
クリーンビルド
以前のビルドの結果を使用しないビルド。一般的には増分ビルドよりも時間がかかりますが、一般的にはより正しいと考えられます。Bazel は、クリーンビルドと増分ビルドの両方が常に正しいことを保証します。
クライアント サーバー モデル
bazel
コマンドライン クライアントは、ローカルマシンでバックグラウンド サーバーを自動的に起動して、Bazel のコマンドを実行します。サーバーはコマンドをまたいで存続しますが、一定時間操作されないと自動的に停止します(または bazel のシャットダウンで明示的に停止します)。Bazel をサーバーとクライアントに分割すると、JVM の起動時間が短縮され、アクション グラフがコマンドをまたいでメモリに残るため、より高速な増分ビルドがサポートされます。
コマンド
コマンドラインで、bazel
build
、bazel test
、bazel run
、bazel query
などのさまざまな Bazel 関数を呼び出すために使用されます。
コマンドフラグ
コマンドに固有の一連のフラグ。コマンドフラグは、コマンド(bazel build <command flags>
)の後で指定します。フラグは 1 つ以上のコマンドに適用できます。たとえば、--configure
は bazel sync
コマンド専用のフラグですが、--keep_going
は sync
、build
、test
などに適用されます。フラグは構成の目的でよく使用されます。そのため、フラグ値が変更されると、Bazel がメモリ内グラフを無効にし、分析フェーズが再開されることがあります。
設定
ルールによるアクションの生成方法に影響する、ルール定義に含まれない情報。すべてのビルドには、ターゲット プラットフォーム、アクション環境変数、コマンドライン ビルドフラグを指定する構成が 1 つ以上あります。遷移により、ホストツールやクロスコンパイルなど、追加の構成が作成されることがあります。
関連情報: 構成
構成のトリミング
ターゲットが実際に必要とする構成の一部のみを含めるプロセス。たとえば、C++ 依存関係 //:c
を使用して Java バイナリ //:j
をビルドする場合、--javacopt
を変更すると、C++ ビルドのキャッシュ可能性が不必要に失われるため、--javacopt
の値を //:c
の構成に含めると無駄になります。
構成済みのクエリ(cquery)
構成されたターゲットをクエリするクエリツール(分析フェーズの完了後)。つまり、select()
とビルドフラグ(--platforms
など)が正確に結果に反映されています。
関連情報: cquery のドキュメント
構成済みのターゲット
構成を使用してターゲットを評価した結果。分析フェーズでは、ビルドのオプションとビルドが必要なターゲットを組み合わせて生成します。たとえば、//:foo
が同じビルド内の 2 つの異なるアーキテクチャ用にビルドする場合、2 つのターゲット(<//:foo, x86>
と <//:foo, arm>
)が構成されています。
正確性
ビルドがその出力に推移的な入力の状態を忠実に反映していれば、ビルドは正しいと言えます。正しいビルドを実現するために、Bazel では密閉型で再現性のあること、ビルドの分析とアクション実行の決定性を実現するよう努めています。
Dependency
2 つのターゲット間の有向エッジ。//:foo
の属性値に //:bar
への参照が含まれている場合、ターゲット //:foo
は、ターゲット //:bar
に対するターゲット依存関係を持ちます。//:foo
のアクションが //:bar
のアクションによって作成された入力アーティファクトに依存している場合、//:foo
は //:bar
に対するアクションの依存関係を持ちます。
文脈によっては、外部依存関係を指す場合もあります。モジュールをご覧ください。
依存関係
推移的依存関係に関するデータを収集するためのデータ構造。依存関係のマージが時間とスペースを効率的に行えるように最適化されています。これは、非常に大きなデプセット(数十万のファイル)が存在することが一般的であるためです。スペース効率上の理由から他の依存関係を再帰的に参照するように実装されています。ルールの実装では、ルールがビルドグラフのトップレベルにある場合を除き、デプセットをリストに変換して「フラット化」しないでください。大きなデプセットをフラット化すると、メモリを大量に消費することになります。Bazel の内部実装では「ネストされたセット」とも呼ばれます。
関連情報: 依存関係のドキュメント
ディスク キャッシュ
リモート キャッシュ機能用のローカルのディスク上の blob ストア。実際のリモート blob ストアと組み合わせて使用できます。
ディストリビューション
リポジトリ ルールを使用して Bazel がインターネットから取得するファイルを含む、読み取り専用ディレクトリ。ビルドを完全にオフラインで実行できます。
動的な実行
さまざまなヒューリスティックに基づいてローカル実行かリモート実行かを選択し、より速く成功したメソッドの実行結果を使用する実行戦略。アクションには、ローカルで実行されるアクション(リンクなど)とリモートで実行されるアクション(並列化可能なコンパイルなど)があります。動的実行戦略により、増分ビルドとクリーン ビルド時間を可能な限り最大化できます。
実施フェーズ
ビルドの 3 番目のフェーズ。分析フェーズで作成されたアクション グラフのアクションを実行します。これらのアクションは実行可能ファイル(コンパイラ、スクリプト)を呼び出して、アーティファクトを読み書きします。スポーン戦略は、これらのアクションの実行方法(ローカル、リモート、動的、サンドボックス化、Docker など)を制御します。
実行ルート
ワークスペースの出力ベース ディレクトリ内のディレクトリで、ローカルのアクションがサンドボックス化されていないビルドで実行されます。ディレクトリの内容のほとんどは、ワークスペースからの入力アーティファクトのシンボリック リンクです。実行ルートには、他の入力として外部リポジトリへのシンボリック リンクや、出力を保存する bazel-out
ディレクトリも含まれます。読み込みフェーズ中に、ビルドが依存するパッケージの推移的クローズを表すディレクトリのシンボリック リンク フォレストを作成することで準備されます。コマンドラインの bazel info
execution_root
でアクセスできます。
ファイル
アーティファクトをご覧ください。
密閉性
ビルドとテスト オペレーションに外部の影響がない場合、ビルドは密閉型であるため、結果を確定的かつ正しいものにできます。たとえば、密閉型のビルドは通常、アクションへのネットワーク アクセスを禁止し、宣言された入力へのアクセスを制限し、固定のタイムスタンプとタイムゾーンを使用します。また、環境変数へのアクセスを制限し、乱数ジェネレータに固定シードを使用します。
増分ビルド
増分ビルドでは、以前のビルドの結果を再利用して、ビルド時間とリソース使用量を削減します。依存関係のチェックとキャッシュは、このタイプのビルドで正しい結果を生成することを目的としています。増分ビルドは、クリーンビルドの逆です。
ラベル
ターゲットの識別子。一般的な形式は @repo//path/to/package:target
です。ここで、repo
はターゲットを含むリポジトリの(明確な)名前、path/to/package
はターゲットを宣言している BUILD
ファイルを含むディレクトリへのパス(このディレクトリはパッケージとも呼ばれます)、target
はターゲット自体の名前です。状況によっては、この構文の一部が省略される場合があります。
関連情報: ラベル
読み込みフェーズ
ビルドの最初のフェーズで、Bazel が BUILD
ファイルを実行してパッケージを作成します。このフェーズでは、マクロと特定の関数(glob()
など)が評価されます。ビルドの 2 番目のフェーズである分析フェーズとインターリーブされ、ターゲット グラフを構築します。
マクロ
複数のルールのターゲット宣言を 1 つの Starlark 関数の下にまとめるメカニズム。BUILD
ファイル間で共通のルール宣言パターンを再利用できるようにします。読み込みフェーズでの、基盤となるルール ターゲットの宣言まで展開しました。
関連情報: マクロに関するドキュメント
ニーモニック
ルール作成者が選択する、人が読める形式の短い文字列。ルール内のアクションの内容をすばやく把握できます。ニーモニックは、生成戦略の選択の識別子として使用できます。アクション ニーモニックの例としては、Java ルールの Javac
、C++ ルールの CppCompile
、Android ルールの AndroidManifestMerger
などがあります。
モジュール
複数のバージョンを持つことができる Bazel プロジェクト。各バージョンには、他のモジュールへの依存関係を含めることができます。これは、Maven アーティファクト、npm パッケージ、Go モジュール、Cargo クレートなど、他の依存関係管理システムで馴染みのあるコンセプトに似ています。モジュールは、Bazel の外部依存関係管理システムのバックボーンを形成します。
各モジュールは、ルートに MODULE.bazel
ファイルを持つリポジトリによって支えられています。このファイルには、モジュール自体に関するメタデータ(名前やバージョンなど)、その直接的な依存関係のほか、ツールチェーンの登録やモジュール拡張機能の入力など、さまざまなデータが格納されます。
モジュール メタデータは、Bazel レジストリでホストされます。
関連情報: Bazel モジュール
モジュール拡張
モジュールの依存関係グラフ全体から入力を読み取り、リポジトリルールを呼び出すことで、repos を生成するために実行できるロジックの一部。モジュール拡張機能にはリポジトリ ルールに似た機能があり、インターネットへのアクセス、ファイル I/O の実行などを行うことができます。
関連情報: モジュール拡張
ネイティブ ルール
Bazel に組み込まれ、Java で実装されるルール。このようなルールは、ネイティブ モジュール(native.cc_library
や native.java_library
など)内の関数として .bzl
ファイルに表示されます。ユーザー定義ルール(非ネイティブ)は、Starlark を使用して作成されます。
出力ベース
Bazel 出力ファイルを格納するワークスペース固有のディレクトリ。ワークスペースのソースツリー(メイン リポジトリ)から出力を分離するために使用されます。出力ユーザーのルートにあります。
出力グループ
Bazel がターゲットのビルドを完了したときにビルドが想定されるファイルのグループです。ルールにより、通常の出力は「デフォルト出力グループ」に配置されます(例: cc_library
ターゲットの java_library
、.a
、.so
の .jar
ファイル)。デフォルトの出力グループは、コマンドラインでターゲットがリクエストされたときにアーティファクトがビルドされる出力グループです。ルールでは、BUILD
ファイル(filegroup
ルール)またはコマンドライン(--output_groups
フラグ)で明示的に指定できる、さらに名前付きの出力グループを定義できます。
出力ユーザーのルート
Bazel の出力を保存するユーザー固有のディレクトリ。ディレクトリ名は、ユーザーのシステム ユーザー名から取得されます。複数のユーザーがシステム上で同じプロジェクトを同時に作成する場合に、出力ファイルの競合を回避します。個々のワークスペースのビルド出力に対応するサブディレクトリ(出力ベースとも呼ばれます)が含まれています。
パッケージ
BUILD
ファイルで定義されたターゲットのセット。パッケージの名前は、repo ルートからの BUILD
ファイルのパスです。パッケージには、サブパッケージまたは BUILD
ファイルを含むサブディレクトリを含めることができます。これにより、パッケージ階層を形成できます。
パッケージ グループ
パッケージのセットを表すターゲット。多くの場合、visibility
属性値で使用されます。
プラットフォーム
ビルドに関係する「マシンタイプ」。これには、Bazel が実行されるマシン(「ホスト」プラットフォーム)、ビルドツールが実行されるマシン(「実行可能ファイル」プラットフォーム)、ターゲットがビルドされるマシン(「ターゲット プラットフォーム」)が含まれます。
提供元
依存関係に沿ってルール ターゲット間で受け渡す情報の単位を記述するスキーマ。通常、コンパイラ オプション、推移的なソースファイル、出力ファイル、ビルド メタデータなどの情報が含まれます。蓄積された推移データを効率的に保存するために、depset と頻繁に併用します。組み込みプロバイダの例としては、DefaultInfo
があります。
関連情報: プロバイダのドキュメント
クエリ(コンセプト)
ビルドグラフを分析して、ターゲット プロパティと依存関係構造を理解するプロセス。Bazel では、query、cquery、aquery の 3 つのクエリ バリアントをサポートしています。
query(コマンド)
ビルドの読み込み後のフェーズのターゲット グラフで動作するクエリツール。これは比較的高速ですが、select()
、ビルドフラグ、アーティファクト、ビルドアクションの影響を分析することはできません。
関連項目: クエリの使い方、クエリ リファレンス
リポジトリ
ルートに境界マーカー ファイルがあるディレクトリ ツリー。Bazel ビルドで使用できるソースファイルが含まれています。多くの場合、「リポジトリ」と短縮されます。
リポジトリの境界マーカー ファイルは、MODULE.bazel
(このリポジトリが Bazel モジュールを表すことを示す)、REPO.bazel
、レガシー コンテキストでは WORKSPACE
または WORKSPACE.bazel
になります。リポジトリの境界マーカー ファイルは、どれもリポジトリの境界を示します。このようなファイルは、1 つのディレクトリに複数存在できます。
メイン リポジトリは、現在の Bazel コマンドが実行されているリポジトリです。
外部リポジトリを定義するには、MODULE.bazel
ファイルでモジュールを指定するか、モジュール拡張機能でリポジトリを呼び出します。これらは、ディスク上のあらかじめ決められた「魔法の」場所にオンデマンドでフェッチできます。
各リポジトリには一意で定数の正規名があります。他のリポジトリから見たときには異なる名前が付いています。
参照: 外部依存関係の概要
リポジトリ キャッシュ
ビルド用に Bazel によってダウンロードされた、ワークスペース間で共有可能な、コンテンツのアドレス指定が可能な共有キャッシュ。最初のダウンロード後にオフライン ビルドを有効にします。一般に、http_archive
などのリポジトリ ルールと、repository_ctx.download
などのリポジトリ ルール API でダウンロードしたファイルをキャッシュに保存するために使用します。ファイルがキャッシュに保存されるのは、ダウンロードに SHA-256 チェックサムが指定されている場合のみです。
リポジトリ ルール
リポジトリを実体化(「フェッチ」)する方法を Bazel に指示するリポジトリ定義のスキーマ。多くの場合、単に「リポルール」と短縮されます。Repo ルールは、モジュールに基づくリポジトリを定義するために Bazel によって内部的に呼び出されます。また、モジュール拡張機能によって呼び出すこともできます。Repo ルールはインターネットへのアクセスやファイル I/O の実行が可能です。最も一般的なリポジトリ ルールは、インターネットからソースファイルを含むアーカイブをダウンロードする http_archive
です。
関連情報: Repo ルールのドキュメント
再現性
ビルドまたはテストに対する一連の入力が、時間、メソッド、環境に関係なく、常に同じ出力セットを生成するというビルドまたはテストのプロパティ。これは必ずしも正しい出力または望ましい出力であることを意味しません。
ルール
BUILD
ファイルでルール ターゲットを定義するスキーマ(cc_library
など)。BUILD
ファイルの作成者から見ると、ルールは一連の属性とブラック ボックス ロジックで構成されます。このロジックは、出力アーティファクトを生成する方法と、他のルール ターゲットに情報を渡す方法をルール ターゲットに指示します。.bzl
作成者の観点からは、新しいプログラミング言語と環境をサポートするために Bazel を拡張する基本的な方法として、ルールがあります。
ルールは、読み込みフェーズでルール ターゲットを生成するためにインスタンス化されます。分析フェーズでは、ルール ターゲットはプロバイダという形でダウンストリームの依存関係に情報を伝達し、出力アーティファクトの生成方法を説明するアクションを登録します。これらのアクションは、実行フェーズで実行されます。
関連情報: ルールに関するドキュメント
ルールの対象
ターゲット。これはルールのインスタンスです。ファイル ターゲットやパッケージ グループとは対照的です。rule と混同しないでください。
実行ファイル
実行可能なターゲットのランタイム依存関係。ほとんどの場合、実行可能ファイルはテストルールの実行可能出力で、runfile はテストのランタイム データ依存関係です。Bazel は、実行可能ファイルを呼び出す前に(bazel テスト)、ソース ディレクトリ構造に従ってテスト実行ファイルとともに runfile のツリーを準備します。
関連情報: Runfile のドキュメント
サンドボックス化
制限付きの一時的な実行ルート内で実行中のアクションを分離する手法。宣言されていない入力を読み取ったり、宣言されていない出力を書き込んだりしないようにします。サンドボックス化により密閉性は大幅に向上しますが、通常はパフォーマンス コストがかかるため、オペレーティング システムからのサポートが必要になります。パフォーマンス コストはプラットフォームによって異なります。これは Linux では重要ではありませんが、macOS ではサンドボックスが使用できなくなる場合があります。
スカイフレーム
Skyframe は Bazel のコアとなる並列評価、機能、増分評価のフレームワークです。
スタンピング
Bazel でビルドされたアーティファクトに追加情報を埋め込む機能。たとえば、リリースビルドのソース管理、ビルド時間、その他のワークスペースや環境関連の情報に使用できます。
--workspace_status_command
フラグと、stamp 属性をサポートするルールを使用して有効にします。
スターラーク
ルールとマクロを記述するための拡張言語。Python の(構文的、文法的に)制限されたサブセットは、構成とパフォーマンス向上を目的としています。.bzl
ファイル拡張子を使用します。BUILD
ファイルは、Starlark のさらに制限されたバージョンを使用します(def
関数の定義がないなど)。たとえば、以前の Skylark です。
関連情報: Starlark 言語のドキュメント
起動フラグ
bazel
とコマンドの間で指定されたフラグのセット(bazel --host_jvm_debug
ビルドなど)。これらのフラグは Bazel サーバーの構成を変更するため、起動フラグを変更するとサーバーが再起動します。起動フラグは特定のコマンドに固有のものではありません。
Target
BUILD
ファイルで定義され、ラベルで識別されるオブジェクト。ターゲットは、エンドユーザーから見たワークスペースのビルド可能単位を表します。
ルールをインスタンス化することによって宣言されるターゲットは、ルール ターゲットと呼ばれます。これらは、ルールに応じて、実行可能(cc_binary
など)またはテスト可能(cc_test
など)になります。ルール ターゲットは通常、属性(deps
など)を介して他のターゲットに依存します。これらの依存関係はターゲット グラフの基礎を形成します。
ルール ターゲットのほかに、ファイル ターゲットとパッケージ グループ ターゲットもあります。ファイル ターゲットは、BUILD
ファイル内で参照されるアーティファクトに対応します。特殊なケースとして、パッケージの BUILD
ファイルは、常にそのパッケージ内のソースファイル ターゲットとみなされます。
ターゲットは読み込みフェーズで検出されます。分析フェーズでは、ターゲットがビルド構成に関連付けられ、構成済みのターゲットが形成されます。
ターゲット グラフ
ターゲットとその依存関係のメモリ内グラフ。読み込みフェーズで生成され、分析フェーズへの入力として使用されます。
ターゲット パターン
コマンドラインでターゲットのグループを指定する方法。よく使用されるパターンは、:all
(すべてのルール ターゲット)、:*
(すべてのルール + ファイル ターゲット)、...
(現在のパッケージとすべてのサブパッケージを再帰的に)です。組み合わせて使用できます。たとえば、//...:*
は、ワークスペースのルートから再帰的にすべてのパッケージ内のすべてのルールとファイル ターゲットを意味します。
テスト
テストルールからインスタンス化されたルールターゲットであるため、テスト実行可能ファイルが含まれています。実行ファイルの完了後の戻りコードがゼロの場合、テストが成功したことを示します。Bazel とテスト(テスト環境変数、テスト結果の収集方法など)の正確なコントラクトは、テスト百科事典に記載されています。
ツールチェーン
特定の言語の出力を作成するためのツールセット。通常、ツールチェーンには、コンパイラ、リンカー、インタープリタ、リンターが含まれます。ツールチェーンはプラットフォームによって異なる場合があります。つまり、ツールチェーンが同じ言語用であっても、Unix コンパイラ ツールチェーンのコンポーネントは Windows バリアントによって異なる場合があります。プラットフォームに適したツールチェーンを選択することを「ツールチェーン解決」といいます。
最上位のターゲット
ビルド ターゲットは、Bazel コマンドラインでリクエストされた場合、トップレベルです。たとえば、//:foo
が //:bar
に依存し、bazel build //:foo
が呼び出された場合、このビルドでは //:foo
がトップレベルになり、//:bar
はトップレベルではありませんが、両方のターゲットをビルドする必要があります。トップレベル ターゲットと非トップレベル ターゲットの重要な違いは、Bazel コマンドライン(または .bazelrc 経由)で設定されたコマンドフラグは、トップレベル ターゲットの構成を設定しますが、非トップレベル ターゲットの遷移によって変更される可能性があることです。
移行
ある値から別の値への構成状態のマッピング。ビルドグラフ内のターゲットは、同じルールからインスタンス化された場合でも、異なる構成を持つことができます。遷移の一般的な用途は、スプリット遷移です。ターゲット グラフの特定の部分が、フォークごとに異なる構成でフォークされます。たとえば、1 つのビルドで分割遷移を使用して、ARM 用と x86 用にコンパイルされたネイティブ バイナリを含む Android APK をビルドできます。
関連情報: ユーザー定義の移行
ツリー アーティファクト
ファイルのコレクションを表すアーティファクト。これらのファイルはアーティファクトではないため、これらを操作するアクションは、代わりにツリー アーティファクトを入力または出力として登録する必要があります。
公開設定
ビルドシステムでの不要な依存関係を防ぐための 2 つのメカニズムのうちの一つです。1 つは、ターゲットが他のターゲットに依存できるかどうかを制御するターゲットの可視性です。もう 1 つは、BUILD
または .bzl
ファイルが特定の .bzl
ファイルを読み込むことができるかどうかを制御するロードの可視性です。コンテキストがなければ、通常「可視性」はターゲットの公開設定を意味します。
関連情報: 可視性に関するドキュメント
ワークスペース
すべての Bazel コマンドで共有される環境は、同じメイン リポジトリから実行されます。
歴史的には「リポジトリ」と「ワークスペース」のコンセプトは混同されてきました。「ワークスペース」という用語はメイン リポジトリを指す場合が多く、「リポジトリ」の同義語として使用されることもよくあります。わかりやすくするために、このような使用は避けてください。