このページでは、読者が Bazel に精通していることを前提としています。また、Bazel の機能を最大限に活用するためのプロジェクト構成に関するガイドラインとアドバイスを提供します。
全体的な目標は次のとおりです。
- きめ細かい依存関係を使用して並列処理とインクリメンタリティを実現できる場合。
- 依存関係を適切にカプセル化するため
- コードを適切に構造化し、テスト可能にするため。
- 理解しやすく、メンテナンスしやすいビルド構成を作成すること。
これらのガイドラインは要件ではありません。すべてのプロジェクトに準拠できるプロジェクトはほとんどありません。lint のマニュアル ページに「厳密なチェックでエラーを発生させない実際のプログラムを作成したユーザーに、特別な報酬が提示されます」ただし、これらの原則をできるだけ多く取り入れることで、プロジェクトが読みやすく、間違いが減り、ビルドの時間が短縮されます。
このページでは、こちらの RFC で説明されている要件レベルを使用します。
ビルドとテストの実行
プロジェクトは、安定版ブランチで bazel build //... と bazel test //... を常に正常に実行できる必要があります。必要だが特定の状況ではビルドしないターゲット（特定のビルドフラグが必要な、特定のプラットフォーム上にビルドしない、ライセンス契約が必要など）は、可能な限り具体的なタグ（「requires-osx」など）でタグ付けする必要があります。タグ付けにより、「手動」タグよりもきめ細かくターゲットをフィルタリングでき、BUILD ファイルを調べて、ターゲットの制限の内容を把握できます。
サードパーティの依存関係
次のようなサードパーティの依存関係を宣言できます。
- または、
WORKSPACEファイルでリモート リポジトリとして宣言します。 - または、ワークスペース ディレクトリの下の
third_party/というディレクトリに配置します。
バイナリに依存
可能な限り、すべてソースからビルドする必要があります。つまり、通常はライブラリ some-library.so に依存するのではなく、BUILD ファイルを作成し、そのソースから some-library.so をビルドし、そのターゲットに依存します。
常にソースからビルドすることで、互換性のないフラグや別のアーキテクチャを使用してビルドされたライブラリがビルドで使用されなくなります。また、ソースでのみ機能するカバレッジ、静的分析、動的分析などの機能もあります。
バージョニング
可能な限り、ヘッドからすべてのコードをビルドすることをおすすめします。バージョンを使用する必要がある場合は、ターゲット名にバージョンを含めないでください（たとえば、//guava-20.0 ではなく //guava）。これにより、ライブラリを更新しやすくなります（更新が必要なターゲットは 1 つだけです）。また、ダイヤモンド依存関係の問題に対する耐性も高くなります。一方のライブラリが guava-19.0 に依存し、一方のライブラリが 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 ファイルを追加する必要があることを示しています。この構造が存在する期間が長いほど、循環依存関係が誤って作成され、ターゲットのスコープが拡大し、更新しなければならない逆方向の依存関係の数が増えます。