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, 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. 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 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
. É possível criar um alias adicionando o seguinte ao arquivo
WORKSPACE:
bind( name = "javacc-latest", actual = "//third_party/javacc-v2", )
Agora as metas 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
vão depender do 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 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 neste outro diretório. Consulte a seção Vincular para mais detalhes.
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 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 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
Acessar a 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 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
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 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"], )
@piano//:play-music
para usar o piano.jar.
Argumentos
Atributos | |
---|---|
name |
Nome: obrigatório Um nome exclusivo para o destino. |
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 chamado de 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 é É preciso especificar build_file ou build_file_content. |
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. |