このページでは、Bazel に精通していることを前提として、Bazel の機能を最大限に活用できるようにプロジェクトを構成するためのガイドラインとアドバイスを提供します。
全体的な目標は次のとおりです。
- きめ細かい依存関係を使用して、並列処理とインクリメンタリティを実現する。
- 依存関係を適切にカプセル化しておく。
- コードを適切に構造化してテストできるようにするため。
- 理解しやすく維持しやすいビルド構成を作成すること。
これらのガイドラインは必須ではありません。すべてのガイドラインを遵守できるプロジェクトはほとんどありません。lint の man ページには、「厳格なチェックでエラーが発生しない実際のプログラムを最初に作成した人に特別な報酬が贈られます」と記載されています。ただし、これらの原則をできるだけ多く取り入れることで、プロジェクトの読みやすさ、エラーの発生率の低下、ビルド時間の短縮が実現できます。
このページでは、この RFC で説明されている要件レベルを使用しています。
ビルドとテストの実行
プロジェクトは、安定したブランチで常に bazel build //... と bazel test //... を正常に実行できる必要があります。必要であるが特定の状況下ではビルドされないターゲット（特定のビルドフラグが必要な場合、特定のプラットフォームでビルドされない場合、ライセンス契約が必要な場合など）には、できるだけ具体的にタグを付ける必要があります（例: requires-osx）。このタグ付けにより、ターゲットを「手動」タグよりもきめ細かくフィルタリングできます。また、BUILD ファイルを検査するユーザーは、ターゲットの制限を把握できます。
サードパーティの依存関係
サードパーティの依存関係は宣言できます。
MODULE.bazelファイルでリモート リポジトリとして宣言します。- または、ワークスペース ディレクトリの
third_party/というディレクトリに配置します。
バイナリへの依存
可能な限り、すべてソースからビルドする必要があります。一般的にこれは
ライブラリの some-library.so に依存する代わりに、
BUILD ファイルを作成し、そのソースから some-library.so をビルドし、それに依存します。
あります。
常にソースからビルドすることで、互換性のないフラグまたは異なるアーキテクチャでビルドされたライブラリがビルドで使用されなくなります。ソースでのみ動作する機能もあります（カバレッジ、静的分析、動的分析など）。
バージョニング
可能な限り、すべてのコードをヘッドからビルドすることをおすすめします。バージョンを使用する必要がある場合は、ターゲット名にバージョンを含めないでください（//guava-20.0 ではなく //guava など）。この命名により、ライブラリの更新が容易になります（更新するターゲットは 1 つだけです）。また、ダイヤモンドへの依存に対する耐性も向上します。
問題: 1 つのライブラリが guava-19.0 に依存し、もう 1 つのライブラリが guava-20.0 に依存している場合、
ライブラリが 2 つの異なるバージョンに依存しようとすることになってしまいます。
両方のターゲットが 1 つの guava ライブラリを指すように、誤解を招くエイリアスを作成した場合は、
この場合、BUILD ファイルは誤解を招くことになります。
.bazelrc ファイルの使用
プロジェクト固有のオプションの場合は、workspace/.bazelrc の構成ファイルを使用します（bazelrc 形式をご覧ください）。
プロジェクトでユーザーごとのオプションをサポートしていない場合、 追加するには、次の行を追加します。
try-import %workspace%/user.bazelrc
（またはその他のファイル名）を workspace/.bazelrc
user.bazelrc を .gitignore に追加してください。
パッケージ
ビルド可能なファイルを含むディレクトリはすべてパッケージにする必要があります。BUILD の場合、
ファイルはサブディレクトリ（srcs = ["a/b/C.java"] など）内のファイルを参照します
BUILD ファイルをそのサブディレクトリに追加する必要があることが示されます。この構造が存在する時間が長くなるほど、循環依存関係が意図せず作成される可能性が高くなり、ターゲットのスコープが拡大し、リバース依存関係の更新が必要になる数が増えます。