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.

Regras

• vinculação
• local_repository
• new_local_repository

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

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

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

Argumentos