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 do 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: não recomendamos o uso de bind()
. Consulte "Considere remover a vinculação" para ver uma longa
discussão de problemas e alternativas. Em especial, considere o uso dos
atributos
de repositório
repo_mapping
.
Aviso: não é possível usar select()
em bind()
. Consulte as Perguntas frequentes sobre atributos configuráveis para
mais detalhes.
Fornece a um destino um alias no pacote //external
.
O pacote //external
não é um pacote "normal": não há um diretório externo.
Portanto, ele pode ser considerado um "pacote virtual" que contém todos os destinos vinculados.
Exemplos
Para atribuir um alias a um destino, adicione-o a bind
no arquivo WORKSPACE. Por exemplo, suponha que haja um destino java_library
chamado //third_party/javacc-v2
. Isso pode receber um alias adicionando o seguinte 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 javacc-v3 for lançado, a regra bind
poderá ser atualizada e todos os arquivos BUILD que dependem de //external:javacc-latest
agora dependerão de javacc-v3 sem precisar ser editados.
A vinculação também pode ser usada para disponibilizar destinos em repositórios externos no 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 //src:openssl-lib
da biblioteca cc, crie um alias para esse destino usando bind
:
bind( name = "openssl", actual = "@my-ssl//src:openssl-lib", )
Em seguida, em um arquivo BUILD em seu 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
for assim:
cc_library( name = "openssl-lib", srcs = ["openssl.cc"], hdrs = ["openssl.h"], )
As inclusões de sign_in.cc
terão esta aparência:
#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 saber mais.
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 ESPAÇO DE TRABALHO 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 em qualquer lugar do sistema de arquivos.
Essa regra cria um repositório do Bazel criando um arquivo do ESPAÇO DE TRABALHO e um subdiretório contendo
links simbólicos para o arquivo BUILD e o caminho fornecidos. O arquivo de build vai criar destinos relativos ao
path
. Para diretórios que já contêm um arquivo do ESPAÇO DE TRABALHO e um arquivo BUILD, a
regra local_repository
pode ser usada.
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"], )
Depois, adicione as seguintes linhas a ~/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 seu 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"], )Então, 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 precisa ser especificado. Esse atributo é um rótulo relativo ao espaço de trabalho principal. O arquivo não precisa ser nomeado 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 precisa ser especificado. |
path
|
Esse valor pode ser absoluto ou relativo ao arquivo de ESPAÇO DE TRABALHO do repositório principal. |
repo_mapping
|
Por exemplo, uma entrada |
workspace_file
|
É possível especificar workspace_file ou workspace_file_content, mas não ambos. Esse atributo é um rótulo relativo ao espaço de trabalho principal. O nome do arquivo não precisa ser ESPAÇO DE TRABALHO, mas pode ser. Algo como WORKSPACE.new-repo-name pode funcionar bem para diferenciá-lo dos arquivos do ESPAÇO DE TRABALHO do repositório. |
workspace_file_content
|
É possível especificar workspace_file ou workspace_file_content, mas não ambos. |