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