Workspace のルール

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

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

ルール

• bind
• local_repository
• new_local_repository

bind

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

警告: bind() の使用はおすすめしません。問題点と代替案については、「bind の削除を検討する」をご覧ください。特に、 repo_mapping リポジトリ属性の使用を検討してください。

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

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

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

例

ターゲットにエイリアスを付与するには、 bind WORKSPACE ファイルでします。たとえば、 `java_library` というターゲットがあるとします。 `//third_party/javacc-v2`これは、 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 を使用して、外部リポジトリのターゲットをワークスペースで使用できるようにすることもできます。 たとえば、 @my-ssl という名前のリモート リポジトリが WORKSPACE ファイルにインポートされ、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"

引数

local_repository

local_repository(name, path, repo_mapping)

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

例

現在のリポジトリがチャット クライアントで、ディレクトリ ~/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 を指定します。

引数

new_local_repository

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

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

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

例

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

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

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",
)

これにより、@my-ssl リポジトリが /home/user/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"],
)

引数