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 del espacio de trabajo nativo, Bazel también incorpora varias Reglas de Starlark de Workspace, en particular las destinadas a gestionar con repositorios Git o archivos alojados en la Web.
Reglas
vincular
bind(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.
Otorga a un objetivo un alias en el paquete //external
.
El paquete //external
no es un paquete "normal" : no hay un directorio externo/,
por lo que se lo puede considerar un “paquete virtual” que contiene todos los destinos vinculados.
Ejemplos
Para asignarle un alias a un destino, usa 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.
Bind también se puede usar para que los destinos en repositorios externos estén disponibles para tu espacio 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"], )
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
es similar a lo siguiente:
esto:
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 |
Un nombre único para este destino. |
actual
|
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
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 los permisos de administrador en el directorio ~/chat-app. Integra
deseas usar una biblioteca SSL definida en un repositorio diferente: ~/ssl. El
La biblioteca SSL tiene un destino //src:openssl-lib
.
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 esto
biblioteca.
Argumentos
Atributos | |
---|---|
name |
Un nombre único para este destino. |
path
|
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
|
Por ejemplo, una entrada |
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 la configuración puedes definir y usar objetivos desde cualquier parte 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 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 los permisos de administrador en el directorio ~/chat-app. Integra deseas usar una biblioteca SSL definida 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
dependencias.
También puedes usar new_local_repository
para incluir archivos individuales, no solo
directorios. Por ejemplo, supongamos que tienes un archivo jar en /inicio/nombredeusuario/Descargas/piano.jar. Tú
podrías agregar solo ese archivo a tu compilación agregando 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 |
Un nombre único para este destino. |
build_file
|
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 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
|
Se debe especificar build_file o build_file_content. |
path
|
Puede ser absoluto o relativo al archivo WORKSPACE del repositorio principal. |
repo_mapping
|
Por ejemplo, una entrada |
workspace_file
|
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
|
Se puede especificar workspace_file o workspace_file_content, pero no ambos. |