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 del lugar de trabajo nativo, Bazel también incorpora varias reglas del lugar de trabajo de Starlark, en particular las que se usan 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 el vínculo" para obtener una explicación detallada de sus problemas y alternativas. En particular, considera el uso de los atributos de repositorio repo_mapping.

Advertencia: No se puede usar select() en bind(). Consulta las Preguntas frecuentes sobre los atributos configurables para obtener 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 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 dependen de //external:javacc-latest ahora dependerán de javacc-v3 sin necesidad de editarlos.

También se puede usar para que los destinos de los repositorios externos estén disponibles para tu espacio de trabajo. Por ejemplo, si hay un repositorio remoto llamado @my-ssl importado en el archivo WORKSPACE 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"],
)

En sign_in.cc y sign_in.h, puedes hacer referencia a los archivos de encabezado expuestos por //external:openssl con 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

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 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. 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.

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 esta biblioteca.

Argumentos

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 a través de la creación de un archivo WORKSPACE y un subdirectorio que contienen símbolos de enlace al archivo BUILD y la ruta de acceso proporcionada. El archivo de compilación debe crear objetivos relacionados con path. En el caso de 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 la raíz en el directorio ~/chat-app, y desea 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 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 @my-ssl con symlinks a /home/user/ssl. Los objetivos pueden depender de esta biblioteca si agregas @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 /inicio/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"],
)

Argumentos