Reglas del lugar de trabajo

Las reglas del espacio de trabajo se usan para incorporar dependencias externas, que suelen ser 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 de espacio de trabajo de Starlark, en particular, las que se relacionan con los repositorios o archivos de Git 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 "Consider removing bind" para ver un análisis detallado de sus problemas y alternativas. En particular, considera el uso de los atributos del repositorio repo_mapping.

Advertencia: select() no se puede usar en bind(). Consulta las Preguntas frecuentes sobre los atributos configurables para obtener más detalles.

Le asigna 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 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 destino de java_library llamado //third_party/javacc-v2. Esto se puede aliasar 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 actualizar la regla bind y todos los archivos BUILD que dependen de //external:javacc-latest ahora dependerán de javacc-v3 sin necesidad de editarse.

También se puede usar bind para que los destinos de repositorios externos estén disponibles en 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"],
)

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

local_repository

local_repository(name, path, repo_mapping)

Permite que se vinculen 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, ubicado en el directorio ~/chat-app. Le gustaría usar una biblioteca SSL que se define en otro repositorio: ~/ssl. La biblioteca de 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 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 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 a la ruta de acceso proporcionados. El archivo de compilación debe crear destinos relativos a 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, ubicado 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 si agregan @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 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",
)

Y crea el siguiente archivo BUILD.piano:

java_import(
    name = "play-music",
    jars = ["piano.jar"],
    visibility = ["//visibility:public"],
)

Argumentos