Workspace ルールは、外部依存関係を pull するために使用されます。 ソースコードの外に出ることもできません。
注: Bazel には、ネイティブ ワークスペース ルールの他にもさまざまな Starlark のワークスペース ルール、特に対処すべきもの ウェブ上にホストされた Git リポジトリやアーカイブです。
ルール
- <ph type="x-smartling-placeholder"></ph> バインド
 - <ph type="x-smartling-placeholder"></ph> local_repository
 - <ph type="x-smartling-placeholder"></ph> new_local_repository
 
バインド
bind(name, actual, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
警告: bind() の使用はおすすめしません。バインドの削除を検討するをご覧ください。長期間
議論が交わされます。特に、kubectl の
repo_mapping
リポジトリ属性をご覧ください。
警告: select() は bind() では使用できません。詳しくは、構成可能な属性に関するよくある質問をご覧ください。
ご覧ください。
//external パッケージでターゲットにエイリアスを付与します。
//external パッケージが「normal」ではないpackage: external/ ディレクトリがありません。
  「仮想パッケージ」と考えることができます。すべてのバインドされたターゲットが含まれます。
例
ターゲットにエイリアスを付与するには、WORKSPACE ファイルでそのエイリアスを bind します。たとえば
  java_library ターゲットが
  //third_party/javacc-v2。これは、次の行を
  WORKSPACE ファイル:
bind(
    name = "javacc-latest",
    actual = "//third_party/javacc-v2",
)
ターゲットが次のものではなく //external:javacc-latest に依存するようになりました。
  //third_party/javacc-v2。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"
引数
| 属性 | |
|---|---|
name | 
        
           
 このターゲットの一意の名前。  | 
      
          actual
         | 
        
                     
 このターゲットは存在する必要がありますが、どのようなタイプのルール(バインドを含む)でも使用できます。 この属性を省略すると、  | 
      
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 | 
        
           
 このターゲットの一意の名前。  | 
      
          path
         | 
        
                     
 リポジトリのディレクトリを含むディレクトリへのパスを指定する必要があります。 WORKSPACE ファイル。パスは、メイン リポジトリの絶対パスまたは相対パスで指定できます。 WORKSPACE ファイル。  | 
      
          repo_mapping
         | 
        
                     
 たとえば、エントリ   | 
      
new_local_repository
new_local_repository(name, build_file, build_file_content, path, repo_mapping, workspace_file, workspace_file_content)
ローカル ディレクトリを Bazel リポジトリに変換できるようにします。つまり、現在の ファイル システム上のどこからでもターゲットを定義して使用できます。
このルールでは、以下を含む WORKSPACE ファイルとサブディレクトリを作成し、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",
)
これにより、/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//:play-music に依存して piano.jar を使用できるようにします。
  引数
| 属性 | |
|---|---|
name | 
        
           
 このターゲットの一意の名前。  | 
      
          build_file
         | 
        
                     
 build_file または build_file_content を指定する必要があります。 この属性は、メイン ワークスペースに対する相対的なラベルです。このファイルは必ずしも BUILD という名前ですが、その名前にすることもできます。(BUILD.new-repo-name のような名前が リポジトリの実際の BUILD ファイルと区別する必要があります)。  | 
      
          build_file_content
         | 
        
                     
 build_file または build_file_content を指定する必要があります。  | 
      
          path
         | 
        
                     
 メイン リポジトリの WORKSPACE ファイルの絶対パスまたは相対パスを指定できます。  | 
      
          repo_mapping
         | 
        
                     
 たとえば、エントリ   | 
      
          workspace_file
         | 
        
                     
 workspace_file または workspace_file_content のいずれかを指定できます。両方は指定できません。 この属性は、メイン ワークスペースに対する相対的なラベルです。このファイルは必ずしも WORKSPACE としていますが、その可能性もあります。(たとえば WORKSPACE.new-repo-name が、 リポジトリの実際の WORKSPACE ファイルと区別する必要があります)。  | 
      
          workspace_file_content
         | 
        
                     
 workspace_file または workspace_file_content のいずれかを指定できます。両方は指定できません。  |