Se usó la API de Cloud Translation para traducir esta página.

Reglas del lugar de trabajo

Las reglas del lugar de trabajo se usan para extraer dependencias externas, que, por lo general, son 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 aquellas para manejar repositorios o archivos de Git alojados en la Web.

bind

Ver la fuente de la regla

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 acceder a un análisis prolongado de sus problemas y alternativas. En particular, considera el uso de 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 lo 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 objetivo java_library llamado //third_party/javacc-v2. Puedes asignarle un alias si agregas 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, la regla bind se puede actualizar, y todos los archivos BUILD que dependan de //external:javacc-latest ahora dependerán de javacc-v3 sin necesidad de editarlos.

Bind también se puede usar para que los destinos en repositorios externos estén disponibles en tu lugar 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 mediante 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 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

Label; el valor predeterminado es None

El objetivo al que se le asignará un alias.

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 //external simplemente no verán este perímetro de dependencia. Ten en cuenta que esto es diferente de omitir la regla bind por completo: es un error si una dependencia //external no tiene una regla bind asociada.

local_repository

Ver la fuente de la regla

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. Desea usar una biblioteca SSL definida en un repositorio diferente: ~/ssl. La biblioteca SSL tiene un //src:openssl-lib de destino.

Para agregar una dependencia en este destino, 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

Atributos

name

Nombre (obligatorio)

Un nombre único para este destino.

path

String; obligatoria

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 puede ser absoluta o relativa al archivo WORKSPACE del repositorio principal.

repo_mapping

Diccionario: String -> String; el valor predeterminado es {}

Un diccionario que va desde el nombre del repositorio local hasta el nombre del repositorio global. Esto permite controles sobre la resolución de dependencias del lugar de trabajo para las dependencias de este repositorio.

Por ejemplo, una entrada "@foo": "@bar" declara que, para cada momento, este repositorio depende de "@foo" (como una dependencia de "@foo//some:target"), en realidad, debe resolver esa dependencia dentro de "@bar" declarado globalmente ("@bar//some:target").

new_local_repository

Ver la fuente de la regla

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 objetivos desde cualquier parte del sistema de archivos.

Esta regla crea un repositorio de Bazel mediante la creación de un archivo y subdirectorio WORKSPACE 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 que tiene permisos de administrador en el directorio ~/chat-app y que desea usar una biblioteca SSL definida en un directorio diferente: ~/ssl.

El usuario puede agregar una dependencia si crea 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 destinos 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. Puedes agregar solo ese archivo a tu compilación si agregas lo siguiente al archivo WORKSPACE:

new_local_repository(
    name = "piano",
    path = "/home/username/Downloads/piano.jar",
    build_file = "BUILD.piano",
)

Y creando el siguiente archivo BUILD.piano:

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

Entonces, los objetivos pueden depender de @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 `None` Un archivo para usar como archivo BUILD para este directorio. 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 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 `""` El contenido del archivo BUILD para este repositorio Se debe especificar build_file o build_file_content.
`path`	String; obligatoria Una ruta en el sistema de archivos local. Puede ser absoluto o relativo al archivo WORKSPACE del repositorio principal.
`repo_mapping`	Diccionario: String -> String; el valor predeterminado es `{}` Un diccionario que va desde el nombre del repositorio local hasta el nombre del repositorio global. Esto permite controles sobre la resolución de dependencias del lugar de trabajo para las dependencias de este repositorio. Por ejemplo, una entrada `"@foo": "@bar"` declara que, para cada momento, este repositorio depende de `"@foo"` (como una dependencia de `"@foo//some:target"`), en realidad, debe resolver esa dependencia dentro de `"@bar"` declarado globalmente (`"@bar//some:target"`).
`workspace_file`	Nombre; el valor predeterminado es `None` El archivo que se usará como archivo WORKSPACE para este repositorio. 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 tenga el nombre 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`	String; el valor predeterminado es `""` El contenido del archivo WORKSPACE de este repositorio. Se puede especificar workspace_file o workspace_file_content, pero no ambos.