Bazel は、次のディレクトリ ツリーで整理されたソースコードからソフトウェアをビルドします。
説明します。ワークスペース内のソースファイルはネストされた
パッケージの階層。各パッケージは、一連のパッケージが格納されたディレクトリ
関連するソースファイルの 1 つと 1 つの BUILD ファイル。BUILD ファイルで指定する
そのソースからビルドできます
ワークスペース
ワークスペースは、ソースを含むファイル システム上のディレクトリ ツリーです。
作成するソフトウェア用のファイルです。各ワークスペースには、名前を付けたテキスト ファイルが
WORKSPACE: 空であるか、以下への参照を含めることができます。
出力のビルドに必要な外部依存関係。
WORKSPACE というファイルを含むディレクトリは、
できます。そのため、Bazel は、root 権限を持つワークスペース内のディレクトリ ツリーを無視します。
これらは別のワークスペースを形成するため、WORKSPACE ファイルを含むサブディレクトリに作成されます。
Bazel は、WORKSPACE ファイルのエイリアスとして WORKSPACE.bazel ファイルもサポートしています。
両方のファイルが存在する場合は、WORKSPACE.bazel が使用されます。
リポジトリ
コードはリポジトリにまとめられます。WORKSPACE を含むディレクトリ
ファイルはメイン リポジトリのルート（@ とも呼ばれます）です。その他（社外向け）
リポジトリは、ワークスペース ルールを使用して WORKSPACE ファイルで定義されます。
Bazel にバンドルされているワークスペース ルールは、 Google Chat の [Workspace ルール] セクション Build 百科事典と、 埋め込みの Starlark リポジトリ ルール。
外部リポジトリはそれ自体がリポジトリであるため、多くの場合、
WORKSPACE ファイルも同様です。ただし、これらの追加の WORKSPACE ファイルは
Bazel では無視されます。特に、推移的に依存するリポジトリは、
自動的に追加されることはありません。
パッケージ
リポジトリ内のコード編成の基本単位はパッケージです。 関連ファイルのコレクションとそれらのファイルがどのように使用されるかの仕様です。 出力アーティファクトを生成できます。
パッケージは、BUILD という名前のファイルを含むディレクトリとして定義されます。
（または BUILD.bazel）。パッケージには、ディレクトリ内のすべてのファイルと、
ただし、その下位のすべてのサブディレクトリに
BUILD ファイル。この定義から、ファイルやディレクトリを
使用します。
たとえば、次のディレクトリ ツリーでは、
my/app とサブパッケージ my/app/tests の 2 つのパッケージがあります。
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 つ目の種類のターゲットは、ルールで宣言されます。各ルール instance は、一連の入力と一連のエントリとの間の関係を 出力ファイルです。ルールへの入力にはソースファイルを指定できますが、 他のルールの出力にもできます。
ルールへの入力がソースファイルか生成されたファイルか ほとんどの場合重要ではない重要なのはその内容 表示されます。そのため、複雑なソースファイルを ルールによって生成されたファイルで、負荷が増加したときなどに 高度に構造化されたファイルを手動で管理すると、 それを導き出すプログラムを書く人もいるでしょう。変更なし ユーザーに付与する必要があります。逆に、生成された ローカル ファイルのみを含むソースファイルと簡単に できます。
ルールへの入力には、他のルールも含めることができます。「 このような関係の正確な意味は多くの場合、かなり複雑で 言語やルールに依存しますが、直感的にはシンプルです。 ライブラリ ルール A の入力には、別の C++ ライブラリ ルール B を指定することもできます。 この依存関係の効果により、B のヘッダー ファイルが 利用可能になると、A は B のシンボルを A はリンク時にデータを使用できるようになり、B のランタイム データを A が 実行されます。
ルールによって生成されるファイルは、すべてのルールに左右されません。 ルール自体と同じパッケージに属します。そうではない 別のパッケージにファイルを生成することも可能です。これは珍しいことではありません。 ルールの入力を別のパッケージから取得する必要があります。
パッケージ グループとは、ユーザー補助機能を制限することを目的とするパッケージのセット
適用できます。パッケージ グループは、package_group 関数で定義されます。
このパッケージには、パッケージのリスト、名前、パッケージの 3 つのプロパティがあります。
他のパッケージ グループが対象になります。これらに言及できるのは、
ルールの visibility 属性または default_visibility
package 関数の属性です。ファイルを生成したり消費したりしません。
詳細については、このモジュールのコースリソースに
package_group ドキュメントをご覧ください。
<ph type="x-smartling-placeholder"></ph> ラベル