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, em particular aquelas para lidar com repositórios ou arquivos do Git hospedados na Web.

Regras

• vincular
• local_repository
• new_local_repository

vincular

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

Aviso: não é recomendado usar bind(). Consulte "Considerar a remoção da vinculação" para uma discussão detalhada sobre os problemas e 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 de 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 dar um alias de destino, bind no arquivo WORKSPACE. Por exemplo, suponha que haja um destino java_library chamado //third_party/javacc-v2. Isso pode ser 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 o javacc-v3 for lançado, a bind regra poderá ser atualizada e todos os arquivos BUILD que dependem de //external:javacc-latest agora vão depender do javacc-v3 sem precisar ser editados.

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 WORKSPACE arquivo e ele tiver um destino cc_library //src:openssl-lib, você pode 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 referenciados usando o caminho relativo à raiz do repositório. Por exemplo, se a definição de 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 podem ser assim:

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

Argumentos

local_repository

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, com raiz no diretório ~/chat-app. Ele gostaria de usar uma biblioteca SSL definida em um repositório diferente: ~/ssl. A biblioteca SSL tem um destino //src:openssl-lib.

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 dessa 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 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 WORKSPACE e um subdiretório que contém links simbólicos para o arquivo BUILD e o caminho fornecido. 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 local_repository regra pode ser usada.

Exemplos

Suponha que o repositório atual seja um cliente de chat, com raiz no diretório ~/chat-app. Ele gostaria de 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) que contém:

java_library(
    name = "openssl",
    srcs = glob(['*.java'])
    visibility = ["//visibility:public"],
)

Em seguida, eles podem adicionar 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 que tem links simbólicos 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 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