Reglas del lugar de trabajo

Las reglas de Workspace se usan para extraer dependencias externas, por lo general, código fuente ubicado fuera del repositorio principal.

Nota: Además de las reglas de espacio de trabajo nativas, Bazel también incorpora varias reglas de espacio de trabajo de Starlark, en particular, aquellas para tratar con repositorios de git o archivos alojados en la Web.

Reglas

• bind
• local_repository
• new_local_repository

vincular

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

Advertencia: No se recomienda el uso de bind(). Consulta "Considera quitar bind" para obtener una explicación detallada de sus problemas y alternativas. En particular, considera el uso de repo_mapping atributos del repositorio.

Advertencia: No se puede usar select() en bind(). Consulta las Preguntas frecuentes sobre los atributos configurables para más detalles.

Le asigna un alias a un objetivo en el paquete //external.

El paquete //external no es un paquete “normal”: no hay un directorio externo, por lo que se puede considerar un “paquete virtual” que contiene todos los destinos vinculados.

Ejemplos

Para asignar un alias a un objetivo, bind en el archivo WORKSPACE. Por ejemplo, supongamos que hay un objetivo java_library llamado //third_party/javacc-v2. A esto se le puede asignar un alias agregando lo siguiente al Archivo WORKSPACE:

bind(
    name = "javacc-latest",
    actual = "//third_party/javacc-v2",
)

Ahora los destinos pueden depender de //external:javacc-latest en lugar de //third_party/javacc-v2 Si se lanza javacc-v3, se puede usar la regla bind actualizado, y todos los archivos BUILD que dependen de //external:javacc-latest ahora estarán disponibles depender de javacc-v3 sin necesidad de editarse.

También se puede usar para que los destinos de los repositorios externos estén disponibles para tu lugar de trabajo. Por ejemplo, si hay un repositorio remoto llamado @my-ssl importado en el archivo WORKSPACE y tiene un objetivo cc_library //src:openssl-lib, puedes crear un alias para este objetivo con bind:

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

Luego, en un archivo de COMPILACIÓN en tu lugar de trabajo, el destino vinculado se puede usar de la siguiente manera:

cc_library(
    name = "sign-in",
    srcs = ["sign_in.cc"],
    hdrs = ["sign_in.h"],
    deps = ["//external:openssl"],
)

En sign_in.cc y sign_in.h, los archivos de encabezado expuestos por Se puede hacer referencia a //external:openssl usando su ruta de acceso en relación con su repositorio raíz. Por ejemplo, si la definición de la regla para @my-ssl//src:openssl-lib se ve así:

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

Entonces, las inclusiones de sign_in.cc podrían verse de la siguiente manera:

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

Argumentos

Atributos
name	Name; required Un nombre único para este objetivo.
actual	Label; optional El objetivo al que se le asignará un alias. Este objetivo debe existir, pero puede ser cualquier tipo de regla (incluida la vinculación). Si se omite este atributo, las reglas que se refieren a este objetivo en //external simplemente no verán este borde de dependencia. Ten en cuenta que esto es diferente a omitir Regla bind completamente: es un error si una dependencia //external no tiene una regla bind asociada.

local_repository

local_repository(name, path, repo_mapping)

Permite que se vinculen los destinos de un directorio local. Esto significa que el repositorio actual puede usa los destinos definidos en este otro directorio. Consulta el vínculo para obtener más información.

Ejemplos

Supongamos que el repositorio actual es un cliente de chat con permisos de administrador en el directorio ~/chat-app. Le gustaría usar una biblioteca SSL que se define en un repositorio diferente: ~/ssl. La biblioteca de SSL tiene un //src:openssl-lib de destino.

El usuario puede agregar una dependencia en este destino agregando las siguientes líneas al ~/chat-app/WORKSPACE:

local_repository(
    name = "my-ssl",
    path = "/home/user/ssl",
)

Los destinos especificarían @my-ssl//src:openssl-lib como una dependencia para depender de esta biblioteca.

Argumentos

Atributos
name	Name; required Un nombre único para este objetivo.
path	String; required La ruta de acceso al directorio del repositorio local. Debe ser una ruta de acceso al directorio que contiene el archivo WORKSPACE. La ruta de acceso puede ser absoluta o relativa al archivo WORKSPACE.
repo_mapping	Dictionary: String -> String; optional Un diccionario del nombre del repositorio local al nombre del repositorio global. Esto permite controlar la resolución de dependencias de Workspace para las dependencias de este repositorio. Por ejemplo, una entrada "@foo": "@bar" declara que, cada vez que este repositorio dependa de "@foo" (como una dependencia de "@foo//some:target"), en realidad debería resolver esa dependencia dentro de "@bar" declarado de forma global ("@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 un directorio local se convierta en un repositorio de Bazel. Esto significa que el repositorio actual puede definir y usar destinos desde cualquier lugar del sistema de archivos.

Esta regla crea un repositorio de Bazel mediante la creación de un archivo y un subdirectorio WORKSPACE que contienen symlinks al archivo de COMPILACIÓN y a la ruta proporcionada. El archivo de compilación debe crear destinos en relación con path. Para los directorios que ya contienen un archivo WORKSPACE y un archivo BUILD, el archivo Se puede usar la regla local_repository.

Ejemplos

Supongamos que el repositorio actual es un cliente de chat con raíz en el directorio ~/chat-app. Le gustaría usar una biblioteca SSL que se define en un directorio diferente: ~/ssl.

El usuario puede agregar una dependencia creando un archivo BUILD para la biblioteca SSL. (~/chat-app/BUILD.my-ssl) que contiene:

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

Luego, puede agregar las siguientes líneas a ~/chat-app/WORKSPACE:

new_local_repository(
    name = "my-ssl",
    path = "/home/user/ssl",
    build_file = "BUILD.my-ssl",
)

Esto creará un repositorio @my-ssl con symlinks a /home/user/ssl. Para que los destinos dependan de esta biblioteca, agrega @my-ssl//:openssl a las dependencias de un destino.

También puedes usar new_local_repository para incluir archivos individuales, no solo directorios. Por ejemplo, supongamos que tienes un archivo JAR en /home/nombredeusuario/Descargas/piano.jar. Para agregar solo ese archivo a tu compilación, agrega lo siguiente a tu archivo WORKSPACE:

new_local_repository(
    name = "piano",
    path = "/home/username/Downloads/piano.jar",
    build_file = "BUILD.piano",
)

Crea el siguiente archivo BUILD.piano:

java_import(
    name = "play-music",
    jars = ["piano.jar"],
    visibility = ["//visibility:public"],
)

Luego, los destinos pueden depender de @piano//:play-music para usar piano.jar.

Argumentos

Atributos
name	Name; required Un nombre único para este destino.
build_file	String; optional Es un archivo que se usará como archivo BUILD para este directorio. Se debe especificar build_file o build_file_content. Este atributo es una etiqueta relativa al espacio de trabajo principal. No es necesario que el archivo llamada BUILD, pero pueden serlo. (Algo como BUILD.new-repo-name podría funcionar bien distinguiéndolo de los archivos BUILD reales del repositorio).
build_file_content	String; optional El contenido del archivo Build de este repositorio. Se debe especificar build_file o build_file_content.
path	String; required Es una ruta de acceso en el sistema de archivos local. Puede ser absoluta o relativa al archivo WORKSPACE del repositorio principal.
repo_mapping	Dictionary: String -> String; optional Un diccionario que va del nombre del repositorio local al nombre del repositorio global. Esto permite controlar resolución de dependencias de Workspace para las dependencias de este repositorio. Por ejemplo, una entrada "@foo": "@bar" declara que, en todo momento, este repositorio depende de "@foo" (como una dependencia de "@foo//some:target"), debería resolver esa dependencia en un declarada a nivel global "@bar" ("@bar//some:target").
workspace_file	String; optional Es el archivo que se usará como archivo WORKSPACE para este repositorio. Se puede especificar workspace_file o workspace_file_content, pero no ambos. Este atributo es una etiqueta relacionada con el lugar de trabajo principal. No es necesario que el archivo llamada WORKSPACE, pero sí pueden serlo. (Algo como WORKSPACE.new-repo-name podría funcionar bien para distinguirlo de los archivos WORKSPACE reales del repositorio).
workspace_file_content	String; optional Es el contenido del archivo WORKSPACE de este repositorio. Se puede especificar workspace_file o workspace_file_content, pero no ambos.