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 de espaço de trabalho nativas, 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

Exibir 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 "Considere remover a vinculaçã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 mais detalhes.

Dá um alias ao destino no pacote //external.

O pacote //external não é um pacote "normal": não há um diretório externo/. Por isso, ele pode ser considerado um "pacote virtual" que contém todos os destinos vinculados.

Exemplos

Para atribuir 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 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 dependerão de 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 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 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 @my-ssl//src:openssl-lib for assim:

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

Então, as inclusões 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 o destino.

actual

Rótulo; o padrão é None

O destino que vai receber o 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. Observe que 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

Exibir origem da regra

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 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 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 o destino.

path

String, obrigatório

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

Esse 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 é {}.

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 deste 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 no "@bar" declarado globalmente ("@bar//some:target").

new_local_repository

Exibir 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 do 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 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 acesso root 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 criará um repositório @my-ssl com 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. É possível 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 o destino.
`build_file`	Nome; o padrão é `None`. Um arquivo para usar como um arquivo BUILD para o 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 ter o nome 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. O padrão é `""`. O conteúdo do arquivo BUILD deste repositório. O build_file ou o build_file_content precisa ser especificado.
`path`	String, obrigatório Um caminho no sistema de arquivos local. Isso pode ser absoluto ou relativo ao arquivo WORKSPACE do repositório principal.
`repo_mapping`	Dicionário: String -> String. O padrão é `{}`. 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 deste 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 no `"@bar"` declarado globalmente (`"@bar//some:target"`).
`workspace_file`	Nome; o padrão é `None`. O arquivo a ser usado como o arquivo de ESPAÇO DE TRABALHO para este repositório. O workspace_file ou workspace_file_content pode ser especificado, 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 distingui-lo dos arquivos WORKSPACE reais do repositório.
`workspace_file_content`	String. O padrão é `""`. O conteúdo do arquivo WORKSPACE deste repositório. O workspace_file ou workspace_file_content pode ser especificado, mas não ambos.