Las reglas del espacio de trabajo se usan para incorporar dependencias externas, por lo general, código fuente ubicado fuera del repositorio principal.
Nota: Además de las reglas nativas del espacio de trabajo, Bazel también incorpora varias reglas del espacio de trabajo de Starlark, en particular, aquellas que se ocupan de los repositorios o archivos de Git alojados en la Web.
Reglas
vincular
Ver código 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 el enlace" para obtener un análisis detallado
de sus problemas y alternativas. En particular, considera el uso de
repo_mapping
atributos de repositorio.
Advertencia: No se puede usar select() en bind(). Consulta las Preguntas frecuentes sobre atributos configurables para
obtener más detalles.
Le da un alias a un destino en el paquete //external.
El paquete //external no es un paquete "normal": no hay un directorio externo/,
por lo que se puede considerar como un "paquete virtual" que contiene todos los destinos vinculados.
Ejemplos
Para darle un alias a un destino, bind en el archivo WORKSPACE. Por ejemplo,
supongamos que hay un destino java_library llamado
//third_party/javacc-v2. Para crear 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 actualizar la regla bind y todos los archivos BUILD que dependen de //external:javacc-latest ahora
dependerán de javacc-v3 sin necesidad de editarlos.
También se puede usar el enlace para que los destinos de repositorios externos estén disponibles para tu espacio de trabajo.
Por ejemplo, si hay un repositorio remoto llamado @my-ssl importado en el
WORKSPACE archivo y tiene un destino cc_library //src:openssl-lib, puedes
crear un alias para este destino con bind:
bind(
name = "openssl",
actual = "@my-ssl//src:openssl-lib",
)
Luego, en un archivo BUILD de tu espacio 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 expuestos por
//external:openssl con su ruta de acceso relativa a la raíz del repositorio. Por ejemplo, si la definición de regla para @my-ssl//src:openssl-lib se ve de la siguiente manera:
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 destino. |
actual
|
Etiqueta; el valor predeterminado es Este destino debe existir, pero puede ser cualquier tipo de regla (incluido el enlace). Si se omite este atributo, las reglas que hacen referencia a este destino en |
local_repository
Ver código fuente de la reglalocal_repository(name, path, repo_mapping)
Permite vincular destinos desde un directorio local. Esto significa que el repositorio actual puede usar destinos definidos en este otro directorio. Consulta la sección de vinculación para obtener más detalles.
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. La
biblioteca SSL tiene un destino //src:openssl-lib.
El usuario puede agregar una dependencia en este destino agregando 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 esta
biblioteca.
Argumentos
| Atributos | |
|---|---|
name |
Nombre; obligatorio Un nombre único para este destino. |
path
|
String; obligatorio 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 del repositorio principal. |
repo_mapping
|
Diccionario: String -> String; el valor predeterminado es Por ejemplo, una entrada |
new_local_repository
Ver código fuente de la reglanew_local_repository(name, build_file, build_file_content, path, repo_mapping, workspace_file, workspace_file_content)
Permite convertir un directorio local 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 creando un archivo WORKSPACE y un subdirectorio que contiene
vínculos simbólicos al archivo BUILD y la ruta de acceso proporcionados. El archivo de compilación debe crear destinos relativos a la
path. Para los directorios que ya contienen un archivo WORKSPACE y un archivo BUILD, se puede usar la
local_repository regla.
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 contenga lo siguiente:
java_library(
name = "openssl",
srcs = glob(['*.java'])
visibility = ["//visibility:public"],
)
Luego, pueden 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 que se vinculará simbólicamente a /home/user/ssl.
Los destinos pueden depender de esta biblioteca agregando @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/Downloads/piano.jar. Para agregar 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",
)
Y crea el siguiente archivo BUILD.piano:
java_import(
name = "play-music",
jars = ["piano.jar"],
visibility = ["//visibility:public"],
)
@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 relativa al espacio de trabajo principal. No es necesario que el archivo se llame BUILD, pero puede hacerlo. (Algo como BUILD.new-repo-name 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
|
String; obligatorio Una ruta de acceso en el sistema de archivos local.Puede ser absoluta o relativa al archivo WORKSPACE del repositorio principal. |
repo_mapping
|
Diccionario: String -> String; 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.new-repo-name 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. |