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
vincular
Ver la fuente de la reglabind(name, actual, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
Advertencia: No se recomienda usar bind(). Consulta “Considera quitar la vinculación” durante mucho tiempo
debate sobre 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. Para asignarle un alias, agrega 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
WORKSPACE y tiene un //src:openssl-lib de destino cc_library, puedes
Crea un alias para este destino con bind:
bind(
name = "openssl",
actual = "@my-ssl//src:openssl-lib",
)
Luego, en un archivo BUILD 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"],
)
Dentro de sign_in.cc y sign_in.h, se puede hacer referencia a los archivos de encabezado que expone //external:openssl mediante su ruta de acceso en relación con la raíz del repositorio. 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 |
Nombre: obligatorio. Un nombre único para este objetivo. |
actual
|
Etiqueta; el valor predeterminado es Este destino debe existir, pero puede ser cualquier tipo de regla (incluida la vinculación). Si se omite este atributo, las reglas que hacen referencia a este destino en |
local_repository
Ver el código fuente de la reglalocal_repository(name, path, repo_mapping)
Permite que se vinculen los destinos de un directorio local. Esto significa que el repositorio actual puede usar 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 los permisos de administrador en el directorio ~/chat-app. Integra
deseas usar una biblioteca SSL definida en un repositorio diferente: ~/ssl. La biblioteca de SSL tiene un //src:openssl-lib de destino.
Para agregar una dependencia a este objetivo, el usuario puede agregar las siguientes líneas a ~/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 esto
biblioteca.
Argumentos
| Atributos | |
|---|---|
name |
Nombre: obligatorio. Un nombre único para este objetivo. |
path
|
String; obligatorio. Es la ruta de acceso al directorio del repositorio local.Debe ser una ruta de acceso al directorio que contiene el archivo WORKSPACE del repositorio. La ruta de acceso puede ser absoluta o relativa al archivo WORKSPACE. |
repo_mapping
|
Diccionario: Cadena -> Cadena; el valor predeterminado es Por ejemplo, una entrada |
new_local_repository
Ver la fuente de la reglanew_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 a través de la creación de un archivo WORKSPACE y un subdirectorio que contiene
símbolos de enlace al archivo BUILD y la ruta de acceso proporcionada. El archivo de compilación debe crear objetivos relativos al
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.
Los destinos pueden depender de esta biblioteca si se agrega @my-ssl//:openssl a la biblioteca de un destino
las dependencias.
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 objetivos pueden depender de @piano//:play-music para usar piano.jar.
Argumentos
| Atributos | |
|---|---|
name |
Nombre: Obligatorio Un nombre único para este destino. |
build_file
|
Nombre: el valor predeterminado es Se debe especificar build_file o build_file_content. Este atributo es una etiqueta relacionada con el lugar de trabajo principal. No es necesario que el archivo se llame BUILD, pero puede hacerlo. (Algo como BUILD.nombre-nuevo-del-repositorio puede funcionar bien para distinguirlo de los archivos BUILD reales del repositorio). |
build_file_content
|
String; el valor predeterminado es Se debe especificar build_file o build_file_content. |
path
|
Cadena; obligatorio Una ruta en el sistema de archivos local.Puede ser absoluta o relativa al archivo WORKSPACE del repositorio principal. |
repo_mapping
|
Diccionario: Cadena -> Cadena; el valor predeterminado es Por ejemplo, una entrada |
workspace_file
|
Nombre: el valor predeterminado es Se puede especificar workspace_file o workspace_file_content, pero no ambos. Este atributo es una etiqueta relativa al espacio de trabajo principal. No es necesario que el archivo se llame WORKSPACE, pero puede hacerlo. (Algo como WORKSPACE.nombre-nuevo-del-repositorio puede funcionar bien para distinguirlo de los archivos WORKSPACE reales del repositorio). |
workspace_file_content
|
String; el valor predeterminado es Se puede especificar workspace_file o workspace_file_content, pero no ambos. |