Para conferir a documentação da versão estável, use o menu suspenso "Documentos com controle de versão". A visualização padrão reflete a versão mais recente em HEAD.

Esta página foi traduzida pela API Cloud Translation.

Regras do Workspace

Informar um problema Ver código-fonte

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.

bind

Ver origem da regra

bind(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

Name; required

Um nome exclusivo para esse destino.

actual

Label; optional

O destino a ser alias.

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 //external simplesmente não verão essa borda de dependência. Isso é diferente de omitir completamente a regra bind. É um erro se uma dependência //external não tiver uma regra bind associada.

repositório_local

Ver origem da regra

local_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

Name; required

Um nome exclusivo para esse destino.

path

String; required

O caminho para o diretório do repositório local.

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

Dictionary: String -> String; optional

Um dicionário do nome do repositório local para o nome do repositório global. Isso permite controles sobre a resolução de dependências do espaço de trabalho para dependências desse repositório.

Por exemplo, uma entrada "@foo": "@bar" declara que, a qualquer momento, esse repositório depende de "@foo" (como uma dependência em "@foo//some:target"), mas na verdade ele precisa resolver essa dependência dentro de "@bar" declarado "@bar//some:target" globalmente.

new_local_repository

Ver origem da regra

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 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`	`Name; required` Um nome exclusivo para esse destino.
`build_file`	`String; optional` Um arquivo a ser usado como arquivo BUILD para esse diretório. 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`	`String; optional` O conteúdo do arquivo BUILD para este repositório. build_file ou build_file_content precisam ser especificados.
`path`	`String; required` Um caminho no sistema de arquivos local. Ele pode ser absoluto ou relativo ao arquivo WORKSPACE do repositório principal.
`repo_mapping`	`Dictionary: String -> String; optional` Um dicionário do nome do repositório local para o nome do repositório global. Isso permite controles sobre a resolução de dependências do espaço de trabalho para dependências desse repositório. Por exemplo, uma entrada `"@foo": "@bar"` declara que, a qualquer momento, esse repositório depende de `"@foo"` (como uma dependência em `"@foo//some:target"`), mas na verdade ele precisa resolver essa dependência dentro de `"@bar"` declarado `"@bar//some:target"` globalmente.
`workspace_file`	`String; optional` O arquivo a ser usado como o arquivo de espaço de trabalho para este repositório. 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`	`String; optional` O conteúdo do arquivo WORKSPACE deste repositório. Workspace_file ou workspace_file_content podem ser especificados, mas não ambos.