As regras do espaço de trabalho são usadas para extrair dependências externas, normalmente o código-fonte localizado fora do repositório principal.
Observação:além das regras nativas do espaço de trabalho, o Bazel também incorpora várias regras de espaço de trabalho do Starlark, especialmente aquelas para lidar com repositórios git ou arquivos hospedados na Web.
Regras
bind
bind(name, actual, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
Aviso: o uso de bind()
não é recomendado. Consulte Considere remover a vinculação para ver uma longa
discussão sobre problemas e alternativas. Considere principalmente o uso de
atributos
de repositório
repo_mapping
.
Aviso: select()
não pode ser usado em bind()
. Consulte as Perguntas frequentes sobre atributos configuráveis para
ver mais detalhes.
Fornece um alias ao destino no pacote //external
.
O pacote //external
não é um pacote "normal": não há diretório externo/, então ele pode ser considerado um "pacote virtual" que contém todos os destinos vinculados.
Exemplos
Para atribuir um alias a um destino, use bind
no arquivo WORKSPACE. Por exemplo,
suponha que haja um destino java_library
chamado
//third_party/javacc-v2
. Ele pode receber um alias adicionando o seguinte código ao arquivo
WORKSPACE:
bind( name = "javacc-latest", actual = "//third_party/javacc-v2", )
Agora, os destinos podem depender de //external:javacc-latest
em vez de //third_party/javacc-v2
. Se a javacc-v3 for lançada, a regra bind
poderá ser atualizada, e todos os arquivos BUILD que dependem de //external:javacc-latest
vão depender de javacc-v3 sem precisar ser editados.
A vinculação também pode ser usada para disponibilizar destinos em repositórios externos para seu espaço de trabalho.
Por exemplo, se houver um repositório remoto chamado @my-ssl
importado no arquivo WORKSPACE e ele tiver um destino cc_library de destino //src:openssl-lib
, você poderá criar um alias para esse destino usando bind
:
bind( name = "openssl", actual = "@my-ssl//src:openssl-lib", )
Em seguida, em um arquivo BUILD no espaço de trabalho, o destino vinculado pode ser usado da seguinte maneira:
cc_library( name = "sign-in", srcs = ["sign_in.cc"], hdrs = ["sign_in.h"], deps = ["//external:openssl"], )
Dentro de sign_in.cc
e sign_in.h
, os arquivos principais expostos por
//external:openssl
podem ser referenciados usando o caminho em relação à raiz do
repositório. Por exemplo, se a definição da regra para @my-ssl//src:openssl-lib
tiver esta aparência:
cc_library( name = "openssl-lib", srcs = ["openssl.cc"], hdrs = ["openssl.h"], )
As inclusões de sign_in.cc
vão ficar assim:
#include "sign_in.h" #include "src/openssl.h"
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para o destino. |
actual
|
O destino precisa existir, mas pode ser qualquer tipo de regra (incluindo vinculação). Se esse atributo for omitido, as regras que se referem a esse destino em |
local_repository
local_repository(name, path, repo_mapping)
Permite que destinos de um diretório local sejam vinculados. Isso significa que o repositório atual pode usar destinos definidos nesse outro diretório. Consulte a seção de vinculação para mais detalhes.
Exemplos
Suponha que o repositório atual seja um cliente de chat, com acesso root no diretório ~/chat-app. É recomendável usar uma biblioteca SSL definida em um repositório diferente: ~/ssl. A biblioteca SSL tem um //src:openssl-lib
de destino.
O usuário pode adicionar uma dependência a esse destino adicionando as seguintes linhas a ~/chat-app/WORKSPACE:
local_repository( name = "my-ssl", path = "/home/user/ssl", )
Os destinos especificariam @my-ssl//src:openssl-lib
como uma dependência para depender dessa
biblioteca.
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para o destino. |
path
|
Precisa ser um caminho para o diretório que contém o arquivo WORKSPACE do repositório. O caminho pode ser absoluto ou relativo ao arquivo WORKSPACE do repositório principal. |
repo_mapping
|
Por exemplo, uma entrada |
new_local_repository
new_local_repository(name, build_file, build_file_content, path, repo_mapping, workspace_file, workspace_file_content)
Permite que um diretório local seja transformado em um repositório do Bazel. Isso significa que o repositório atual pode definir e usar destinos de qualquer lugar no sistema de arquivos.
Essa regra cria um repositório do Bazel criando um arquivo e um subdiretório do ESPAÇO DE TRABALHO com
links simbólicos para o arquivo BUILD e o caminho fornecidos. O arquivo de build precisa criar destinos relativos ao
path
. Para diretórios que já contêm um arquivo de ESPAÇO DE TRABALHO e um arquivo BUILD, é possível usar a
regra local_repository
.
Exemplos
Suponha que o repositório atual seja um cliente de chat, com acesso root no diretório ~/chat-app. É recomendável usar uma biblioteca SSL definida em um diretório diferente: ~/ssl.
O usuário pode adicionar uma dependência criando um arquivo BUILD para a biblioteca SSL (~/chat-app/BUILD.my-ssl) contendo:
java_library( name = "openssl", srcs = glob(['*.java']) visibility = ["//visibility:public"], )
Em seguida, ele pode adicionar estas linhas ao arquivo ~/chat-app/WORKSPACE:
new_local_repository( name = "my-ssl", path = "/home/user/ssl", build_file = "BUILD.my-ssl", )
Isso vai criar um repositório @my-ssl
vinculado a /home/user/ssl.
Os destinos podem depender dessa biblioteca adicionando @my-ssl//:openssl
às dependências
de um destino.
Você também pode usar new_local_repository
para incluir arquivos únicos, não apenas
diretórios. Por exemplo, suponha que você tenha um arquivo jar em /home/username/Downloads/piano.jar. Você
pode adicionar apenas esse arquivo ao build adicionando o seguinte ao arquivo do ESPAÇO DE TRABALHO:
new_local_repository( name = "piano", path = "/home/username/Downloads/piano.jar", build_file = "BUILD.piano", )
Crie o seguinte arquivo BUILD.piano:
java_import( name = "play-music", jars = ["piano.jar"], visibility = ["//visibility:public"], )Os destinos podem depender de
@piano//:play-music
para usar piano.jar.
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para o destino. |
build_file
|
O build_file ou o build_file_content precisam ser especificados. Esse atributo é um rótulo relativo ao espaço de trabalho principal. Esse arquivo não precisa ter o nome BUILD, mas pode ser. Algo como BUILD.new-repo-name pode funcionar bem para distingui-lo dos arquivos BUILD reais do repositório. |
build_file_content
|
O build_file ou o build_file_content precisam ser especificados. |
path
|
Esse valor pode ser absoluto ou relativo ao arquivo ESPAÇO DE TRABALHO do repositório principal. |
repo_mapping
|
Por exemplo, uma entrada |
workspace_file
|
Workspace_file ou workspace_file_content pode ser especificado, mas não ambos. Esse atributo é um rótulo relativo ao espaço de trabalho principal. O arquivo não precisa ter o nome WORKSPACE, mas pode ser. Algo como WORKSPACE.new-repo-name pode funcionar bem para diferenciá-lo dos arquivos WORKSPACE reais do repositório. |
workspace_file_content
|
Workspace_file ou workspace_file_content pode ser especificado, mas não ambos. |