Workspace のルール

ワークスペース ルールは、外部依存関係（通常はメイン リポジトリの外にあるソースコード）を取り込むために使用されます。

注: Bazel には、ネイティブのワークスペース ルールに加えて、さまざまな Starlark ワークスペース ルールも埋め込まれています。特に、ウェブ上でホストされている Git リポジトリやアーカイブを扱うルールが対象となります。

ルール

• バインド
• local_repository
• new_local_repository

bind

bind(name, actual, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

警告: bind() の使用はおすすめしません。バインドの削除を検討するには、問題と代替手段について詳しく説明しています。特に、repo_mapping リポジトリ属性の使用を検討してください。

警告: select() は bind() では使用できません。詳しくは、構成可能な属性に関するよくある質問をご覧ください。

ターゲットに //external パッケージのエイリアスを指定します。

//external パッケージは「通常の」パッケージではありません。external/ ディレクトリは存在しないため、バインドされたすべてのターゲットを含む「仮想パッケージ」と考えることができます。

例

ターゲットにエイリアスを指定するには、WORKSPACE ファイルでエイリアスを bind します。たとえば、//third_party/javacc-v2 という java_library ターゲットがあるとします。WORKSPACE ファイルに次の行を追加することで、エイリアスを設定できます。

bind(
    name = "javacc-latest",
    actual = "//third_party/javacc-v2",
)

ターゲットが //third_party/javacc-v2 ではなく //external:javacc-latest に依存できるようになりました。javacc-v3 がリリースされると、bind ルールを更新できるようになります。//external:javacc-latest に依存するすべての BUILD ファイルは、編集することなく javacc-v3 に依存するようになります。

Bind は、外部リポジトリ内のターゲットをワークスペースで使用できるようにするためにも使用できます。たとえば、WORKSPACE ファイルにインポートされた @my-ssl という名前のリモート リポジトリがあり、そのリポジトリに cc_library ターゲット //src:openssl-lib がある場合は、bind を使用してこのターゲットのエイリアスを作成できます。

bind(
    name = "openssl",
    actual = "@my-ssl//src:openssl-lib",
)

次に、ワークスペースの BUILD ファイルで、バインドされたターゲットを次のように使用できます。

cc_library(
    name = "sign-in",
    srcs = ["sign_in.cc"],
    hdrs = ["sign_in.h"],
    deps = ["//external:openssl"],
)

sign_in.cc と sign_in.h 内では、//external:openssl によって公開されるヘッダー ファイルは、リポジトリのルートからの相対パスを使用して参照できます。たとえば、@my-ssl//src:openssl-lib のルール定義が次のような場合、

cc_library(
    name = "openssl-lib",
    srcs = ["openssl.cc"],
    hdrs = ["openssl.h"],
)

sign_in.cc のインクルードは次のようになります。

#include "sign_in.h"
#include "src/openssl.h"

引数

属性
name	Name; required このターゲットの一意の名前。
actual	Label; optional エイリアスを設定するターゲット。 このターゲットは存在している必要がありますが、任意のタイプのルール（バインドを含む）を指定できます。 この属性を省略すると、//external でこのターゲットを参照するルールでは、この依存関係エッジが表示されなくなります。これは、bind ルールを完全に省略した場合とは異なることに注意してください。//external 依存関係に bind ルールが関連付けられていない場合は、エラーになります。

local_repository

local_repository(name, path, repo_mapping)

ローカル ディレクトリのターゲットをバインドできるようにします。つまり、現在のリポジトリは、このディレクトリで定義されたターゲットを使用できます。詳しくは、バインドのセクションをご覧ください。

例

現在のリポジトリがチャット クライアントで、ルートが ~/chat-app ディレクトリであるとします。このクライアントでは、別のリポジトリ ~/ssl で定義されている SSL ライブラリを使用することを希望しています。SSL ライブラリにはターゲット //src:openssl-lib があります。

このターゲットへの依存関係を追加するには、~/chat-app/WORKSPACE に次の行を追加します。

local_repository(
    name = "my-ssl",
    path = "/home/user/ssl",
)

ターゲットは、このライブラリに依存する依存関係として @my-ssl//src:openssl-lib を指定します。

引数

属性
name	Name; required このターゲットの一意の名前。
path	String; required ローカル リポジトリのディレクトリへのパス。 これは、リポジトリの WORKSPACE ファイルを含むディレクトリへのパスにする必要があります。パスは、メイン リポジトリの WORKSPACE ファイルへの絶対パスまたは相対パスのいずれかになります。
repo_mapping	Dictionary: String -> String; optional ローカル リポジトリ名からグローバル リポジトリ名への辞書。これにより、このリポジトリの依存関係のワークスペース依存関係の解決を制御できます。 たとえば、エントリ "@foo": "@bar" は、このリポジトリが "@foo" に依存しているときは常に（"@foo//some:target" への依存関係など）、グローバルに宣言された "@bar"（"@bar//some:target"）内でその依存関係を実際に解決することを宣言します。

new_local_repository

new_local_repository(name, build_file, build_file_content, path, repo_mapping, workspace_file, workspace_file_content)

ローカル ディレクトリを Bazel リポジトリに変換できるようにします。つまり、現在のリポジトリでは、ファイル システムの任意の場所からターゲットを定義して使用できます。

このルールでは、指定された BUILD ファイルとパスへのシンボリック リンクを含む WORKSPACE ファイルとサブディレクトリを作成して、Bazel リポジトリを作成します。ビルドファイルでは、path を基準とする相対パスを作成する必要があります。WORKSPACE ファイルと BUILD ファイルがすでに含まれているディレクトリの場合は、local_repository ルールを使用できます。

例

現在のリポジトリがチャット クライアントで、ルートが ~/chat-app ディレクトリであるとします。このリポジトリでは、別のディレクトリ ~/ssl で定義されている SSL ライブラリを使用することが考えられます。

ユーザーは、以下を含む SSL ライブラリ（~/chat-app/BUILD.my-ssl）の BUILD ファイルを作成することで、依存関係を追加できます。

java_library(
    name = "openssl",
    srcs = glob(['*.java'])
    visibility = ["//visibility:public"],
)

次に、~/chat-app/WORKSPACE に次の行を追加します。

new_local_repository(
    name = "my-ssl",
    path = "/home/user/ssl",
    build_file = "BUILD.my-ssl",
)

これにより、/home/user/ssl にシンボリック リンクする @my-ssl リポジトリが作成されます。ターゲットをこのライブラリに依存させるには、@my-ssl//:openssl をターゲットの依存関係に追加します。

new_local_repository を使用して、ディレクトリだけでなく単一のファイルを含めることもできます。たとえば、/home/username/Downloads/piano.jar に jar ファイルがあるとします。WORKSPACE ファイルに次の行を追加すると、このファイルのみをビルドに追加できます。

new_local_repository(
    name = "piano",
    path = "/home/username/Downloads/piano.jar",
    build_file = "BUILD.piano",
)

次の BUILD.piano ファイルを作成します。

java_import(
    name = "play-music",
    jars = ["piano.jar"],
    visibility = ["//visibility:public"],
)

この場合、ターゲットは piano.jar を使用するために @piano//:play-music に依存できます。

引数

属性
name	Name; required このターゲットの一意の名前。
build_file	String; optional このディレクトリの BUILD ファイルとして使用するファイル。 build_file または build_file_content を指定する必要があります。 この属性は、メイン ワークスペースに関連するラベルです。ファイル名を BUILD にする必要はありませんが、BUILD という名前でもかまいません。（リポジトリの実際の BUILD ファイルと区別するには、BUILD.new-repo-name などが適切です）。
build_file_content	String; optional このリポジトリの BUILD ファイルの内容。 build_file または build_file_content を指定する必要があります。
path	String; required ローカル ファイル システム上のパス。 絶対パスを指定することも、メイン リポジトリの WORKSPACE ファイルを基準とする相対パスを指定することもできます。
repo_mapping	Dictionary: String -> String; optional ローカル リポジトリ名からグローバル リポジトリ名への辞書。これにより、このリポジトリの依存関係のワークスペース依存関係の解決を制御できます。 たとえば、エントリ "@foo": "@bar" は、このリポジトリが "@foo" に依存しているときは常に（"@foo//some:target" への依存関係など）、グローバルに宣言された "@bar"（"@bar//some:target"）内でその依存関係を実際に解決することを宣言します。
workspace_file	String; optional このリポジトリの WORKSPACE ファイルとして使用するファイル。 workspace_file と workspace_file_content のどちらか一方のみ指定できます。 この属性は、メイン ワークスペースに関連するラベルです。ファイル名を WORKSPACE にする必要はありませんが、指定できます。（リポジトリの実際の WORKSPACE ファイルと区別するには、WORKSPACE.new-repo-name のような名前が適している可能性があります）。
workspace_file_content	String; optional このリポジトリの WORKSPACE ファイルの内容。 workspace_file と workspace_file_content のどちらか一方のみ指定できます。