このページでは、Bazel に精通していることを前提としています。 Bazel の機能を最大限に活用するためのプロジェクト構成についてのアドバイスを提供します。
全体的な目標は次のとおりです。
- きめ細かい依存関係を使用して、並列処理とインクリメンタリティを実現する。
- 依存関係を適切にカプセル化しておく。
- コードを適切に構造化し、テストしやすくするため。
- 理解しやすく維持しやすいビルド構成を作成すること。
このガイドラインは要件ではなく、少数のプロジェクトは できます。lint のマニュアル ページに記載されているように、「特別な特典が贈られます」 エラーを発生させない実際のプログラムを 指示を出します。ただし、これらの原則をできるだけ多く取り入れることで、 プロジェクトが読みやすくなり、エラーが発生しにくくなり、ビルド時間を短縮できます。
このページでは、前述の要件レベルについて説明します。 こちらの RFC をご覧ください。
ビルドとテストの実行
プロジェクトでは、常に bazel build //... を実行し、
安定版ブランチで bazel test //... が正常に記述されました。必要なターゲット
ただし、特定の状況（特定のビルドを必要とする、
特定のプラットフォーム上に構築されていない、ライセンス契約が必要など）に
可能な限り具体的にタグ付けします（「requires-osx」など）。この
タグ設定を使用すると、
「手動」BUILD ファイルを検査すると、その内容が
ターゲットの制限と同じです。
サードパーティの依存関係
サードパーティの依存関係は宣言できます。
WORKSPACEファイルでリモート リポジトリとして宣言します。- または、ワークスペース ディレクトリの下の
third_party/というディレクトリに配置します。
バイナリへの依存
可能な限り、すべてソースからビルドする必要があります。一般的にこれは
ライブラリの some-library.so に依存する代わりに、
BUILD ファイルを作成し、そのソースから some-library.so をビルドし、それに依存します。
あります。
常にソースからビルドすることで、ビルドに使用されているライブラリが 互換性のないフラグまたは異なるアーキテクチャでビルドされました。また、 カバレッジ、静的分析、動的分析などの一部の機能は、 ソースで作業します。
バージョニング
可能な限り、すべてのコードをヘッドからビルドすることを優先します。新しいバージョンを
ターゲット名にバージョンを含めないでください（例: //guava、
//guava-20.0 ではない）。この名前にすると、ライブラリの更新が簡単になります（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 ファイルをそのサブディレクトリに追加する必要があることが示されます。また、
この構造が存在すると、依存関係が循環する可能性が高くなります。
不注意に作成された場合、ターゲットの範囲はクリープし、
更新する必要があります。