Esta página foi traduzida pela API Cloud Translation.

Regras do Workspace

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 nativas do espaço de trabalho, o Bazel também incorpora várias regras do espaço de trabalho do Starlark, especialmente aquelas para lidar com repositórios git ou arquivos hospedados na Web.

bind

bind(name, actual, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

Aviso: não recomendamos o uso de bind(). Consulte "Considere remover a vinculação" para ver uma longa discussão de problemas e alternativas. Em especial, considere o uso dos atributos de repositório repo_mapping.

Aviso: não é possível usar select() em bind(). Consulte as Perguntas frequentes sobre atributos configuráveis para mais detalhes.

Fornece a um destino um alias 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 atribuir um alias a um destino, adicione-o a bind no arquivo WORKSPACE. Por exemplo, suponha que haja um destino java_library chamado //third_party/javacc-v2. Isso pode receber um alias adicionando 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 que dependem de //external:javacc-latest agora dependerão de javacc-v3 sem precisar ser editados.

A vinculação também pode ser usada para disponibilizar destinos em repositórios externos no 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 da biblioteca cc, crie um alias para esse destino usando bind:

bind(
    name = "openssl",
    actual = "@my-ssl//src:openssl-lib",
)

Em seguida, em um arquivo BUILD em 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"],
)

Dentro de 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 para @my-ssl//src:openssl-lib for assim:

cc_library(
    name = "openssl-lib",
    srcs = ["openssl.cc"],
    hdrs = ["openssl.h"],
)

As inclusões de sign_in.cc terão esta aparência:

#include "sign_in.h"
#include "src/openssl.h"

Argumentos

Atributos

name

Name; required

Um nome exclusivo para o destino.

actual

Label; optional

O destino que receberá o alias.

O 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: será um erro se uma dependência //external não tiver uma regra bind associada.

local_repository

local_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 saber mais.

Exemplos

Suponha que o repositório atual seja um cliente de chat com acesso root no diretório ~/chat-app. É recomendável 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 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

Name; required

Um nome exclusivo para o destino.

path

String; required

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 ESPAÇO DE TRABALHO do repositório principal.

repo_mapping

Dictionary: String -> String; optional

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, sempre que esse repositório depender de "@foo" (como uma dependência de "@foo//some:target"), ele precisará resolver essa dependência dentro de "@bar" declarado globalmente ("@bar//some:target").

new_local_repository

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 em qualquer lugar do sistema de arquivos.

Essa regra cria um repositório do Bazel criando um arquivo do ESPAÇO DE TRABALHO e um subdiretório contendo links simbólicos para o arquivo BUILD e o caminho fornecidos. O arquivo de build vai criar destinos relativos ao path. Para diretórios que já contêm um arquivo do ESPAÇO DE TRABALHO 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. É recomendável 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, adicione 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 vinculado a /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 seu arquivo do ESPAÇO DE TRABALHO:

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"],
)

Então, os destinos podem depender de @piano//:play-music para usar piano.jar.

Argumentos

Atributos
`name`	`Name; required` Um nome exclusivo para o destino.
`build_file`	`String; optional` Um arquivo para usar como arquivo BUILD para esse diretório. 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 ser nomeado 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; optional` O conteúdo do arquivo BUILD para este repositório. O build_file ou o build_file_content precisa ser especificado.
`path`	`String; required` Um caminho no sistema de arquivos local. Esse valor pode ser absoluto ou relativo ao arquivo de ESPAÇO DE TRABALHO do repositório principal.
`repo_mapping`	`Dictionary: String -> String; optional` 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, sempre que esse repositório depender de `"@foo"` (como uma dependência de `"@foo//some:target"`), ele precisará resolver essa dependência dentro de `"@bar"` declarado globalmente (`"@bar//some:target"`).
`workspace_file`	`String; optional` O arquivo a ser usado como o ESPAÇO DE TRABALHO deste repositório. É 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 nome do arquivo não precisa ser ESPAÇO DE TRABALHO, mas pode ser. Algo como WORKSPACE.new-repo-name pode funcionar bem para diferenciá-lo dos arquivos do ESPAÇO DE TRABALHO do repositório.
`workspace_file_content`	`String; optional` O conteúdo do arquivo do ESPAÇO DE TRABALHO deste repositório. É possível especificar workspace_file ou workspace_file_content, mas não ambos.