Las reglas del lugar de trabajo se usan para extraer dependencias externas, por lo general, el código fuente ubicado fuera del repositorio principal.
Nota: Además de las reglas del lugar de trabajo nativo, Bazel también incorpora varias reglas del lugar de trabajo de Starlark, en particular las para tratar con los repositorios o archivos de Git alojados en la Web.
Reglas
bind
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 la vinculación" para ver un análisis extenso de sus problemas y alternativas. En particular, considera el uso de los atributos del repositorio repo_mapping
.
Advertencia: No se puede usar select()
en bind()
. Consulta las Preguntas frecuentes sobre los atributos configurables para obtener 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 puede considerar como un "paquete virtual" que contiene todos los destinos vinculados.
Ejemplos
Para asignar un alias a un destino, bind
en el archivo WORKSPACE. Por ejemplo, supongamos que hay un objetivo java_library
llamado //third_party/javacc-v2
. Se puede asignar un alias agregando lo siguiente al archivo WORKSPACE:
bind( name = "javacc-latest", actual = "//third_party/javacc-v2", )
Ahora los objetivos 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 dependan de //external:javacc-latest
ahora dependerán de javacc-v3 sin necesidad de editarlos.
La vinculación también se puede usar a fin de hacer que los destinos en 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 //src:openssl-lib
de destino de cc_library, puedes crear 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 relativa a la raíz del repositorio. Por ejemplo, si la definición de la regla para @my-ssl//src:openssl-lib
es similar a la siguiente:
cc_library( name = "openssl-lib", srcs = ["openssl.cc"], hdrs = ["openssl.h"], )
Entonces, las inclusiones de sign_in.cc
podrían tener el siguiente aspecto:
#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 hagan referencia a este destino en |
local_repository
local_repository(name, path, repo_mapping)
Permite vincular destinos de un directorio local. Esto significa que el repositorio actual puede usar los 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 permisos de administrador en el directorio ~/chat-app. Necesitaría una biblioteca SSL definida en otro repositorio: ~/ssl. La biblioteca SSL tiene un //src:openssl-lib
de destino.
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 que dependerá de esta biblioteca.
Argumentos
Atributos | |
---|---|
name |
Un nombre único para este destino. |
path
|
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
|
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 el repositorio actual puede definir y usar destinos desde cualquier parte del sistema de archivos.
Esta regla crea un repositorio de Bazel mediante la creación de un archivo WORKSPACE y un subdirectorio que contienen
symlinks al archivo BUILD y la ruta proporcionada. El archivo de compilación debe crear objetivos relacionados con path
. Para los directorios que ya contienen un archivo WORKSPACE y un archivo BUILD, se puede usar la regla local_repository
.
Ejemplos
Supongamos que el repositorio actual es un cliente de chat con permisos de administrador en el directorio ~/chat-app. Necesitaría una biblioteca SSL definida en otro directorio: ~/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, 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 de @my-ssl
con symlinks a /home/user/ssl.
Los objetivos pueden depender de esta biblioteca si se 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/username/Downloads/piano.jar. Podrías agregar solo ese archivo a tu compilación incluyendo lo siguiente al 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"], )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 tenga el nombre BUILD, pero puede tenerlo. (Algo similar a BUILD.new-repo-name puede funcionar bien para distinguirlo 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 se llame WORKSPACE, pero puede ser así. (Algo como WORKSPACE.new-repo-name puede 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. |