As regras do Workspace são usadas para extrair dependências externas, geralmente 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, em particular aquelas que lidam com repositórios ou arquivos git hospedados na Web.
Regras
vincular
Acessar a 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 o bind para uma discussão longa
sobre os problemas e as alternativas. Em particular, considere o uso de
atributos do 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 a um alvo no pacote //external
.
O pacote //external
não é um pacote "normal": não há um 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, 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
agora dependerão de javacc-v3 sem precisar ser editados.
O bind também pode ser usado 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 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 referenciados usando o caminho relativo à raiz do
repositório. Por exemplo, se a definição de regra para @my-ssl//src:openssl-lib
for semelhante a esta:
cc_library( name = "openssl-lib", srcs = ["openssl.cc"], hdrs = ["openssl.h"], )
Em seguida, os elementos incluídos 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 essa segmentação. |
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
Acessar a 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 Vincular 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 a esse destino adicionando as linhas a seguir 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 essa segmentação. |
path
|
String; obrigatório O caminho para o diretório do repositório local.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 em qualquer lugar do sistema de arquivos.
Essa regra cria um repositório do Bazel ao criar um arquivo WORKSPACE e um subdiretório contendo
links simbólicos para o arquivo BUILD e o caminho fornecido. 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 raiz 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 vai criar um repositório @my-ssl
que cria links simbólicos para /home/user/ssl.
Os destinos podem depender dessa biblioteca adicionando @my-ssl//:openssl
às dependências
do 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 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 essa segmentação. |
build_file
|
Nome; o padrão é É preciso especificar build_file ou build_file_content. Esse atributo é um rótulo relativo ao espaço de trabalho principal. O arquivo não precisa ser nomeado como BUILD, mas pode ser. Algo como BUILD.new-repo-name pode funcionar bem para diferenciá-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.Ele 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 é É 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 arquivo não precisa ser nomeado como 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
|
String; o padrão é É possível especificar workspace_file ou workspace_file_content, mas não ambos. |