As regras do espaço de trabalho são usadas para extrair dependências externas, normalmente código-fonte localizado fora do repositório principal.
Observação:além das regras de espaço de trabalho nativo, 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
Ver 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 "Remover remoçã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
ver detalhes.
Fornece um alias a um destino 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 dar 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 criar 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 javacc-v3 for lançado, a regra bind
poderá ser
atualizada, e todos os arquivos BUILD, dependendo de //external:javacc-latest
, agora
dependerão de javacc-v3 sem precisar ser editado.
A vinculação também pode ser usada para disponibilizar destinos em repositórios externos ao 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
de cc_library, 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 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"], )
Em sign_in.cc
e sign_in.h
, os arquivos de cabeçalho expostos por //external:openssl
podem ser referidos usando o caminho deles 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
ficam assim:
#include "sign_in.h" #include "src/openssl.h"
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para esse destino. |
actual
|
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 |
repositório_local
Ver origem da regralocal_repository(name, path, repo_mapping)
Permite que os 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 e tenha acesso root ao diretório ~/chat-app. Ele quer usar uma biblioteca SSL definida em um repositório diferente: ~/ssl. A
biblioteca SSL tem como destino //src:openssl-lib
.
O usuário pode adicionar uma dependência a este 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 a fim de depender dessa
biblioteca.
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para esse destino. |
path
|
Ele 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
Ver 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 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 arquivos WORKSPACE e BUILD, a
regra local_repository
pode ser usada.
Exemplos
Suponha que o repositório atual seja um cliente de chat e tenha acesso root ao 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"], )
Depois, ele pode adicionar estas 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
que vincula links para /home/user/ssl.
Os destinos podem depender dessa biblioteca adicionando @my-ssl//:openssl
às dependências
de um destino.
Também é possível 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 seu build adicionando o seguinte ao arquivo WORKSPACE:
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 esse destino. |
build_file
|
build_file ou build_file_content precisam ser especificados. Esse atributo é um rótulo relativo ao espaço de trabalho principal. O arquivo não precisa ser chamado BUILD, mas pode ser. Algo como o BUILD.new-repo-name pode funcionar bem para diferenciá-lo dos arquivos BUILD reais do repositório. |
build_file_content
|
build_file ou build_file_content precisam ser especificados. |
path
|
Ele pode ser absoluto ou relativo ao arquivo WORKSPACE do repositório principal. |
repo_mapping
|
Por exemplo, uma entrada |
workspace_file
|
Workspace_file ou workspace_file_content podem ser especificados, mas não ambos. Esse atributo é um rótulo relativo ao espaço de trabalho principal. O arquivo não precisa ser chamado 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 podem ser especificados, mas não ambos. |