工作区规则用于拉取外部依赖项,这些依赖项通常位于主代码库之外的源代码。
注意:除了原生工作区规则之外,Bazel 还嵌入了各种 Starlark 工作区规则,尤其是用于处理 Web 上托管的 Git 代码库或归档的规则。
规则
绑定
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", )
现在,目标可以依赖于 //external:javacc-latest
,而不是 //third_party/javacc-v2
。如果发布了 javacc-v3,则可以更新 bind
规则,并且所有依赖于 //external:javacc-latest
的 BUILD 文件现在都将依赖于 javacc-v3,而无需进行修改。
binder 还可用于将外部代码库中的目标提供给您的工作区。例如,如果在 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 可能如下所示:
#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 文件和子目录(其中包含指向 BUILD 文件和给定路径的符号链接)来创建 Bazel 代码库。build 文件应创建相对于 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 文件,从而仅将该文件添加到您的 build 中:
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,但不能同时指定两者。 |