Para obtener documentación sobre versiones estables, usa el menú desplegable "Documentos con versiones". La vista predeterminada refleja la versión más reciente en el encabezado.

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

Reglas de Workspace

Informar un problema Ver el código fuente

Las reglas de Workspace se usan para extraer dependencias externas, por lo general, el código fuente ubicado fuera del repositorio principal.

Nota: Además de las reglas de espacio de trabajo nativas, Bazel también incorpora varias reglas de espacio de trabajo de Starlark, en particular, para lidiar con los repositorios de Git o archivos alojados en la Web.

bind

Ver 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 “Cómo quitar la vinculación” para obtener un análisis detallado de los problemas y las alternativas. En particular, considera el uso de 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 información.

Otorga un destino a un alias en el paquete //external.

El paquete //external no es un paquete "normal": no tiene un directorio externo/ directorio, por lo que se puede considerar como un "paquete virtual" que contiene todos los destinos vinculados.

Ejemplos

Para asignarle un alias a un destino, usa bind en el archivo WORKSPACE. Por ejemplo, supongamos que hay un objetivo java_library llamado //third_party/javacc-v2. Para agregar un alias a esto, 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, la regla bind se puede actualizar y todos los archivos BUILD dependiendo de //external:javacc-latest ahora dependerán de javacc-v3 sin necesidad de editarlo.

La vinculación también se puede usar con el fin de que los destinos de los 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 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 en su 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"],
)

En sign_in.cc y sign_in.h, se puede hacer referencia a los archivos de encabezado expuestos por //external:openssl mediante la ruta de acceso relativa a la raíz de su 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

Name; required

Un nombre único para esta orientación.

actual

Label; optional

El destino al que se le asignará un alias.

Este objetivo 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 esta arista de dependencia. Ten en cuenta que esto es diferente de omitir por completo la regla bind; es un error si una dependencia //external no tiene una regla bind asociada.

repositorio_local

Ver fuente de la regla

local_repository(name, path, repo_mapping)

Permite vincular objetivos de 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 permisos de administrador en el directorio ~/chat-app. Le gustaría usar una biblioteca SSL que esté definida en un repositorio diferente: ~/ssl. La biblioteca SSL tiene un //src:openssl-lib de destino.

El usuario puede agregar una dependencia a este destino agregando las siguientes líneas a ~/chat-app/WORKSPACE:

local_repository(
    name = "my-ssl",
    path = "/home/user/ssl",
)

Los objetivos especificarían @my-ssl//src:openssl-lib como una dependencia para depender de esta biblioteca.

Argumentos

Atributos

name

Name; required

Un nombre único para esta orientación.

path

String; required

La ruta de acceso al directorio del repositorio local.

Debe ser una ruta 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

Dictionary: String -> String; optional

Un diccionario del nombre del repositorio local al nombre del repositorio global Esto permite controlar la resolución de dependencias del lugar de trabajo para las dependencias de este repositorio.

Por ejemplo, una entrada "@foo": "@bar" declara que, en cualquier momento, este repositorio depende de "@foo" (como una dependencia en "@foo//some:target"), que debe resolver esa dependencia dentro de un "@bar" ("@bar//some:target") declarado de manera global.

nuevo_repositorio_local

Ver 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 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 contiene symlinks al archivo BUILD y la ruta de acceso proporcionadas. El archivo de compilación debe crear destinos relacionados con path. Para los directorios que ya contienen un archivo WORKSPACE y un archivo BUILD, se puede usar la regla local_repository.

Ejemplos

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 @my-ssl que se vincula symlink a /home/user/ssl. Los destinos pueden depender de esta biblioteca. Para ello, 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. Para ello, 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"],
)

Luego, los destinos pueden depender de @piano//:play-music para usar piano.jar.

Argumentos

Atributos
`name`	`Name; required` Un nombre único para esta orientación.
`build_file`	`String; optional` Un archivo para usar como archivo BUILD para este directorio. Se debe especificar build_file o build_file_content. Este atributo es una etiqueta relativa al lugar de trabajo principal. No es necesario que el archivo se llame BUILD, pero puede serlo. (Algo como BUILD.new-repo-name puede funcionar bien para distinguirlo de los archivos BUILD reales del repositorio).
`build_file_content`	`String; optional` El contenido del archivo BUILD para este repositorio. Se debe especificar build_file o build_file_content.
`path`	`String; required` Una ruta en el sistema de archivos local. Puede ser un valor absoluto o relativo al archivo WORKSPACE del repositorio principal.
`repo_mapping`	`Dictionary: String -> String; optional` Un diccionario del nombre del repositorio local al nombre del repositorio global Esto permite controlar la resolución de dependencias del lugar de trabajo para las dependencias de este repositorio. Por ejemplo, una entrada `"@foo": "@bar"` declara que, en cualquier momento, este repositorio depende de `"@foo"` (como una dependencia en `"@foo//some:target"`), que debe resolver esa dependencia dentro de un `"@bar"` (`"@bar//some:target"`) declarado de manera global.
`workspace_file`	`String; optional` El archivo que se usará como archivo WORKSPACE para este repositorio. Se pueden especificar workspace_file o workspace_file_content, pero no ambos. Este atributo es una etiqueta relativa al lugar de trabajo principal. No es necesario que el archivo se llame WORKSPACE, pero puede serlo. (Algo como WORKSPACE.new-repo-name puede funcionar bien para distinguirlo de los archivos WORKSPACE reales del repositorio).
`workspace_file_content`	`String; optional` El contenido del archivo WORKSPACE para este repositorio. Se pueden especificar workspace_file o workspace_file_content, pero no ambos.