BazelCon 2024 登録の受け付けを開始しました。

このページは Cloud Translation API によって翻訳されました。

Bazel コードベース

<ph type="x-smartling-placeholder"></ph> 問題を報告するソースを表示夜間 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

このドキュメントでは、コードベースと Bazel の構造について説明します。これは、は、エンドユーザー向けではなく、Bazel への貢献に積極的なユーザーを対象としています。

はじめに

Bazel のコードベースは大規模（約 350 KLOC の本番環境コードと約 260 KLOC のテスト）この環境全体に精通している人はいません。谷合の情報を知っている人はほとんどいませんが、方向です。

旅の途中で出会うことがないように、単純な道が失われて暗くなっている場合に、この文書は簡単に使い始められるように、コードベースの概要を説明します。あります。

Bazel のソースコードの公開バージョンは GitHub github.com/bazelbuild/bazelこれは、「信頼できる情報源」。Google 内部のソースツリーから取得され、 Google 以外では役に立たない追加機能が含まれている。「長期的な目標は GitHub を信頼できる情報源にすることです

コントリビューションは、通常の GitHub pull リクエストメカニズムを通じて受け付けられます。 Google 社員が手動で内部ソースツリーにインポートした後、 GitHub に再エクスポートされます

クライアント/サーバーアーキテクチャ

Bazel の大部分は、ビルド間で RAM にとどまるサーバープロセスに存在します。これにより、Bazel はビルド間で状態を維持できます。

そのため、Bazel コマンドラインには起動と起動の 2 種類のオプションがあります。使用できます。コマンドラインでは次のようになります。

    bazel --host_jvm_args=-Xmx8G build -c opt //foo:bar

一部のオプション（--host_jvm_args=）は、実行するコマンドの名前の前にあります一部は（-c opt）より後です。「スタートアップオプション」と呼ばれるものです。およびコマンドはサーバープロセス全体に影響しますが、後者の場合、 1 つのコマンドにのみ影響します。

各サーバーインスタンスには単一のソースツリー（「ワークスペース」）が関連付けられており、アクティブなサーバーインスタンスが 1 つ存在します。これは回避できますカスタムの出力ベースを指定できます（詳細については、「ディレクトリレイアウト」セクションをご覧ください）。情報）が含まれます。

Bazel は、有効な .zip ファイルである単一の ELF 実行可能ファイルとして配布されます。「bazel」と入力すると、上記の ELF 実行可能ファイルが C++（「クライアント」）が制御を取得します。このコマンドを使用して、適切なサーバープロセスをセットアップします。手順は次のとおりです。

すでに自身を抽出しているかどうかを確認します。そうでない場合は、それが実行されます。このサーバーの実装元です
正常に動作するアクティブなサーバーインスタンスがあるかどうかを確認します。実行中のサーバーインスタンス、適切な起動オプションが設定され、適切なワークスペースディレクトリが使用されています。これは、 $OUTPUT_BASE/server ディレクトリを参照して実行中のサーバーを見つけます。サーバーがリッスンしているポートを含むロックファイルがあります。
必要に応じて、古いサーバープロセスを強制終了する
必要に応じて、新しいサーバープロセスを起動する

適切なサーバープロセスの準備ができたら、次のコマンドを実行する必要があります。 gRPC インターフェースを介して通信されると、Bazel の出力がパイプで返されます。送信します。同時に実行できるコマンドは 1 つのみです。これは、 C++ の部分と 2 つの部分からなる Java です。複数のコマンドを並行して実行するためのインフラストラクチャが存在しますが、 bazel version を別のコマンドと並行して実行できないため、厄介な問題です主な阻害要因は BlazeModule のライフサイクルです。 BlazeRuntime の状態などです。

コマンドの最後に、Bazel サーバーは終了コードをクライアントに送信します。返されます。興味深いのは bazel run の実装です。このコマンドのジョブは、Bazel でビルドしたものを実行することですが、実行できませんサーバープロセスから分離します。その代わりに、どのバイナリとどの引数を使用してujexec()するかをクライアントに提供します。

Ctrl+C を押すと、クライアントによって gRPC の Cancel 呼び出しに変換されます。コマンドをできるだけ早く終了しようとします。 3 回目の Ctrl+C キーを押すと、クライアントは SIGKILL をサーバーに送信します。

クライアントのソースコードは src/main/cpp にあり、使用するプロトコルはサーバーとの通信は src/main/protobuf/command_server.proto にあります。

サーバーの主なエントリポイントは BlazeRuntime.main() で、gRPC 呼び出し（クライアントからの）は GrpcServerImpl.run() によって処理されます。

ディレクトリレイアウト

Bazel は、ビルド中にやや複雑なディレクトリセットを作成します。フル説明が出力ディレクトリレイアウトに記載されています。

「ワークスペース」Bazel が実行されるソースツリーです。通常はチェックした項目です

Bazel では、すべてのデータが「出力ユーザールート」に置かれます。これは通常 $HOME/.cache/bazel/_bazel_${USER}。ただし、次のコマンドを使用してオーバーライドできます。 --output_user_root 起動オプション。

「インストールベース」Bazel を抽出する場所です。これは自動的に行われます Bazel の各バージョンは、チェックサムに基づいてサブディレクトリをインストールベースデフォルトは $OUTPUT_USER_ROOT/install で、変更できます --install_base コマンドラインオプションを使用します。

出力ベース特定のインスタンスにアタッチされた Bazel インスタンスが表示されます。各出力ベースに含まれる Bazel サーバーインスタンスは 1 つだけですいつでも実行できます。いつもは $OUTPUT_USER_ROOT/<checksum of the path to the workspace> です。これは、--output_base 起動オプションを使用して変更できます。これは、特に、特定の組織やフォルダにのみ存在するどのワークスペースでも同時に 1 つの Bazel インスタンスを実行できます。

出力ディレクトリには、特に次のものが含まれます。

$OUTPUT_BASE/external で取得された外部リポジトリ。
実行ルート（すべてのソースへのシンボリックリンクを含むディレクトリ）確認できます。$OUTPUT_BASE/execroot にあります。イベント中ビルドの場合、作業ディレクトリは $EXECROOT/<name of main repository> です。現在は $EXECROOT に変更される予定ですが、現在、互換性のない変更だからです。
ビルド中にビルドされたファイル。

コマンドを実行するプロセス

Bazel サーバーが制御を取得し、コマンドに関する通知を受け取ったら、以下を実行します。実行すると、次の一連のイベントが発生します。

BlazeCommandDispatcher に新しいリクエストが通知されます。判断コマンドの実行に必要なワークスペースが必要かどうか（ソースコードとは関係のないものについては、 help など）、別のコマンドが実行中かどうかを確認します。
正しいコマンドが見つかりました。各コマンドでインターフェースを実装する必要がある BlazeCommand。@Command アノテーションを付ける必要があります（これは少しコマンドに必要なメタデータがすべて BlazeCommand のメソッドで記述）
コマンドラインオプションが解析されます。各コマンドには、それぞれ異なるコマンドラインオプション。@Command アノテーションに記述されています。
イベントバスが作成されます。イベントバスは、発生したイベントのストリームおすすめします。その一部は、ビルドがどのように行われるかを世界に伝えるために、できます。
コマンドが制御を取得します。最も興味深いコマンドは、ビルド、テスト、実行、カバレッジなど、 BuildTool によって実装される。
コマンドラインのターゲットパターンのセットが解析され、 //pkg:all と //pkg/... が解決されました。これは AnalysisPhaseRunner.evaluateTargetPatterns()し、Skyframe で次のように具体化しました TargetPatternPhaseValue。
読み込み/分析フェーズでは、アクショングラフ（有向ビルドで実行する必要があるコマンドの非巡回グラフなど）。
実行フェーズが実行されます。つまり、必要なすべてのアクションをビルドされたトップレベルターゲットが実行されます。

コマンドラインオプション

Bazel 呼び出しのコマンドラインオプションについては、 OptionsParsingResult オブジェクトが返され、このオブジェクトには「option」からのマップが含まれます。クラス」オプションの値にマッピングされます。「オプションクラス」のサブクラスである OptionsBase: それぞれに関連するコマンドラインオプションをグループ化します。あります。例:

プログラミング言語に関連するオプション（CppOptions または JavaOptions）。これらは FragmentOptions のサブクラスである必要があり、最終的に BuildOptions オブジェクトに変換します。
Bazel によるアクションの実行方法に関連するオプション（ExecutionOptions）

これらのオプションは、分析フェーズで使用するように設計されており、 Java では RuleContext.getFragment()、Starlark では ctx.fragments）。一部（C++ スキャンを含むかどうかなど）は、読み取られます。ただし、そのためには常に明示的なプラミングが必要になります。その日は BuildConfiguration はご利用になれません。詳しくは、 [構成]セクションに進みましょう

警告: ここでは、OptionsBase インスタンスは不変であり、そのように使用する必要があります（SkyKeys の一部など）。これは違います。変更することは、難しい方法で Bazel を壊すための良い方法です。デバッグします。残念なことに、これらを実際に不変にするのは多大な労力を要します。（コンストラクションの直後に他の誰よりも早く FragmentOptions を変更する） equals() または hashCode() が作成される前に、そのオブジェクトへの参照を保持します。呼び出すことは問題ありません）。

Bazel は、次の方法でオプションクラスを学習します。

Bazel に組み込まれているものもあります（CommonCommandOptions）
各 Bazel コマンドの @Command アノテーションから
ConfiguredRuleClassProvider から（これらは関連するコマンドラインオプションです）個々のプログラミング言語）
Starlark のルールでは、独自のオプションを定義することもできます（こちら）

各オプション（Starlark で定義されたオプションを除く）は、 @Option アノテーションを持つ FragmentOptions サブクラス。このサブクラスは、コマンドラインオプションの名前とタイプ、そしてヘルプテキストです。

コマンドラインオプションの値の Java の型は通常、単純なものです。（文字列、整数、ブール値、ラベルなど）。またより複雑なタイプのオプション今回の例では、コマンドライン文字列のデータ型は、 com.google.devtools.common.options.Converter。

Bazel で表示されたソースツリー

Bazel はソフトウェアの構築に使用されています。ソフトウェアの構築は、見ていきます。Bazel が動作するソースコード全体「ワークスペース」と呼びます。リポジトリ、パッケージ、リソースという構成でできます。

リポジトリ

「リポジトリ」開発者が作業するソースツリーです。通常は 1 つのプロジェクトを表します。Bazel の祖先である Blaze は monorepo で実行されていました。つまり、ビルドの実行に使用されるすべてのソースコードを含む単一のソースツリーです。一方、Bazel は、ソースコードが複数のプロジェクトにまたがってできます。Bazel が呼び出されるリポジトリは「メイン」その他は「外部リポジトリ」と呼ばれます。

リポジトリは、WORKSPACE（または WORKSPACE.bazel）というファイルでマークされています。ルートディレクトリに配置されます。このファイルには「グローバル」の情報が含まれています。全体たとえば、使用可能な一連の外部リポジトリをビルドします。これは、通常の Starlark ファイル。つまり、他の Starlark ファイルを load() できます。これは、リポジトリが必要とするリポジトリを pull するためによく使用されます。明示的に参照される（これを「deps.bzl パターン」と呼びます）

外部リポジトリのコードはシンボリックリンクされているか、 $OUTPUT_BASE/external。

ビルドを実行するときは、ソースツリー全体をつなぎ合わせる必要があります。メインリポジトリ内のすべてのパッケージをシンボリックリンクする SymlinkForest によって行われます。すべての外部リポジトリを $EXECROOT/external または$EXECROOT $EXECROOT/..（もちろん、前者はパッケージをメインリポジトリにある external。そのため Google Cloud の。

パッケージ

すべてのリポジトリは、パッケージ、関連ファイルのコレクション、依存関係の仕様を指定します。これらは、Terraform という BUILD または BUILD.bazel。両方が存在する場合、Bazel は BUILD.bazel を優先します。理由 BUILD ファイルがまだ受け入れられているのは、Bazel の祖先である Blaze がファイル名を指定します。しかし、このセグメントは一般的に使用されるパスセグメントです。特に、 Windows では、ファイル名の大文字と小文字は区別されません。

パッケージは互いに独立している（パッケージの BUILD ファイルに対する変更）他のパッケージは変更できません。BUILD ファイルの追加、削除再帰 glob はパッケージ境界で停止するため、他のパッケージを変更できます。 BUILD ファイルが存在する場合、再帰は停止されます。

BUILD ファイルの評価は「パッケージの読み込み」と呼ばれます。実装されているクラス PackageFactory: Starlark インタープリタを呼び出して機能し、使用可能なルールクラスのセットに関する知識が必要です。パッケージの結果読み込みは Package オブジェクトです。ほとんどは、文字列（名前）からのマップです。ターゲット自体に追加されます。

パッケージ読み込みの複雑さの大部分は「グロビング」です。Bazel はすべてのソースファイルを明示的にリストする必要があり、代わりに glob を（glob(["**/*.java"]) など）。シェルとは異なり、再帰的 glob をサポートしています。サブディレクトリに降格します（サブパッケージにはできません）。これには、以下へのアクセス権が必要です。読み込みには時間がかかることがあるため、可能な限り効率的に並列実行できます

グロビングは次のクラスに実装されています。

LegacyGlobber は、スカイフレームをまったく知らない、高速で快適な地球儀です。
SkyframeHybridGlobber: Skyframe を使用して以前の「スカイフレームの再起動」を回避するために以前の globber を使用（以下で説明）。

Package クラス自体には、イベントにのみ使用されるメンバーがいくつか含まれています。実際のパッケージでは意味をなさない部分を、WORKSPACE ファイルを解析します。これは、設計上の欠陥の一例です。通常のパッケージを記述するオブジェクトには、その他の情報を表すフィールドが作成されます。指標には以下が含まれます。

リポジトリのマッピング
登録済みのツールチェーン
登録された実行プラットフォーム

理想的には、WORKSPACE ファイルのパースと Package がニーズに対応する必要がないように通常のパッケージを解析するあります。この 2 つは関連しあっているため、これは残念ながら困難です。深く掘り下げることができます

ラベル、ターゲット、ルール

パッケージは、次のタイプのターゲットで構成されます。

ファイル: ビルドの入力または出力です。イン Bazel の用語では、これらはアーティファクト（別の場所で説明）と呼ばれます。すべてではありませんビルド中に作成されるファイルがターゲットになります。通常、出力は Bazel にラベルが関連付けられていない。
ルール: 入力から出力を導出する手順を説明します。。通常はプログラミング言語（cc_library、 java_library や py_library など）ですが、言語に依存しないものもあります（genrule、filegroup など）
パッケージグループ: 公開設定のセクションを参照してください。

ターゲットの名前はラベルと呼ばれます。ラベルの構文は、 @repo//pac/kage:name（repo はラベルがあるリポジトリの名前です） pac/kage はその BUILD ファイルがあるディレクトリ、name はパスです。ファイル（ラベルがソースファイルを参照している場合）の相対パスで、パッケージ化されています。コマンドラインでターゲットを参照する場合、ラベルの一部は省略できます。

リポジトリを省略すると、ラベルはメインのリポジトリに配置されます。できます。
パッケージ部分（name や :name など）が省略されている場合は、ラベルが使用されます。現在の作業ディレクトリのパッケージに配置されます（相対パス）上位レベルの参照（..）を含むことはできません）

ルールの一種（「C++ ライブラリ」など）は「ルールクラス」と呼ばれます。ルールクラスは、 Starlark（rule() 関数）または Java（「ネイティブルール」、RuleClass と入力します）。長期的には Starlark に実装されますが、Java や Java などの古いルールファミリーもあります。や C++ など）を含むライブラリは当面は Java のままとなります。

Starlark ルールクラスを BUILD ファイルの先頭でインポートする必要があります Java のルールクラスは load() ステートメントを使用して知名度 Bazel は ConfiguredRuleClassProvider に登録されているためです。

ルールクラスには、以下のような情報が含まれます。

属性（srcs、deps など）: 型、デフォルト値、制約など
各属性に関連付けられた構成の遷移とアスペクト（存在する場合）
ルールの実装
推移的情報プロバイダは、ルールを「通常」作成

用語に関する注: コードベースでは、ターゲットと作成します。Starlark のユーザー向けドキュメントでは、「ルール」は、ルールクラス自体を参照する目的でのみ使用します。ターゲット単なる「ターゲット」ですまた、RuleClass には "class" があるにもかかわらず、内でルールクラスとターゲットの間に Java 継承関係はありません。作成します。

スカイフレーム

Bazel の基盤となる評価フレームワークは Skyframe です。モデルは、ビルド中に構築する必要があるすべてのものが、エッジが任意のデータからその依存関係を指している非巡回グラフつまり構築するために知る必要のある他のデータです

グラフ内のノードは SkyValue と呼ばれ、その名前は SkyKey 秒。どちらもほとんど不変です。不変のオブジェクトのみを内部 IP アドレスを使用して通信できますこの不変条件はほとんどの場合に当てはまりますが、（たとえば、個々のオプションクラス BuildOptions は、 BuildConfigurationValue やその SkyKey など）を変更しないようにするために、外部からは観察できない方法でのみ変更したりできますこのことから、Skyframe 内で計算されるもの（構成済みのターゲット）も不変である必要があります。

Skyframe グラフを観察する最も便利な方法は、bazel dump --skyframe=deps を実行することです。これにより、1 行に 1 つの SkyValue がダンプされます。最高非常に大きくなる可能性があるため、小さなビルドでこれを行う必要があります。

スカイフレームは com.google.devtools.build.skyframe パッケージにあります。「類似した名前のパッケージ com.google.devtools.build.lib.skyframe には、 Skyframe 上に Bazel を実装しています。Skyframe について詳しくは、こちらをご覧ください。

特定の SkyKey を SkyValue に評価するために、Skyframe は鍵の型に対応する SkyFunction。関数の Skyframe から他の依存関係をリクエストして、 SkyFunction.Environment.getValue() のさまざまなオーバーロード。これには、これらの依存関係を Skyframe の内部グラフに登録することによる副作用が発生するため、 Skyframe の依存関係が関数に再評価されることをあります。言い換えれば、Skyframe のキャッシュ保存と増分計算は SkyFunction と SkyValue の粒度。

SkyFunction が利用できない依存関係をリクエストするたびに、getValue() null が返されます。この関数で Skyframe に制御を戻す必要があります。 null を返します。しばらくすると Skyframe が関数を最初から再起動するだけです。 getValue() 呼び出しが null 以外の結果で成功する時間。

そのため、SkyFunction 内で実行される計算は処理を繰り返す必要があります。ただし、これにはキャッシュに保存される依存関係 SkyValues を評価します。そのため次の方法でこの問題を回避します。

依存関係をバッチで宣言する（getValuesAndExceptions() を使用）再起動の回数を制限します。
SkyValue を異なる要素によって計算された複数の部分に分割する個別に計算してキャッシュに保存できるように、SkyFunction を作成します。このメモリを増やす可能性があるため、戦略的に行う必要があります。できます。
再起動と再起動の間に状態を保存する（ SkyFunction.Environment.getState()、またはアドホック静的キャッシュの保持「skyframe の背面」です。

基本的に、このような回避策が必要なのは、何十万もの処理中の Skyframe ノードが必要です軽量のスレッドです。

スターラーク

Starlark は、ユーザーが構成と拡張に使用するドメイン固有の言語 Bazel。Python の制限付きサブセットとして想定されていますが制御フローの制限が増え、最も重要なこととして、不変性が強くなります。同時読み取りが可能になります。チューリング完全ではないため、一部の（すべてではない）ユーザーが、一般的な目的を達成しようと試みることをプログラミングタスクに使用できます。

Starlark は net.starlark.java パッケージに実装されています。また、独立した Go 実装も備えています。こちらをご覧ください。Java Bazel で使用される実装は、現時点ではインタープリタです。

Starlark は、次のような複数のコンテキストで使用されます。

BUILD 言語。ここで新しいルールを定義します。Starlark コードこのコンテキストで実行すると、BUILD ファイルの内容にのみアクセスできます。それによって読み込まれた .bzl ファイルが含まれます。
ルールの定義。新しいルール（新しいルールのサポートなど）が、言語）が定義されます。このコンテキストで実行される Starlark コードには、直接依存関係によって提供される構成とデータ（詳しくはあります）。
WORKSPACE ファイル。外部リポジトリ（）が定義されます。
リポジトリルールの定義。これが新しい外部リポジトリタイプ定義します。このコンテキストで実行される Starlark のコードは、 Bazel が実行されているマシンから分離して、ワークスペースの外部にリーチできます。

BUILD ファイルと .bzl ファイルで使用できる言語が若干異なる表現力が異なるからです差異のリストはこちらをご覧ください。

Starlark について詳しくはこちらをご覧くださいこちらをご覧ください。

読み込み/分析フェーズ

読み込み/分析フェーズでは、Bazel は必要なアクションを判断します。作成します。基本単位は「構成済みのターゲット」です。（ターゲットと構成）のペアになります。

これは「読み込み/分析フェーズ」と呼ばれる2 つに分けることができるため以前はシリアル化されていた別々の部分が、時間的に重複しています。

パッケージを読み込む（BUILD ファイルを Package オブジェクトに変換する）各要素を表す
構成済みのターゲットの分析、つまり、使用してアクショングラフを生成する

構成された各ターゲットの推移的クロージャ内の構成済みターゲットボトムアップで分析する必要があります。つまり、リーフノードは次にコマンドラインで指定される関数に移ります。分析のための入力は、単一の構成済みターゲットは次のとおりです。

構成。（そのルールの「作成方法」。たとえば、ターゲットコマンドラインオプションなども使用できます C++ コンパイラに渡されます）
直接的な依存関係。一時的な情報の提供元は追加します。このように呼ばれるのは「ロールアップ」構成された 2 つの推移のたとえば、クラスパス上のすべての .jar ファイル、 C++ バイナリにリンクする必要がある）
ターゲット自体。ターゲットにパッケージを読み込んだ結果ありますルールの場合、これには属性が含まれます。重要です
構成されたターゲットの実装。ルールの場合、この設定は次のいずれかです。 Starlark か Java ですルール以外の構成ターゲットがすべて実装されています説明します。

構成されたターゲットの分析の出力は次のようになります。

それに依存するターゲットを構成した推移的情報プロバイダは、アクセス
作成可能なアーティファクトと、それを生成するアクション。

Java ルールに提供される API は RuleContext です。これは、 Starlark ルールの ctx 引数。API はより強力ですが、 Bad ThingsTM の作業も簡単です Bazel サーバーがクラッシュする条件を 2 次関数（2 次）にし、 Java 例外が発生する、または不変条件に違反した場合（例: Options インスタンスを使用するか、構成されたターゲットを変更可能にします）

構成されたターゲットの直接的な依存関係を判断するアルゴリズム DependencyResolver.dependentNodeMap() に住んでいる。

構成

構成とは、どのプラットフォームを何でコマンドラインオプションなど

同じビルド内の複数の構成に対して同じターゲットをビルドできます。このツールは、たとえば、実行中のツールに同じコードを使用する場合にビルドとターゲットコードのコンパイルがファットな Android アプリ（複数の CPU に対応するネイティブコードを含むもの）を作成するアーキテクチャ）

概念的には、この構成は BuildOptions インスタンスです。ただし、 BuildOptions は BuildConfiguration でラップされており、次の値を提供します。追加機能も備えていますレイヤの上から順に表示されます。変更があった場合は、ビルドを次のように変更する必要があります。再分析します

その結果、ビルド全体を再分析しなければならないような異常が生じます。リクエストされたテスト実行の数は変わりませんが、テストターゲットに影響します（構成を「トリミング」して、まだ準備ができていません）。

ルールの実装を構成に含める必要がある場合は、 RuleClass.Builder.requiresConfigurationFragments() を使用して定義の中でをタップします。これは誤り（Java フラグメントを使用する Python ルールなど）を回避するためと、構成のトリミングを容易にして、Python のオプションが変更された場合に、ターゲットを再分析する必要はありません

ルールの構成は、そのルールの「親」の構成と必ずしも同じではない適用できます。依存関係エッジで構成を変更するプロセスは、「構成の移行」です。これは、次の 2 つの場所で発生します。

依存関係エッジ。これらの遷移は、 Attribute.Builder.cfg() は、Rule の関数です（ここで、 BuildOptions（元の構成）を 1 つの変換にまたは複数の BuildOptions（出力構成）。
構成されたターゲットへの任意の受信エッジ。これらは RuleClass.Builder.cfg()。

関連するクラスは TransitionFactory と ConfigurationTransition です。

次のような構成の遷移が使用される。

ビルド中に特定の依存関係が使用され、その依存関係がその都度実行アーキテクチャに
特定の依存関係を複数の依存関係用にビルドする必要があることを宣言するアーキテクチャ（ファットな Android APK のネイティブコードなど）

構成の遷移によって複数の構成が生じることを、 あります。

構成の遷移は Starlark でも実装できます（ドキュメントこちら）

一時的な情報提供者

推移的情報プロバイダは、構成されたターゲットのための方法（および唯一の方法）依存する他の構成済みターゲットに関する情報を提供します。なぜなら、「推移的」これは通常なんらかの形で統合され設定済みターゲットの推移的クロージング

通常、Java の推移的情報プロバイダ間には 1 対 1 の対応関係があります。 Starlark のもの（例外は DefaultInfo は、 FileProvider、FilesToRunProvider、RunfilesProvider です。これは、この API が Java の文字変換よりも Starlark っぽいと考えられています）。キーは次のいずれかです。

Java クラスオブジェクト。これを利用できるのは、 Starlark からもアクセスできます。これらのプロバイダは、 TransitiveInfoProvider。
文字列。これは遺産であり、脆弱性の影響を受けやすいため、強くおすすめしません。おすすめします。このような推移的情報プロバイダは、 build.lib.packages.Info
プロバイダシンボル。これは、provider() を使用して Starlark から作成できます。新しいプロバイダを作成する場合には、この方法をおすすめします。記号は、 Java では Provider.Key インスタンスで表されます。

Java で実装された新しいプロバイダは、BuiltinProvider を使用して実装する必要があります。 NativeProvider はサポートが終了している（まだ削除できていない） Starlark から TransitiveInfoProvider サブクラスにはアクセスできません。

構成済みのターゲット

構成済みのターゲットは RuleConfiguredTargetFactory として実装されます。こちらのサブクラスを 1 つ実装します。Starlark の構成済みターゲット StarlarkRuleConfiguredTargetUtil.buildRule() を使用して作成されます。

構成されたターゲットファクトリで RuleConfiguredTargetBuilder を使用して以下を行う必要があります。戻り値を構築します。以下の要素で構成されます。

「filesToBuild」は、「このルールの一連のファイル」という曖昧なコンセプトです。説明します。これらは、構成済みのターゲットの作成時にビルドされるコマンドラインまたは genrule の srcs に配置します。
実行ファイル、通常のファイル、およびデータです。
出力グループ。これらはさまざまな「その他のファイルセット」ルールは、構築できます。Deployment の output_group 属性を使用して、 BUILD のファイルグループルールと Java の OutputGroupInfo プロバイダを使用します。

実行ファイル

一部のバイナリは、実行するためにデータファイルを必要とします。典型的な例が、3 つのアプリケーションの使用できます。Bazel では、「runfiles」のコンセプトで表されます。「runfiles ツリー」特定のバイナリのデータファイルのディレクトリツリーです。ファイルシステムで、個々のシンボリックリンクを含むシンボリックリンクツリーとして作成されます。出力ツリーのソース内のファイルを指します。

実行ファイルのセットは Runfiles インスタンスとして表されます。これは概念的には、 runfiles ツリー内のファイルのパスから Artifact インスタンスへマッピングを意味します。2 つで Map を 1 つ使うよりも少し複雑です。理由:

ほとんどの場合、ファイルの runfiles パスは execpath と同じです。これを使用して RAM を節約します。
実行ファイルツリーにはさまざまな種類のエントリがあり、それらも表します

実行ファイルは RunfilesProvider（このクラスのインスタンス）を使用して収集されます。構成されたターゲット（ライブラリなど）およびその推移的なランファイルを表します。ネストされたセットのように収集されます（実際、実装されています。各ターゲットは runfile を UNION します。依存関係の追加を行ってから、その依存関係を必要があります。RunfilesProvider インスタンスには 2 つの Runfiles が含まれます。 1 つは「data」型ルールに依存する場合で、属性と 1 つずつ作成するようにしますこれは、ターゲットがデータ属性を通じて依存されている場合、異なるランファイルを提示することがある向上しますこれはこれまで気づかなかった、望ましくない従来の動作ですまだ削除中です。

バイナリの実行ファイルは RunfilesSupport のインスタンスとして表されます。このは、RunfilesSupport には次の機能があるため、Runfiles とは異なります。（単なるマッピングである Runfiles とは異なります）。この次の追加コンポーネントが必要です。

入力 runfile マニフェスト。これは、データセットのシリアル化された説明です。 runfiles ツリーを使用します。runfiles ツリーの内容のプロキシとして使用 Bazel は、runfiles ツリーが変化したと想定するのは、維持できます。
出力の runfile マニフェスト。これはランタイムライブラリが runfile ツリーを処理します。特に Windows では、シンボリックリンク。
runfiles 中間者。runfile ツリーを作成するには、シンボリックリンクツリーとシンボリックリンクが参照するアーティファクトを構築します。順序依存関係のエッジを減らすために、runfiles 中間者をすべてを表すために使用されます
コマンドライン引数。その実行ファイルがあるバイナリを実行するための RunfilesSupport オブジェクトが表すもの。

アスペクト

アスペクトは、「計算を依存関係グラフに伝播」する方法です。内容は次のとおりです。 Bazel のユーザー向けに記載こちらをご覧ください。良い重要な例は、プロトコルバッファです。proto_library ルールは認識すべきではありません。プロトコルの実装を構築する際には、任意のプログラミングにおけるバッファメッセージ（プロトコルバッファの「基本単位」）言語は proto_library ルールに結合し、2 つのターゲットが同じ言語が同じプロトコルバッファに依存しているため、ビルドは 1 回だけです。

構成されたターゲットと同様に、Skyframe では SkyValue として表されます。その構成方法は、構成済みのターゲットとビルドされています。たとえば、ConfiguredAspectFactory というファクトリクラスがあり、 RuleContext にアクセスできますが、構成されたターゲットファクトリとは異なり、プロバイダに関する情報を確認できます。

依存関係グラフに伝播されるアスペクトのセットは、 Attribute.Builder.aspects() 関数を使用して属性を追加します。他にもプロセスに参加している

AspectClass はアスペクトの実装です。Java や（この場合はサブクラス）または Starlark（この場合は StarlarkAspectClass のインスタンスです）。これは、 RuleConfiguredTargetFactory。
AspectDefinition はアスペクトの定義です。次の要素が含まれます: プロバイダとその提供プロバイダが記載されています。また、プロバイダが（適切な AspectClass インスタンスなど）。です。 RuleClass に似ています。
AspectParameters は、伝播されるアスペクトをパラメータ化する方法です。依存関係グラフを作成します。現在は文字列から文字列へのマップです。良い例これが役立つ理由のほとんどは、プロトコルバッファです。1 つの言語に複数の API がある場合、どの API のためにプロトコルバッファを構築すべきかについて反映されます。
Aspect は、特徴値を計算するために必要なすべてのデータを表します。依存関係グラフの下まで伝播しますこれは、アスペクトクラス、定義とパラメータを指定します。
RuleAspect は、特定のルールの要素を決定する関数です。伝播されます。Rule です。->Aspect 関数を使用します。

やや予想外に複雑になるのは、アスペクトが他のアスペクトに結び付く可能性があることです。たとえば、アスペクトが Java IDE のクラスパスを収集する場合、クラスパス上のすべての .jar ファイルについて知る必要がありますが、その一部はプロトコルバッファです。その場合、IDE 側でこれにアタッチするのは（proto_library ルール + Java proto アスペクト）ペア。

アスペクトの複雑さはクラスでキャプチャされます AspectCollection。

プラットフォームとツールチェーン

Bazel はマルチプラットフォームビルド（つまり、存在する可能性があるビルド）をサポートしていますビルドアクションを実行する複数のアーキテクチャと、構築するコードを指定しますこれらのアーキテクチャは、Bazel ではプラットフォームと呼ばれます。用語（詳細ドキュメント）こちら）

プラットフォームは、制約設定（「CPU アーキテクチャ」の概念）を制約値（特定の CPU や（x86_64 など）。「辞書」という最も一般的な制約の @platforms リポジトリ内の設定と値。

ツールチェーンのコンセプトは、ビルドが実行されているか、ターゲットプラットフォームが特定されるため、異なるコンパイラ。たとえば、特定の C++ ツールチェーンが他の OS をターゲットにすることもできますBazel は C++ とセット実行とターゲットプラットフォームに基づいて使用されるコンパイラ（ツールチェーンのドキュメントは、こちらをご覧ください）。

そのために、ツールチェーンに実行セットのアノテーションを付け、ターゲットプラットフォームの制約に応じて異なります。そのためには、ツールチェーンは、次の 2 つの部分に分かれています。

実行とターゲットのセットを記述する toolchain() ルールツールチェーンがサポートしている制約と、リソースの種類（C++ や Java など）をツールチェーン。後者は toolchain_type() ルールで表されます。
実際のツールチェーン（ cc_toolchain()）

このようにして、すべてのリソースに対して制約をツールチェーンを使用して、ツールチェーンの解決や言語固有の *_toolchain() ルールにはそれよりはるかに多くの情報が含まれているため、ルールよりも多くの処理が必要になります。時間がかかります。

実行プラットフォームは、次のいずれかの方法で指定します。

WORKSPACE ファイルで、register_execution_platforms() 関数を使用する
コマンドライン（--extra_execution_platforms コマンドラインを使用）オプション

使用可能な実行プラットフォームのセットは、 RegisteredExecutionPlatformsFunction

構成されたターゲットのターゲットプラットフォームは、 PlatformOptions.computeTargetPlatform()これはプラットフォームのリストです複数のターゲットプラットフォームをサポートしたいが、実装されていないまだです。

構成済みのターゲットに使用するツールチェーンのセットは、 ToolchainResolutionFunction。次の関数です。

登録済みのツールチェーンのセット（WORKSPACE ファイルと構成）
目的の実行プラットフォームとターゲットプラットフォーム（構成内）
構成されたターゲット（ UnloadedToolchainContextKey)
構成されたターゲットの実行プラットフォーム制約のセット（ exec_compatible_with 属性）と構成（--experimental_add_exec_constraints_to_targets）、 UnloadedToolchainContextKey

その結果は UnloadedToolchainContext になります。これは基本的に、ツールチェーンタイプ（ToolchainTypeInfo インスタンスとして表される）を、ツールチェーン）が表示されます。これは“アンロード”と呼ばれ単語が含まれていないため、そのラベルのみが含まれます。

次に、ツールチェーンが実際に ResolvedToolchainContext.load() を使用して読み込まれます。リクエスト元の構成済みターゲットの実装で使用されます。

単一の「ホスト」に依存しているレガシーシステムもあります。さまざまな形式で表される構成とターゲット構成が構成フラグ（--cpu など）。上の移行に段階的に移行しています。ありませんユーザーが従来の構成に依存しているケースに対応するには実装しています。プラットフォームのマッピング従来のフラグと新しいスタイルのプラットフォーム制約の間の変換が必要になります。コードは PlatformMappingFunction にあり、Starlark 以外の「little」表示されます。

制約

場合によっては、あるターゲットと互換性があるように指定したい説明します。残念ながら、Bazel にはこの目的を達成するための複数のメカニズムがあります。

ルール固有の制約
environment_group() / environment()
プラットフォームの制約

ルール固有の制約は主に Google for Java ルールで使用されます。彼らは Bazel では利用できない場合でも、ソースコードがそのエンティティへの参照が含まれます。これを制御する属性は constraints=

environment_group() と environment()

これらのルールは従来のメカニズムであり、広くは使用されていません。

すべてのビルドルールで、どの「環境」をターゲットとなるのは「environment」environment() ルールのインスタンスです。

ルールでサポートされている環境を指定するには、いくつかの方法があります。

restricted_to= 属性を使用する。これは最も直接的な形式で、仕様ルールでサポートされる環境のセットを正確に宣言する選択します。
compatible_with= 属性を使用する。環境をルールとして宣言します。「standard」のほかに、Google Cloud でサポートされるできます。
パッケージレベルの属性 default_restricted_to= と default_compatible_with=。
environment_group() ルールのデフォルトの指定を使用する。毎が属しているグループ（例: 「CPU 使用率」、アーキテクチャ、JDK バージョン（例: 「モバイルオペレーティングシステム」）。「環境グループの定義には、次の環境のうちどれが「default」によってサポートされる restricted_to= / environment() 属性。該当する属性がないルールは、属性はすべてデフォルトを継承します。
ルールクラスによるデフォルト。これは、すべての割り当てられています。これを使用して、たとえば各インスタンスを明示的に指定することなく、すべての *_test ルールをテスト可能宣言します。

environment() は通常のルールとして実装されますが、environment_group() はは Target のサブクラスであり、Rule（EnvironmentGroup）ではない、かつ Starlark からデフォルトで使用できる（StarlarkLibrary.environmentGroup()）で、最終的には同名のあります。これは、各依存関係が反復的な依存関係にあり、所属する環境グループを宣言し、それぞれの環境を環境グループでデフォルトの環境を宣言する必要があります。

ビルドを特定の環境に制限するには、 --target_environment コマンドラインオプション。

制約チェックの実装は、Terraform の RuleContextConstraintSemantics と TopLevelConstraintSemantics。

プラットフォームの制約

現在の「公式」ターゲットが対応しているプラットフォームを説明するツールチェーンとプラットフォームの記述に使用したのと同じ制約を使用します。 pull リクエストで審査中です #10945。

公開設定

（Google のような）多数の開発者が関与する大規模なコードベースを扱っている場合、他の誰かが自分のロールに依存することがないよう、できます。それ以外の場合は、ハイラムの法則に従い、導入できると見なした行動にユーザーが依存するようになる表示されます。

Bazel は、可視性と呼ばれるメカニズムによってこれをサポートしています。つまり、特定のターゲットを限定するには、 visibility 属性を使用します。この属性は少し特殊です。これは、ラベルのリストを保持していますが、任意のパッケージ名へのポインタではなく、パッケージ名のパターンを特定できます。（はい、これは設計上の欠陥です）。

これは次の場所に実装されています。

RuleVisibility インターフェースは可視性の宣言を表します。機能定数（完全に公開または完全に非公開）またはラベルのリストのいずれかです。
ラベルは、パッケージグループ（事前定義されたパッケージのリスト）を参照したり、パッケージの直接（//pkg:__pkg__）またはパッケージのサブツリー（//pkg:__subpackages__）。これはコマンドライン構文とは異なりますこれは //pkg:* または //pkg/... を使用します。
パッケージグループは独自のターゲット（PackageGroup）として実装されます。設定されたターゲット（PackageGroupConfiguredTarget）。おそらく単純なルールに置き換えることもできます。ロジックが実装されている PackageSpecification を使用します。これは //pkg/... のような単一のパターンPackageGroupContents: これは単一の package_group の packages 属性にマッピングします。および PackageSpecificationProvider は package_group を集計し、推移的な includes です。
公開設定ラベルリストから依存関係への変換は、 DependencyResolver.visitTargetVisibility、その他できます。
実際のチェックは CommonPrerequisiteValidator.validateDirectPrerequisiteVisibility()

ネストされたセット

多くの場合、構成されたターゲットは、その依存関係から一連のファイルを集約し、集約セットを推移的情報プロバイダにラップするため、依存するターゲットが構成済みの場合、それらは同様に動作します。例:

ビルドに使用される C++ ヘッダーファイル
cc_library の推移的クロージャを表すオブジェクトファイル
Java ルールのクラスパス上に配置する必要がある一連の .jar ファイル。コンパイルまたは実行
Python ルールの推移的クロージャ内の Python ファイルのセット

List や Set などを使用してこれを単純な方法で行った場合、次のようになります。二次的なメモリ使用量: N 個のルールのチェーンがあり、各ルールがコレクションのメンバーは 1+2+...+N です

この問題を回避するために、 NestedSet。これは、他の NestedSet で構成されるデータ構造です。それによって、有向非巡回グラフが形成されます。セットの集合です。これらは不変であり、そのメンバーは反復処理できます。定義複数の反復順序（NestedSet.Order）: preorder、postorder、トポロジ（ノードは常に祖先の後に来ます）「気にしないではありますが、 “毎回同じ”とします

Starlark では、同じデータ構造が depset と呼ばれます。

アーティファクトとアクション

実際のビルドは、実行する必要がある一連のコマンドから構成され、出力を出力できます。コマンドは、クラス Action。ファイルは、クラスのインスタンスとして表されます。 Artifact。これらは二部グラフ（有向非巡回グラフ）に並んでおり、「アクショングラフ」のようなものです。

アーティファクトには、ソースアーティファクト（利用可能なソースアーティファクト）の 2 種類（Bazel の実行が開始される前）と派生アーティファクト（構築）。派生アーティファクト自体には、複数の種類があります。

**通常のアーティファクト。**これらは、チェックサム（mtime をショートカットとして使用）ファイルのチェックサムは、 ctime は変わっていません。
未解決のシンボリックリンクアーティファクト。これらは Google の API によって readlink() を呼び出しています。通常のアーティファクトとは異なり、これらはぶら下がるシンボリックリンク。通常、いくつかのファイルを 1 つのアーカイブしてるんだ。
ツリーアーティファクト。これらは単一のファイルではなく、ディレクトリツリーです。。最新の状態がチェックされます。できます。TreeArtifact として表されます。
継続的なメタデータアーティファクト。これらのアーティファクトを変更しても、行います。これはビルドスタンプ情報にのみ使用されます。再ビルドする必要があります。

ソースアーティファクトがツリーアーティファクトや、未解決のシンボリックリンクアーティファクトがある場合、これはまだ実装されていないだけです（ただし、BUILD ファイル内のソースディレクトリを参照するのは、 Bazel に関して以前から報告されている不正確さのごくわずかな問題利用可能なこの種の機能の実装には、 BAZEL_TRACK_SOURCE_DIRECTORIES=1 JVM プロパティ）

注目すべき種類の Artifact は仲介業者です。Artifact で示されます。 MiddlemanAction の出力であるインスタンス。これらは、次のようなことを念頭に置いてください。

アーティファクトをグループ化するには、集約中間者を使用します。これは、多くのアクションが同じ大規模な入力セットを使用する場合、N*M は存在しない依存エッジ、N+M のみ（ネストされたセットに置き換えられる）
依存関係ミドルマンのスケジュールによって、あるアクションが別のアクションより先に実行されるようにします。主に lint チェックに使用されますが、C++ コンパイルにも使用されます（ CcCompilationContext.createMiddleman(): 説明）。
実行ファイルミドルメンは、runfiles ツリーの存在を確認するために使用されます。出力マニフェストや各モジュールに個別に依存する必要は runfiles ツリーで参照される単一のアーティファクトです。

アクションは、実行する必要があるコマンド、つまり環境生成する出力のセットが含まれます。主なものは次のとおりです。次の要素が含まれます。

実行する必要があるコマンドライン
必要な入力アーティファクト
設定する必要がある環境変数
実行する必要のある環境（プラットフォームなど）を記述するアノテーション \

他にも、内容が指定されたファイルを書き込むなど、いくつかの特殊なケースがあります。使用されます。AbstractAction のサブクラスです。ほとんどのアクションは SpawnAction または StarlarkAction（同じ。 Java と C++ にはそれぞれ独自のアクション型がありますが、（JavaCompileAction、CppCompileAction、CppLinkAction）。

最終的には、すべてを SpawnAction に移行します。JavaCompileAction はかなり似ていますが、C++ は少し特殊なケースです。.d ファイルの解析と変換のスキャンが含まれます。

アクショングラフのほとんどは「埋め込まれている」グラフに表現されます。概念的には、アクションの実行は、サービスの呼び出しとして表され、 ActionExecutionFunction。アクショングラフの依存関係エッジからスカイフレームの依存関係エッジについては、 ActionExecutionFunction.getInputDeps()、Artifact.key() などがあり、 Skyframe のエッジの数を低く抑えるために、次のように最適化します。

派生アーティファクトには、独自の SkyValue はありません。代わりに Artifact.getGeneratingActionKey() は、鍵を見つけるために使用されます。アクションを生成
ネストされたセットには独自のスカイフレームキーがあります。

共有操作

一部のアクションは、複数の構成済みターゲットによって生成されます。Starlark のルールは次のとおりです。派生アクションを 1 つのコンテナにしか格納できないため、構成とパッケージによって決定されます（ただし、競合する可能性がありますが、Java で実装されたルールでは保存できます。

これは誤りと考えられますが、取り除くのはとても困難です実行時間を大幅に短縮できるからですソースファイルはなんらかの方法で処理する必要があり、複数のルールがあります（例: 手を振る、手を振る）。これには RAM がいくらかかかります。各インスタンスは個別にメモリに保存する必要があります。

2 つのアクションが同じ出力ファイルを生成する場合は、完全に同じである必要があります。同じ入力、同じ出力を指定し、同じコマンドラインを実行します。この等価関係は Actions.canBeShared() に実装されています。すべてのアクションを検証する必要があります。これは SkyframeActionExecutor.findAndStoreArtifactConflicts() に実装されています。 Bazel で「グローバル」なものを必要とする数少ない場所の 1 つです。ビュー構築できます。

実行フェーズ

このとき、Bazel が実際にビルドアクションの実行を開始します。出力を生成します。

分析フェーズの後、Bazel が最初に行うのは、アーティファクトを構築する必要があります。このロジックは、Python コードで TopLevelArtifactHelper、大まかに言えば、モデルの filesToBuild です。コマンドラインで構成されたターゲットと、「もしこのターゲットがコマンドに含まれているか」を明示する目的で、これらのアーティファクトをビルドします

次のステップでは、実行ルートを作成します。Bazel には、リソースを読み取るオプションがファイルシステム（--package_path）の異なる場所にあるソースパッケージ完全なソースツリーを使用して、ローカルで実行されるアクションを提供する必要があります。これは、クラス SymlinkForest によって処理され、すべてのターゲットをメモすることで動作します。シンボリックリンクする単一のディレクトリツリーを構築します。使用済みのターゲットを持つすべてのパッケージを実際の場所から追跡できます。別の方法として、コマンドに正しいパスを渡す必要があります（--package_path を考慮します）。次の理由により、これは適切ではありません。

パッケージがパッケージパスから移動されると、アクションのコマンドラインが変更されます。別のエントリ（以前はよく発生します）
アクションをリモートで実行する場合とリモート実行する場合とで、異なるコマンドラインになります。ローカルで実行され
使用するツールに固有のコマンドライン変換が必要である（Java クラスパスと C++ インクルードパスの違いを考慮してください）
アクションのコマンドラインを変更すると、そのアクションのキャッシュエントリが無効になる
--package_path は段階的に非推奨に

次に、Bazel はアクショングラフ（二部有向グラフ）の走査を開始します。アクションとその入力および出力アーティファクトで構成される）と、実行中のアクションです。各アクションの実行は SkyValue のインスタンスによって表されるクラス ActionExecutionValue。

アクションの実行にはコストがかかるため、複数のレイヤを使用して SkyFrame の後ろにぶつかる:

ActionExecutionFunction.stateMap には、Skyframe を再起動するためのデータが含まれています。 /ActionExecutionFunction の低価格
ローカルアクションキャッシュには、ファイルシステムの状態に関するデータが含まれています。
リモート実行システムには通常、独自のキャッシュも含まれている

ローカルアクションキャッシュ

このキャッシュは Skyframe の背後にあるもう 1 つのレイヤです。あるアクションが Skyframe で再実行された場合、ローカルアクションキャッシュでヒットする可能性があります。これは、ローカルファイルシステムの状態を表し、ディスクにシリアル化されます。新しい Bazel サーバーを起動すると、ローカルアクションキャッシュを取得できますヒットします。

このキャッシュでは、メソッドを使用してヒットがチェックされます。 ActionCacheChecker.getTokenIfNeedToExecute()

名前とは異なり、派生アーティファクトのパスから検出できます。このアクションは次のように記述されます。

入出力ファイルとそれらのチェックサムのセット
「アクションキー」（通常は実行されたコマンドライン）ですが、アプリケーションリソースのチェックサムでキャプチャされないもの、入力ファイル（たとえば FileWriteAction の場合、これはデータの記録される）

高度に実験的な「トップダウンアクションキャッシュ」もあります。まだこれは、推移的ハッシュを使用して、できるだけ多くのあります。

入力検出と入力プルーニング

一部のアクションは、単に一連の入力を取得するよりも複雑な場合があります。変更点アクションの入力セットには、次の 2 つの形式があります。

アクションは、実行前に新しい入力を検出したり、一部の入力をその入力が実際には必要ありません。典型的な例は C++です C++ レイヤでどのヘッダーファイルがファイルなのか、一時的なクロージャから解放されるようにします。これにより、リモートエグゼキュータに送信します。すべてのケースを登録する代わりにヘッダーファイルを「入力」として使用するが、ソースファイルをスキャンして推移的そのヘッダーファイルのみを含む入力としてマークし、 #include ステートメントで言及（実際よりも多く見積もっているため、（完全な C プリプロセッサを実装）「false」Bazel で行われ、Google 内でのみ使用されます。
アクションの実行中に一部のファイルが使用されていないことに気付く場合があります。イン C++ の場合、これは「.d ファイル」と呼ばれます。コンパイラは、どのヘッダーファイルが悪化させたという恥ずかしさを避けるために、インクリメンタリティであるため、Bazel はこの事実を利用しています。これにより、インクルードスキャナはコンパイラに依存しているため、見積もりはインクルードスキャナよりも高くなります。

これらは Action のメソッドを使用して実装されます。

Action.discoverInputs() が呼び出されます。ネストされたフィールドのセットが返されます。必要と判断されたアーティファクト。これらはソースアーティファクトであること依存関係のない依存関係エッジがアクショングラフに残らないようにします。同等の値が示されます。
このアクションは、Action.execute() を呼び出すことによって実行されます。
Action.execute() の最後で、アクションは以下を呼び出すことができます。 Action.updateInputs() で、入力の一部がないことを Bazel に指示します必要ありません。これにより、使用された入力が次の場合に、増分ビルドが正しく行われないことがあります。未使用と報告されます

アクションキャッシュが新しいアクションインスタンス（作成された Bazel は updateInputs() 自体を呼び出し、入力内容には、以前に実施した入力の検出とプルーニングの結果が反映されます。

Starlark のアクションは、この機能を利用して一部の入力を未使用として宣言できます。 unused_inputs_list= 引数を使用して、 ctx.actions.run()。

アクションを実行するさまざまな方法: Strategies/ActionContexts

一部のアクションはさまざまな方法で実行できます。たとえば、コマンドラインは、さまざまなサンドボックス、またはリモートで実行されるようにします。「これを実現するコンセプトを ActionContext（または Strategy 名前変更の半分しか成功しなかった...）

アクションコンテキストのライフサイクルは次のとおりです。

実行フェーズが開始されると、BlazeModule インスタンスに対して、コンテキストに基づいて生成されます。これは、Terraform のコンストラクタで ExecutionTool。アクションコンテキストタイプは Java Class で識別されます ActionContext のサブインターフェースを参照するインスタンスと、実装する必要があるインターフェースです。
利用可能なアクションコンテキストから適切なアクションコンテキストが選択され、 ActionExecutionContext と BlazeExecutor に転送。
アクションは、ActionExecutionContext.getContext() を使用してコンテキストをリクエストします。 BlazeExecutor.getStrategy()（実際には、実行する方法は 1 つ。

戦略は、仕事をするために他の戦略を自由に呼び出すことができます。これは Pod のローカルとリモートの両方でアクションを開始する動的戦略の場合、先に終了したほうを使用します。

注目すべき戦略の一つは、永続ワーカープロセスを実装することです。（WorkerSpawnStrategy）。一部のツールは起動に時間がかかるという別のアクションをまたいで再利用するのではなくすべてのアクション（これは正確性の問題である可能性があります。Bazel はワーカープロセスが Observability の Promise に依存していることに状態を指定する）

ツールが変更された場合は、ワーカープロセスを再起動する必要があります。ワーカーがツールのチェックサムを計算して、 WorkerFilesHash。アクションのどの入力が何を表しているかを知ることにより、入力を表す部分です。クリエイターによって決定されますアクション Spawn.getToolFiles() と Spawn の実行ファイルは次のとおりです。ツールの一部としてカウントされます

戦略（またはアクションのコンテキスト）について詳しくは、以下をご覧ください。

アクションを実行するためのさまざまな戦略に関する情報を利用可能こちらをご覧ください。
アクションを実行するダイナミック戦略に関する情報結果が出ているほうをローカルとリモートから選択し、こちらをご覧ください。
ローカルでのアクション実行の複雑さに関する情報はこちらをご覧ください。

ローカルリソースマネージャー

Bazel では、多くのアクションを並行して実行できます。ローカルアクションの数は、並行して実行することが推奨されています。同時に実行するインスタンスの数を減らして、この問題を回避してください。過負荷状態になります。

これはクラス ResourceManager で実装されます。各アクションは、必要なローカルリソースの推定値が、 ResourceSet インスタンス（CPU と RAM）。アクションコンテキストがなんらかの動作をローカルリソースを必要とする場合、ResourceManager.acquireResources() を呼び出します。必要なリソースが使用可能になるまでブロックされます。

ローカルリソース管理のより詳細な説明については、こちらをご覧ください。

出力ディレクトリの構造

各アクションは、出力ディレクトリ内に個別の場所として配置する必要があります。確認します。通常、派生アーティファクトの場所は次のようになります。

$EXECROOT/bazel-out/<configuration>/bin/<package>/<artifact name>

特定の ID に関連付けられたディレクトリの名前は何ですか。どうなるでしょうか望ましいプロパティには相反するものが 2 つあります。

同じビルドで 2 つの構成を作成できる場合は、別々のディレクトリを作成し、両方に同じバージョンのインスタンスをアクション:このコマンドで 2 つの構成で相違がある場合に同じ出力ファイルを生成するアクションの行で、Bazel はどの行が選択するアクション（「アクションの競合」）
2 つの構成が「おおまか」を表す場合、同じものとして、そうすると、一方で実行されるアクションを他方で再利用できるようになります。たとえば、コマンドラインオプションを変更し、 Java コンパイラでは、C++ コンパイルアクションが再実行されません。

今のところ、この問題を解決する原則的な解決策は見つかっていません。構成トリミングの問題と類似しています長めのディスカッションオプションが用意されています。こちらをご覧ください。主な問題点は Starlark のルールです（Starlark の作成者は通常、（Bazel についてよく知っているもの）とさまざまな側面を取り上げており、「同じ」ものを生成できるものの、出力ファイルです。

現在のアプローチでは、構成のパスセグメントは <CPU>-<compilation mode> に、さまざまなサフィックスを追加して、構成に Java で実装された遷移によってアクションの競合が発生しません。また、一連の Starlark 構成遷移のチェックサムが追加され、ユーザーがアクションの競合を引き起こさないようにします。これは完璧とは程遠いものです。これは OutputDirectories.buildMnemonic()。各構成フラグメントに依存します。出力ディレクトリの名前に独自の部分を追加します。

テスト

Bazel は、テストを実行するための豊富なサポートを備えています。以下がサポートされます。

リモートでのテストの実行（リモート実行バックエンドが利用可能な場合）
テストを複数回並行して実行する（デフレークまたはタイミングの収集のため）データ）
テストのシャーディング（同じテスト内のテストケースを複数のプロセスに分割する）スピードを重視）
不安定なテストの再実行
テストをテストスイートにグループ化する

テストは、TestProvider を持つ通常の構成済みターゲットです。テストの実行方法を以下に示します。

ビルドの結果、テストが実行されるアーティファクト。これは「キャッシュ」でステータス」シリアル化された TestResultData メッセージを含むファイル
テストの実行回数
テストを分割するシャードの数
テストの実行方法に関するパラメータ（テストのタイムアウトなど）

実行するテストの決定

実行するテストの決定は複雑なプロセスです。

まず、ターゲットパターンの解析中に、テストスイートが再帰的に展開されます。「拡張は TestsForTargetPatternFunction に実装されています。ややそう思う驚くべき点として、テストスイートでテストが宣言されていない場合、そのパッケージ内のすべてのテストを実行します。これは Package.beforeBuild() で次のように実装されています。テストスイートのルールに $implicit_tests という暗黙の属性を追加します。

次に、テストは、ルールに従ってサイズ、タグ、タイムアウト、言語でフィルタされます。コマンドラインオプションを使用します。これは TestFilter で実装され、ターゲット解析中は TargetPatternPhaseFunction.determineTests()、結果は TargetPatternPhaseValue.getTestsToRunLabels() に読み込まれます。その理由は、フィルタできるルール属性を構成できないのは、実行されるので、構成は分析フェーズには含まれません。できます。

その後、BuildView.createResult() でさらに処理されます。分析が失敗した場合は除外され、テストは排他的非独占的なテストも行いますこれを AnalysisResult に挿入します。これにより、 ExecutionTool は実行するテストを認識します。

この複雑なプロセスに透明性を持たせるため、tests() クエリ演算子（TestsFunction に実装）を使用して、コマンドラインで特定のターゲットを指定すると、です。残念なことに再実装なので、上記の説明からいくつかあります。

テストの実行

テストを実行するには、キャッシュステータスのアーティファクトをリクエストします。その後、 TestRunnerAction が実行され、最終的に --test_strategy コマンドラインオプションによって選択された TestActionContext は、リクエストされた方法でテストを実行します。

テストは、環境変数を使用する複雑なプロトコルに従って実行されるテストに何を求めるかですBazel の詳細テストで想定されるもの、Bazel で想定されるテストを確認できますこちらをご覧ください。Google 最もシンプルです。終了コードが 0 の場合は成功、それ以外は失敗を意味します。

各テストプロセスは、キャッシュステータスファイル以外にも、できます。テストログディレクトリに配置されます。このサブディレクトリの名前はターゲット構成の出力ディレクトリの testlogs:

test.xml: 個々のテストケースの詳細を示す JUnit スタイルの XML ファイル。テストシャード
test.log: テストのコンソール出力。stdout と stderr はあります。
test.outputs: 「宣言されていない出力ディレクトリ」。テストで使用します。ターミナルに出力する内容に加えてファイルを出力したいアプリケーションに適しています。

テスト実行中に発生する可能性は 2 つありますが、排他的なテスト実行と出力ストリーミング。

一部のテストは排他モードで実行する必要がある（例: テストします。これを起動するには、tags=["exclusive"] をテストルールを実行するか、--test_strategy=exclusive を使用してテストを実行します。各限定別の Skyframe 呼び出しによってテストが実行され、「main」の後にテストする構築できます。これは SkyframeExecutor.runExclusiveTest()。

通常のアクションとは異なり、アクションの実行後にターミナル出力がダンプされます。終了すると、ユーザーはテストの出力をストリーミングするようリクエストして、長時間実行テストの進行状況を確認できます。これは、 --test_output=streamed コマンドラインオプション。排他テストを示します。異なるテストの出力が混在しないようにする必要があります。

これは適切な名前の StreamedTestOutput クラスに実装されており、次のように機能します。該当するテストの test.log ファイルに変更をポーリングし、新しいコードをダンプ Bazel ルールのターミナルにルーティングされます。

実行したテストの結果は、（TestAttempt、TestResult、TestingCompleteEvent など）。 Build Event Protocol にダンプされてコンソールに出力される作成者: AggregatingTestListener。

カバレッジの収集

テストのカバレッジは、ファイルの LCOV 形式で報告されます。 bazel-testlogs/$PACKAGE/$TARGET/coverage.dat

カバレッジを収集するために、各テスト実行は collect_coverage.sh

このスクリプトは、カバレッジの収集を有効にするテスト環境をセットアップします。カバレッジファイルが書き込まれる場所が、カバレッジランタイムによって判別されます。その後、テストを実行します。テスト自体が複数のサブプロセスを実行し、複数の異なるプログラミング言語で記述された部分をカバレッジ収集ランタイムなど）ですラッパースクリプトは、アプリケーションの結果のファイルを必要に応じて LCOV 形式に変換し、1 つの表示されます。

collect_coverage.sh の介在は、テスト戦略によって行われます。テストの入力に collect_coverage.sh が必要です。これは、暗黙的な属性 :coverage_support によって実現されます。これは、構成フラグ --coverage_support の値（ TestConfiguration.TestOptions.coverageSupport)

一部の言語ではオフライン計測を行います。つまり、インストルメンテーションはコンパイル時に追加され（C++など）、その他はオンラインで行われますインストルメンテーション。つまり、実行時にカバレッジインストルメンテーションが追加されるあります。

もう 1 つのコアコンセプトは、ベースラインカバレッジです。これは図書館のニュースですコードが実行されていないかどうかをテストします。解決する問題はバイナリのテストカバレッジを計算したい場合は、すべてのテストのカバレッジを確保できます。これは、バイナリに標準外のコードが含まれている可能性があるためです。すべてのテストにリンクされますしたがって、すべてのアクティビティに対してカバレッジファイルをカバレッジ対象のファイルのみを含むバイナリです。作成します。ターゲットのベースラインカバレッジファイルは、 bazel-testlogs/$PACKAGE/$TARGET/baseline_coverage.datまた、テストに加えて、バイナリとライブラリの --nobuild_tests_only フラグを Bazel に設定。

ベースラインカバレッジは現在、破損しています。

カバレッジコレクションは、ルールごとに、インストルメンテーション・メタデータ・ファイルのセットが含まれます。

インストゥルメント化されたファイルのセットは、計測するファイルのセットだけです。対象これはランタイム時にこれを使用してあります。ベースラインカバレッジの実装にも使用されます。

インストルメンテーションメタデータファイルのセットは、テストに必要な追加のファイルのセット Bazel が必要とする LCOV ファイルを生成できます。実際にはランタイム固有のファイルたとえば、gcc はコンパイル時に .gcno ファイルを出力します。これらは、カバレッジモードが次の場合にテストアクションの入力のセットに追加されます。有効にします。

カバレッジが収集されているかどうかは、 BuildConfiguration。テストの変更を簡単にするため、これは便利です。アクションとアクショングラフが異なる場合もありますがすべてのターゲットを再分析する必要があります（ C++ では、カバレッジを収集できるコードを出力するために、さまざまなコンパイラオプションが必要です。この問題はある程度軽減されます。それでいずれにせよ再分析が必要になるからです）。

カバレッジサポートファイルは、暗黙的なオーバーライドして、呼び出しポリシーでオーバーライドできるようにします。これにより、 Bazel のバージョンが異なっている必要があります。できれば、これらのそのうちの 1 つを標準化しました。

「カバレッジレポート」も生成します。収集されたカバレッジが Bazel 呼び出しのすべてのテスト。この処理には CoverageReportActionFactory で、BuildView.createResult() から呼び出されます。これは、必要なツールにアクセスするには、:coverage_report_generator 属性を宣言します。

クエリエンジン

Bazel は小さな言葉さまざまなグラフについてさまざまな質問をしています。次のクエリの種類次のオプションが提供されます。

bazel query は、ターゲットグラフの調査に使用されます。
bazel cquery は、構成されたターゲットグラフを調査するために使用されます。
bazel aquery はアクショングラフの調査に使用されます。

これらはそれぞれ、AbstractBlazeQueryEnvironment をサブクラス化することで実装されます。 QueryFunction をサブクラス化することで、その他のクエリ関数を実行できます。をタップします。クエリ結果をストリーミングで収集するのではなく、 query2.engine.Callback が QueryFunction に渡され、返すことができます。

クエリの結果は、ラベル、ラベル、ルールなど、さまざまな方法で出力できる XML、protobuf などです。これらは、Terraform のサブクラスとして実装され、 OutputFormatter。

一部のクエリ出力形式（proto は当然）の微妙な要件は、 Bazel は、パッケージの読み込みが提供するすべての情報を出力して、出力の差分を比較して、特定のターゲットに変化があったかどうかを判断できます。そのため、属性値はシリアル化可能である必要があります。そのため、複雑な Starlark を持つ属性を持たない属性タイプはごくわずかです。使用できます。通常の回避策は、ラベルを使用して複雑な追加することもできます。あまり満足のいく回避策ではないこの要件を解除できると便利です

モジュールシステム

Bazel は、モジュールを追加することで拡張できます。各モジュールは、サブクラス内に BlazeModule（この名前は、Bazel が以前使われていた頃の Bazel の歴史の遺物です Blaze）が使用され、実行中にさまざまなイベントに関する情報ができます。

これらは主に、さまざまな「非コア」コンポーネントを実装するために使用されます。機能一部のバージョンの Bazel（Google で使用しているバージョンなど）でのみ必要とする場合は、

リモート実行システムへのインターフェース
次のコマンドを新しく導入しました。

BlazeModule が提供する拡張ポイントのセットは、やや漠然としています。すべきでないこと良い設計原則の例として使えます

イベントバス

BlazeModule が Bazel の他の部分と通信する主な方法は、イベントバスによって行われます。（EventBus）: Bazel のさまざまな部分、ビルドごとに新しいインスタンスが作成されますイベントをポストでき、モジュールは対象のイベントのリスナーを登録できます。できます。たとえば、以下がイベントとして表されます。

ビルドするビルドターゲットのリストが決まっています (TargetParsingCompleteEvent)
最上位の構成が決まっています (BuildConfigurationEvent)
ターゲットは正常にビルドされましたが、正常にビルドされませんでした（TargetCompleteEvent）
テストが実行されました（TestAttempt、TestSummary）

これらのイベントの一部は、 Build イベントプロトコル（BuildEvent です）。これにより、BlazeModule だけでなく、 Bazel プロセス外でビルドを監視します。この API にはファイル（Bazel はプロトコルメッセージを含む）が格納されているサーバー（いわゆる Build Event Service など）を使用して、イベントをストリーミングできます。

これは build.lib.buildeventservice と build.lib.buildeventstream Java パッケージ。

外部リポジトリ

一方、Bazel は元々 monorepo（単一のソース Bazel は、構築に必要なすべてのものを含む必ずしもそうとは限りません「外部リポジトリ」抽象化は、この 2 つの橋渡しをしてくれます。これらはビルドに必要なコードですが、メインソースツリーにはありません。

WORKSPACE ファイル

外部リポジトリのセットは、WORKSPACE ファイルを解析することによって決定されます。たとえば、次のような宣言を行います。

    local_repository(name="foo", path="/foo/bar")

@foo という名前のリポジトリが利用可能になります。取得されるデータ Starlark ファイルで新しいリポジトリルールを定義してこれを使用して新しい Starlark コードを読み込み、新しい Starlark コードをリポジトリルールなどです。

このケースに対処するため、WORKSPACE ファイルの解析（ WorkspaceFileFunction など）は、load() で区切られたチャンクに分割されます。ステートメント。チャンクインデックスは WorkspaceFileKey.getIndex() で示され、インデックス X まで WorkspaceFileFunction を計算するということは、 X 番目の load() ステートメント。

リポジトリの取得

リポジトリのコードを Bazel で使用できるようにするには、以下を行う必要があります。 取得済みです。これにより、Bazel は $OUTPUT_BASE/external/<repository name>。

リポジトリの取得は次の手順で行われます。

PackageLookupFunction は、リポジトリが必要であることを認識し、 RepositoryLoaderFunction を呼び出す SkyKey としての RepositoryName
RepositoryLoaderFunction がリクエストを次のアドレスに転送します。不明確な理由で RepositoryDelegatorFunction（コードには、 Skyframe が再起動した場合に備えてダウンロードし直さないでください。ただし、非常に確固たる推論）
RepositoryDelegatorFunction は、リクエストされたリポジトリルールを検出します要求があるまで WORKSPACE ファイルのチャンクを反復処理して取得し、リポジトリが見つかりました
リポジトリを実装する適切な RepositoryFunction が見つかる fetching;リポジトリの Starlark 実装かマップがハードコードされています。

リポジトリの取得は非常に困難であるため、キャッシュにはさまざまなレイヤがあります。高価:

チェックサムをキーとする、ダウンロードしたファイルのキャッシュがある（RepositoryCache）。そのためには、ソースコード内でチェックサムをとにかく密閉性に優れています。共有元同じワークステーション上のすべての Bazel サーバーインスタンスをまたは出力ベースを指定できます。
「マーカーファイル」$OUTPUT_BASE/external の下に、リポジトリごとに書き込まれます。このオブジェクトには、その取得に使用されたルールのチェックサムが格納されています。Bazel によるチェックサムが変更されず、再取得も行われません。この RepositoryDelegatorFunction.DigestWriter に実装されています。
--distdir コマンドラインオプションは、別のキャッシュを使用してダウンロードするアーティファクトを検索します。これは企業の設定に便利です Bazel はインターネットからランダムに取得すべきではありません。これは、 DownloadManager で実装されます。

リポジトリをダウンロードすると、リポジトリ内のアーティファクトがソースとして扱われます。アーティファクトです通常、Bazel は最新性をチェックするため、これによって問題が発生します。 stat() を呼び出して、ソースアーティファクトの状態を確認できます。これらのアーティファクトは、リポジトリの定義が変更されると無効になります。したがって、次のようになります。外部リポジトリ内のアーティファクトの FileStateValue は、外部リポジトリに保存しましたこれは ExternalFilesHelper によって処理されます。

マネージドディレクトリ

外部リポジトリでは、Workspace のルートにあるファイルの変更が必要になる場合があります（たとえば、ダウンロードしたパッケージをアプリケーションのサブディレクトリのサブディレクトリに保管するパッケージ管理システムなど）表示されます。これは、Bazel がソースをソースとして使用するという前提とは矛盾しています。ユーザーによってのみ変更され、自身による変更ではなくなります。これにより、パッケージにすべてのディレクトリを参照します。このような外部リポジトリの作業では、Bazel は次の 2 つのことを行います。

Bazel が存在しないワークスペースのサブディレクトリをユーザーが指定できるようにします。通信できるようになります。これらは .bazelignore というファイルにリストされており、この機能は BlacklistedPackagePrefixesFunction に実装されています。
ワークスペースのサブディレクトリから外部ディレクトリへのマッピングをエンコード ManagedDirectoriesKnowledge に取り込んで処理し、 FileStateValue は通常の場合と同じように、それらを参照します。使用できます。

リポジトリのマッピング

複数のリポジトリが同じリポジトリに依存したい場合や、異なるバージョン（これは「ダイヤモンド依存関係のインスタンスであります）。たとえば、ビルド時に別々のリポジトリにある 2 つのバイナリが、両方がラベル付きの Guava を参照する可能性があります。 @guava// から始まります。これは異なるバージョンを意味すると想定します。

そのため、Bazel では外部リポジトリのラベルを再マッピングして、文字列 @guava// は、同じディレクトリ内の 1 つの Guava リポジトリ（@guava1// など）を参照できます。 1 つのバイナリリポジトリと、別の Guava リポジトリ（@guava2// など）を作成されます。

または、ダイヤモンドの結合にも使用できます。リポジトリが @guava1// に依存し、もう 1 つは @guava2// に依存し、リポジトリマッピングこれにより、正規の @guava// リポジトリを使用するように両方のリポジトリを再マッピングできます。

このマッピングは、WORKSPACE ファイルで repo_mapping 属性として指定されています。定義できます。Skyframe に WorkspaceFileValue: 次の場所に組み込まれます。

Package.Builder.repositoryMapping: ラベル値を持つ変換に使用されます。パッケージ内のルールの属性を RuleClass.populateRuleAttributeValues()
Package.repositoryMapping: 分析フェーズ（読み込みで解析されない $(location) などの問題を解決フェーズ）
load() ステートメントのラベルを解決するための BzlLoadFunction

JNI ビット

Bazel のサーバーは、ほとんど Java で記述されています。ただし、例外は、 Java は、実装時に単独では、または単独では実行できません。この主にファイルシステム、プロセス制御、アプリケーションシステムとの低レベルの要素です。

C++ コードは src/main/native の下にあり、Java クラスは native メソッドは次のとおりです。

NativePosixFiles、NativePosixFileSystem
ProcessUtils
WindowsFileOperations、WindowsFileProcesses
com.google.devtools.build.lib.platform

コンソール出力

コンソール出力を出力するのは簡単そうに思えますが、きめ細かなキャッシュ、詳細なキャッシュ保存、きれいでカラフルなターミナル出力があり、長時間稼働しているサーバーがあればこれは容易ではありません。

クライアントから RPC 呼び出しが到着した直後に、2 つの RpcOutputStream 出力されたデータを転送するためのインスタンスが作成されます（stdout と stderr の場合）。クライアントに提供しますこれらはその後、OutErr（stdout、stderr）でラップされます。ペア）。コンソールに出力する必要があるものはすべて、使用できます。これらのストリームは BlazeCommandDispatcher.execExclusively()。

出力はデフォルトで ANSI エスケープシーケンスを使用して出力されます。そうでない場合必要な場合（--color=no）、AnsiStrippingOutputStream によって削除されます。インさらに、System.out と System.err はこれらの出力ストリームにリダイレクトされます。これは、デバッグ情報を出力するために System.err.println()。ただし、最終的にクライアントのターミナル出力に入ります。（サーバーとは異なります）。プロセスが予期せず終了した場合は、バイナリ出力（bazel query --output=proto など）を生成し、stdout を変更しない行われます。

短いメッセージ（エラー、警告など）は、 EventHandler インターフェース。注目すべき点は、個人が投稿する内容とは EventBus（わかりにくい）。各 Event には EventKind（エラー、警告、情報など）が含まれていて、Location（イベントの発生原因となったソースコードなど）が含まれます。

一部の EventHandler 実装は、受け取ったイベントを保存します。これは、キャッシュされた各種処理で生じた情報を UI にリプレイするたとえば、キャッシュに保存された構成済みターゲットによって発行された警告などです。

一部のEventHandlerでは、最終的に投稿のきっかけとなったイベントも投稿できます。イベントバス（通常の Event は表示されません）。これらは ExtendedEventHandler の実装とその主な用途は、キャッシュされたコンテンツの再生です。 EventBus 件のイベント。以下の EventBus イベントはすべて Postable を実装しますが、 EventBus に投稿されるものすべてに、必ずこのインターフェースを実装します。 ExtendedEventHandler によってキャッシュされたもののみ（これは、ほとんど変わりません。適用されません）

ターミナルの出力は、ほとんど UiEventHandler から出力されます。 Bazel のあらゆる高度な出力フォーマットと進捗状況レポートを担当します。あります。入力は 2 つあります。

イベントバス
Reporter を介してこのイベントストリームにパイプで

コマンド実行マシン（たとえば、 Bazel など）からクライアントへの RPC ストリームに Reporter.getOutErr() を経由する必要があります。これらのストリームに直接アクセスできますこれは、コマンドに必要な大量のバイナリデータ（bazel query など）をダンプする

Bazel のプロファイリング

Bazel は高速です。Bazel も低速です。ビルドが増加する傾向が 100% に達するまで画期的なことですそのため、Bazel にはプロファイラが含まれており、プロファイラを Bazel 自体をプロファイリングします。このクラスは、適切な名前は Profiler です。デフォルトでオンになっていますが、オーバーヘッドが許容されるように要約されたデータ。コマンドライン --record_full_profiler_data は、可能なものをすべて録画するようにします。

Chrome Profiler 形式でプロファイルを出力します。Chrome での表示が最適ですデータモデルはタスクスタックのものです。タスクを開始して終了し、互いにきちんとネストされていることが前提です各 Java スレッドは独自のタスクスタックを作成できますTODO: アクションと継続を渡す方法

プロファイラは BlazeRuntime.initProfiler() で開始、停止し、各 BlazeRuntime.afterCommand() で指定し、存続を試行します。すべてをプロファイリングしますプロファイルに項目を追加するには Profiler.instance().profile() を呼び出します。Closeable を返します。そのクロージャはタスクの終わりを表します。try-with-resources と組み合わせて使用すると、ステートメント。

MemoryProfiler でも基本的なメモリプロファイリングが行われます。いつでもオンにできる主に最大ヒープサイズと GC 動作を記録します

Bazel のテスト

Bazel には主に 2 種類のテストがあります。1 つは Bazel を「ブラックボックス」として観察するテストです。および分析フェーズのみを実行するリソースがあります前者を「統合テスト」と呼びます後者の「単体テスト」がありますが、これらは統合テストに似ており、統合性に劣ります実際の単体テストもあります。できます。

インテグレーションテストには次の 2 種類があります。

1 つは、非常に複雑な bash テストフレームワークを使用して実装されたものです。 src/test/shell
Java で実装されたもの。これらは、Terraform のサブクラスとして実装され、 BuildIntegrationTestCase

統合テストフレームワークとして推奨されるものは BuildIntegrationTestCase です。ほとんどのテストシナリオに十分対応できますJava フレームワークであるため、多くの一般的な開発手法とデバッグ性とシームレスな統合を提供できます。Google Cloud のインフラストラクチャには、BuildIntegrationTestCase クラスの多くの例が Bazel リポジトリ。

分析テストは BuildViewTestCase のサブクラスとして実装されます。こちらの BUILD ファイル、各種ヘルパーの書き込みに使用できるスクラッチファイルシステムメソッドでは、構成済みターゲットのリクエスト、構成の変更、アサートを行うことができますさまざまな情報を提供します。