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 de espaço de trabalho nativas, o Bazel também incorpora várias regras de espaço de trabalho do Starlark, principalmente as para lidar com repositórios git ou arquivos hospedados na Web.
Regras
bind
Exibir origem da regrabind(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 discussão
longa sobre os problemas e as alternativas. Especificamente, considere 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
mais detalhes.
Dá um alias ao destino no pacote //external
.
O pacote //external
não é um pacote "normal": não há um diretório externo/. Por isso, 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
. Para atribuir um alias, adicione 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 o javacc-v3 for lançado, a regra bind
poderá ser atualizada e todos os arquivos BUILD que dependem de //external:javacc-latest
dependerão 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 //src:openssl-lib
, será possível 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"], )
Em 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 @my-ssl//src:openssl-lib
for assim:
cc_library( name = "openssl-lib", srcs = ["openssl.cc"], hdrs = ["openssl.h"], )
Então, as inclusões de sign_in.cc
podem ficar assim:
#include "sign_in.h" #include "src/openssl.h"
Argumentos
Atributos | |
---|---|
name |
Nome, obrigatório Um nome exclusivo para o destino. |
actual
|
Rótulo; o padrão é Esse 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
Exibir origem da regralocal_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. Ele quer 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 nesse 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 |
Nome, obrigatório Um nome exclusivo para o destino. |
path
|
String, obrigatório O caminho para o diretório do repositório local.Esse 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
|
Dicionário: String -> String. O padrão é Por exemplo, uma entrada |
new_local_repository
Exibir origem da regranew_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 subdiretório do WORKSPACE contendo
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 WORKSPACE 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. Ele quer 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 as seguintes linhas a ~/chat-app/WORKSPACE:
new_local_repository( name = "my-ssl", path = "/home/user/ssl", build_file = "BUILD.my-ssl", )
Isso criará um repositório @my-ssl
com links simbólicos para /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. É possível
adicionar apenas esse arquivo ao build adicionando o seguinte ao arquivo WORKSPACE:
new_local_repository( name = "piano", path = "/home/username/Downloads/piano.jar", build_file = "BUILD.piano", )
E criando 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 |
Nome, obrigatório Um nome exclusivo para o destino. |
build_file
|
Nome; o padrão é 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 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
|
String. O padrão é O build_file ou o build_file_content precisa ser especificado. |
path
|
String, obrigatório Um caminho no sistema de arquivos local.Isso pode ser absoluto ou relativo ao arquivo WORKSPACE do repositório principal. |
repo_mapping
|
Dicionário: String -> String. O padrão é Por exemplo, uma entrada |
workspace_file
|
Nome; o padrão é O 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 ser nomeado como WORKSPACE, mas pode ser. Algo como WORKSPACE.new-repo-name pode funcionar bem para distingui-lo dos arquivos WORKSPACE reais do repositório. |
workspace_file_content
|
String. O padrão é O workspace_file ou workspace_file_content pode ser especificado, mas não ambos. |