As inscrições para a BazelCon 2024 já estão abertas.

Esta página foi traduzida pela API Cloud Translation.

Regras do Workspace

As regras do Workspace são usadas para extrair dependências externas, normalmente fora do repositório principal.

Observação:além das regras nativas do espaço de trabalho, o Bazel também incorpora vários Regras do espaço de trabalho Starlark, principalmente para lidar com repositórios Git ou arquivos hospedados na Web.

vincular

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. por muito tempo discussão sobre os problemas e as alternativas. Em particular, considere o uso de repo_mapping atributos de repositório.

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/ então 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 campo 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 atualizados, e todos os arquivos BUILD que dependem de //external:javacc-latest serão atualizados. dependem de javacc-v3 sem precisar de edição.

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 WORKSPACE e ele tiver o destino cc_library //src:openssl-lib, será possível crie 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 O //external:openssl pode ser referenciado usando o caminho em relação ao próprio repositório. raiz. Por exemplo, se a definição da regra @my-ssl//src:openssl-lib for parecida isso:

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

Name; required

Um nome exclusivo para o destino.

actual

Label; optional

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 no //external não terão acesso a essa borda de dependência. Isso é diferente de omitir bind regra completa: será um erro se uma dependência //external não tem 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 use destinos definidos neste outro diretório. Consulte a 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. Ela quiser usar uma biblioteca SSL definida em um repositório diferente: ~/ssl. A A biblioteca SSL tem um //src:openssl-lib de destino.

O usuário pode acrescentar 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 disso. 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. O caminho pode ser absoluto ou relativo ao método WORKSPACE.

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 resolução de dependência do espaço de trabalho para dependências deste repositório.

Por exemplo, uma entrada "@foo": "@bar" declara que, para qualquer momento que esse repositório depende de "@foo" (como uma dependência do "@foo//some:target"), ele vai resolver essa dependência declaração global de "@bar" ("@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 projeto repositório pode definir e usar destinos de qualquer lugar no sistema de arquivos.

Essa regra cria um repositório Bazel ao criar um arquivo e subdiretório do WORKSPACE que contém links simbólicos para o arquivo BUILD e o caminho fornecidos. O arquivo de build deve criar destinos relativos à path: Para diretórios que já contêm um arquivo WORKSPACE e um arquivo BUILD, o 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. Ela quiser 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 dependências.

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ê 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`	`Name; required` Um nome exclusivo para o destino.
`build_file`	`String; optional` 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 ser chamado BUILD, mas pode ser. (Algo como BUILD.new-repo-name pode funcionar bem para diferenciando-o dos arquivos BUILD reais do repositório.)
`build_file_content`	`String; optional` O conteúdo do arquivo BUILD deste repositório. O build_file ou o build_file_content precisa ser especificado.
`path`	`String; required` Um caminho no sistema de arquivos local. Isso 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 resolução de dependência do espaço de trabalho para dependências deste repositório. Por exemplo, uma entrada `"@foo": "@bar"` declara que, para qualquer momento que esse repositório depende de `"@foo"` (como uma dependência do `"@foo//some:target"`), ele vai resolver essa dependência declaração global de `"@bar"` (`"@bar//some:target"`).
`workspace_file`	`String; optional` 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 chamado WORKSPACE, mas pode ser. (Algo como WORKSPACE.new-repo-name pode funcionar bem para diferenciando-o dos arquivos do ESPAÇO DE TRABALHO reais do repositório.)
`workspace_file_content`	`String; optional` O conteúdo do arquivo WORKSPACE deste repositório. O workspace_file ou workspace_file_content pode ser especificado, mas não ambos.