Bazel は、ディレクトリ ツリーに整理されたソースコードからソフトウェアをビルドします。
できます。ワークスペース内のソースファイルは、ネストされた階層
パッケージ。各パッケージは、関連する一連のパッケージを含むディレクトリです。
ソースファイルと 1 つの BUILD ファイル。BUILD ファイルは、使用するソフトウェアを
その出力をソースから構築できます。
ワークスペース
ワークスペースは、ソースを含むファイル システム上のディレクトリ ツリーです。
作成するソフトウェア用のファイルです。各ワークスペースには、名前を付けたテキスト ファイルが
WORKSPACE: 空か、外部への参照を含めることができます。
依存関係があります。
WORKSPACE というファイルを含むディレクトリは、
できます。そのため、Bazel は、root が root になっているワークスペース内のディレクトリ ツリーを無視します。
これらは別のワークスペースを形成するため、WORKSPACE ファイルを含むサブディレクトリが作成されます。
Bazel は、WORKSPACE ファイルのエイリアスとして WORKSPACE.bazel ファイルもサポートしています。条件
両方のファイルが存在する場合は、WORKSPACE.bazel が使用されます。
リポジトリ
コードはリポジトリにまとめられます。WORKSPACE を含むディレクトリ
ファイルはメイン リポジトリのルート（@ とも呼ばれます）です。その他（社外向け）
ワークスペース ルールを使用して、WORKSPACE ファイルでリポジトリが定義されている。
モジュールと拡張機能から生成されます。詳しくは、社外向け記事をご覧ください。
依存関係の概要をご覧ください。
Bazel にバンドルされているワークスペース ルールは、Workspace Build の [ルール] セクション 百科事典と埋め込みドキュメント Starlark リポジトリ ルール。
外部リポジトリはそれ自体がリポジトリであるため、多くの場合、
WORKSPACE ファイルも同様です。ただし、これらの追加の WORKSPACE ファイルは
Bazel では無視されます。特に、推移的に依存するリポジトリは
自動的に追加されます。
パッケージ
リポジトリ内のコード編成の基本単位はパッケージです。 package は、関連ファイルのコレクションと、そのファイルを 使用されます。
パッケージは、コンテナ イメージを含むディレクトリとして
BUILD または BUILD.bazel という名前の BUILD ファイル。
パッケージには、そのディレクトリ内のすべてのファイルと、その下のすべてのサブディレクトリが含まれます。
ただし、それ自体が BUILD ファイルを含むものは除きます。この定義によれば、
ファイルまたはディレクトリが 2 つの異なるパッケージの一部である可能性があります。
たとえば、次のディレクトリ ツリーには、my/app という 2 つのパッケージがあります。
サブパッケージは my/app/tests です。my/app/data はパッケージではありませんが、
パッケージ my/app に属するディレクトリです。
src/my/app/BUILD
src/my/app/app.cc
src/my/app/data/input.txt
src/my/app/tests/BUILD
src/my/app/tests/test.cc
ターゲット
パッケージはターゲットのコンテナで、パッケージの
BUILD ファイル。ほとんどのターゲットは、ファイルとルールの 2 つのプリンシパルの種類のいずれかです。
ファイルはさらに 2 種類に分類されます。通常、ソースファイルは リポジトリにチェックインしました。生成されたファイル （派生ファイルや出力ファイルと呼ばれることもあります）は、チェックインされておらず、 ソース ファイルから生成されます。
2 つ目の種類のターゲットは、ルールで宣言されます。各ルール インスタンス 一連の入力ファイルと出力ファイルのセットの関係を指定します。「 ソースファイルにすることもできますが、他のルールの出力に できます。
ルールへの入力がソースファイルか生成されたファイルかは、 重要ではないケース重要なのはそのファイルの内容だけです。この事実 を使用すると、複雑なソースファイルを、Google Cloud で生成された たとえば、大規模なインフラストラクチャを手作業で維持する負担が、 構造化ファイルの作成は面倒になり、誰かがプログラムを作成してそれを導き出します。 このファイルの使用者を変更する必要はありません。逆に、生成された ファイルは、ローカルの変更のみを含むソースファイルと簡単に置き換えることができます。
ルールへの入力には、他のルールも含めることができます。かかる Pod の正確な意味は、 非常に複雑で言語やルールに依存しますが 直感的にシンプルです。C++ ライブラリ ルール A に別の C++ ライブラリと ルール B を入力します。この依存関係の効果により、B のヘッダー ファイルが 利用可能になると、A は B のシンボルをコンパイル時に リンクされ、実行中に A は B のランタイム データを利用できます。
すべてのルールと変わらないのは、ルールによって生成されたファイルは常に ルール自体と同じパッケージです。Cloud Storage バケットにファイルを生成することはできません。 別のパッケージに含まれます。ルールの入力が別のルールから来ることは珍しくありません。 です。
パッケージ グループとは、特定の Google サービスへのユーザーのアクセスを制限することを目的とする
適用できます。パッケージ グループは、package_group 関数で定義されます。。
プロパティが 3 つあります。パッケージに含まれるパッケージのリスト、名前、
パッケージグループも参照できますそれらを参照するのは、
ルールの visibility 属性、またはルールの default_visibility 属性から
package 関数ファイルを生成したり消費したりしません。詳細
詳しくは、package_group
ドキュメントをご覧ください。
<ph type="x-smartling-placeholder"></ph> ラベル