Definiciones comunes

Informar un problema Ver fuente Por la noche · 7.2 · 7.1 · 7.0 · 6.5 · 6.4

En esta sección, se definen varios términos y conceptos comunes a muchas funciones o reglas de compilación.

Contenido

Asignación de token de shell de Bourne

Ciertos atributos de cadena de algunas reglas se dividen en varios de acuerdo con las reglas de asignación de token del shell de Bourne: los espacios sin comillas delimitan las palabras separadas, y las palabras se usan comillas dobles y barras inversas para evitar la asignación de token.

Aquellos atributos sujetos a esta asignación de token son se indica explícitamente como tal en sus definiciones en este documento.

Atributos sujetos a "Marca" expansión variable y shell de Bourne la asignación de token se usan normalmente para pasar opciones arbitrarias compiladores y otras herramientas. Algunos ejemplos de estos atributos son cc_library.copts y java_library.javacopts. Juntas, estas sustituciones permiten un una sola variable de cadena para expandirse a una lista específica de la configuración de palabras de opciones.

Expansión de etiquetas

Algunos atributos de cadena de unas pocas reglas están sujetos a etiquetas. expansión: si esas cadenas contienen una etiqueta válida como como //mypkg:target, y esa etiqueta es una declarado como requisito previo de la regla actual, se expande al nombre de ruta del archivo representado por el objetivo //mypkg:target

Algunos ejemplos de atributos incluyen genrule.cmd y cc_binary.linkopts Los detalles pueden variar significativamente en en cada caso, sobre temas como si las etiquetas relativas expandido; cómo se expanden las etiquetas que se expanden a varios archivos se tratan, etc. Consulta la documentación de atributos de reglas para información específica.

Atributos típicos definidos por la mayoría de las reglas de compilación

En esta sección, se describen los atributos que definen muchas reglas de compilación, pero no del todo.

Atributo Descripción
data

Lista de etiquetas; el valor predeterminado es []

Archivos que necesita esta regla en el tiempo de ejecución. Puede enumerar destinos de archivos o de reglas. Generales permite cualquier objetivo.

Las salidas y los archivos de ejecución predeterminados de los objetivos en el atributo data debería aparecer en el área *.runfiles de cualquier ejecutable que sea salida o tiene una dependencia del entorno de ejecución en este destino. Esto puede incluir datos binarios o archivos binarios que se usan cuando la capa de srcs. Consulta la dependencias de datos para obtener más información sobre cómo depender y usar los archivos de datos.

Las reglas nuevas deben definir un atributo data si se procesan. que pueden usar otras entradas en el entorno de ejecución. Reglas funciones de implementación también debe completar los campos runfiles de los archivos de salida y runfiles de cualquier atributo data y runfiles de cualquier atributo de dependencia que proporcione el código fuente o las dependencias del entorno de ejecución.

deps

Lista de etiquetas; el valor predeterminado es []

Dependencias del destino. Por lo general, solo debe enumerar los objetivos de la regla. (Sin embargo, algunas reglas permiten que los archivos se enumeren directamente en deps, esta se deben evitar siempre que sea posible).

Por lo general, las reglas específicas de un idioma limitan los destinos enumerados a aquellos con proveedores específicos.

La semántica precisa de lo que significa que un objetivo dependa de otro mediante Las deps son específicas del tipo de regla y las reglas específicas la documentación entra en más detalle. Para las reglas que procesan código fuente, deps generalmente especifica las dependencias de código que usa el código en srcs

Por lo general, se usa una dependencia deps para permitir que un módulo use definidos en otro módulo escrito en el mismo lenguaje de programación y compilarse por separado. Las dependencias entre lenguajes también se permiten casos: Por ejemplo, un destino java_library puede depender del código de C++. en un destino cc_library, mostrando este último en el atributo deps. Consulta la definición de dependencias para obtener más información.

licenses

Lista de cadenas; no configurable; el valor predeterminado es ["none"]

Una lista de cadenas de tipo de licencia que se usarán para este objetivo en particular. Esto forma parte de una API de licencias obsoleta que Bazel ya no usa. Lo que no debes hacer usan esto.

srcs

Lista de etiquetas; el valor predeterminado es []

Archivos procesados o incluidos por esta regla. Por lo general, enumera los archivos de forma directa, pero puede mostrar los objetivos de la regla (como filegroup o genrule) a incluyen sus resultados predeterminados.

Las reglas específicas del lenguaje a menudo requieren que los archivos de la lista tengan extensiones de archivo.

Atributos comunes a todas las reglas de compilación

En esta sección, se describen los atributos que se agregan de forma implícita a todas las compilaciones las reglas de firewall.

Atributo Descripción
compatible_with

Lista de etiquetas; no configurable; el valor predeterminado es []

La lista de entornos para los que se puede crear este destino, además de compatibles de forma predeterminada.

Esto es parte del sistema de restricciones de Bazel, que permite a los usuarios declarar qué estos pueden o no pueden depender unos de otros. Por ejemplo, implementable de forma externa. Los objetos binarios no deben depender de bibliotecas con código secreto de la empresa. Consulta ConstraintSemantics para obtener más detalles.

deprecation

String; no configurable; el valor predeterminado es None

Un mensaje de advertencia explicativo asociado a este destino. Por lo general, se usa para notificar a los usuarios que un destino dejó de estar disponible o fue sustituida por otra regla, es privada de un paquete o considerado perjudicial por alguna razón. Es una buena idea incluir alguna referencia (como una página web, un número de error o ejemplos de CL de migración), que uno pueda averiguar fácilmente qué cambios se requieren para evitar el mensaje. Si hay un objetivo nuevo que se pueda usar como una disminución en el reemplazo, se trata de un es buena idea migrar todos los usuarios del destino anterior.

Este atributo no tiene efecto en la forma en que se crean los elementos, pero puede afectar el resultado de diagnóstico de una herramienta de compilación. La herramienta de compilación emite un una advertencia cuando se establece una regla con un atributo deprecation un destino en otro paquete.

Las dependencias dentro del paquete están exentas de esta advertencia. Por lo tanto, por ejemplo, crear las pruebas de una regla obsoleta verán una advertencia.

Si un objetivo obsoleto depende de otro objetivo obsoleto, no se muestran advertencias si se envía un mensaje de error.

Una vez que las personas dejen de usarlo, se podrá quitar el objetivo.

distribs

Lista de cadenas; no configurable; el valor predeterminado es []

Una lista de cadenas de método de distribución que se usarán para este objetivo en particular. Esto forma parte de una API de licencias obsoleta que Bazel ya no usa. Lo que no debes hacer usan esto.

exec_compatible_with

Lista de etiquetas; no configurable; el valor predeterminado es []

Una lista de constraint_values que debe estar presente en la plataforma de ejecución para este destino. Está en además de cualquier restricción ya establecida por el tipo de regla. Se usan restricciones para restringir la lista de plataformas de ejecución disponibles. Para obtener más detalles, consulta la descripción de resolución de la cadena de herramientas.

exec_properties

Diccionario de cadenas; el valor predeterminado es {}

Un diccionario de cadenas que se agregará a exec_properties de una plataforma seleccionada para este destino. Consulta exec_properties de la regla de la plataforma.

Si una clave está presente en las propiedades de nivel de plataforma y de destino, el valor se tomará del destino.

features

Lista de cadenas feature; el valor predeterminado es []

Una función es una etiqueta de cadena que se puede habilitar o inhabilitar en un destino. El el significado de un atributo depende de la regla misma.

Este atributo features se combina con el atributo features de nivel de paquete. Por ejemplo, las funciones ["a", "b"] están habilitadas a nivel de paquete, y la política El atributo features contiene ["-a", "c"], las funciones habilitadas para el de entrada será “b” y "c". Consulta el ejemplo.

restricted_to

Lista de etiquetas; no configurable; el valor predeterminado es []

Es la lista de entornos para los que se puede compilar este destino, en lugar de compatibles de forma predeterminada.

Esto forma parte del sistema de restricciones de Bazel. Consulta compatible_with para conocer los detalles.

tags

Lista de cadenas; no configurable; el valor predeterminado es []

Las etiquetas se pueden usar en cualquier regla. Las etiquetas de prueba y Las reglas test_suite son útiles para categorizar las pruebas. Las etiquetas de destinos que no son de prueba se usan para controlar la ejecución en zona de pruebas de genrule s y Starlark y realizar análisis con personas o herramientas externas.

Bazel modifica el comportamiento de su código de zona de pruebas si encuentra lo siguiente: palabras clave en el atributo tags de cualquier prueba o genrule objetivo, o las claves de execution_requirements para cualquier Starlark acción.

  • La palabra clave no-sandbox hace que la acción o la prueba nunca se efectúe en entornos aislados; aún se puede almacenar en caché o ejecutarse de forma remota: usa no-cache. o no-remote para evitarlos.
  • La palabra clave no-cache hace que la acción o la prueba nunca se efectúe almacenado en caché (de forma remota o local)
  • La palabra clave no-remote-cache hace que la acción o la prueba nunca se efectúe almacenarse en caché de forma remota (pero puede almacenarse en caché localmente; también se puede ejecutar de forma remota). Nota: A los efectos de esta etiqueta, la caché de disco se considera una caché local, mientras que las cachés de HTTP y gRPC se consideran remotas. Si se usa una combinación de caché de disco local y caché remota (caché combinada), se trata como una caché remota y se inhabilita por completo, a menos que --incompatible_remote_results_ignore_disk en cuyo caso se usarán los componentes locales.
  • La palabra clave no-remote-exec hace que la acción o la prueba nunca se efectúe ejecutarse de forma remota (pero puede almacenarse en caché de forma remota).
  • La palabra clave no-remote impide que la acción o la prueba se ejecuten de forma remota. se almacenan en caché de forma remota. Esto equivale a usar ambos no-remote-cache y no-remote-exec.
  • La palabra clave no-remote-cache-upload inhabilita la carga del almacenamiento en caché remoto de un generación. no inhabilita la ejecución remota.
  • La palabra clave local impide que la acción o la prueba se almacene en caché de forma remota. ejecutar de forma remota o ejecutarse dentro de la zona de pruebas. Para genrules y pruebas, marca la regla con local = True. tiene el mismo efecto.
  • La palabra clave requires-network permite acceder al recurso desde dentro de la zona de pruebas. Esta etiqueta solo tiene efecto en la zona de pruebas esté habilitado.
  • La palabra clave block-network bloquea el acceso al recurso externo desde dentro de la zona de pruebas. En este caso, solo la comunicación con localhost. Esta etiqueta solo tiene efecto si la zona de pruebas está habilitado.
  • requires-fakeroot ejecuta la prueba o la acción como uid y gid 0 (es decir, la raíz usuario). Esta función solo es compatible con Linux. Esta etiqueta tiene prioridad sobre el Opción de línea de comandos --sandbox_fake_username.

Por lo general, las etiquetas de las pruebas se usan para anotar el rol de una prueba en tu el proceso de depuración y lanzamiento. Por lo general, las etiquetas son más útiles para C++ y Python. que carecen de la capacidad de anotación de tiempo de ejecución. El uso de etiquetas y tamaños ofrece flexibilidad para organizar conjuntos de pruebas basadas en la base de código de entrada.

Bazel modifica el comportamiento de ejecución de la prueba si encuentra las siguientes palabras clave en el Atributo tags de la regla de prueba:

  • exclusive forzará la ejecución de la prueba en el “exclusivo” y asegúrate de que no se ejecuten otras pruebas en el mismo tiempo. Esas pruebas se ejecutarán en serie después de toda la compilación actividad y se completaron las pruebas no exclusivas. La ejecución remota está inhabilitado en esas pruebas porque Bazel no tiene control sobre lo que que se ejecuta en una máquina remota.
  • exclusive-if-local forzará la ejecución de la prueba en el “exclusivo” si se ejecuta de forma local, pero la prueba se ejecutará en paralelo si es ejecutado de forma remota.
  • La palabra clave manual excluirá la segmentación de la expansión de comodines de patrones de segmentación (..., :*, :all, etc.) y test_suite reglas que no indiquen la prueba de manera explícita cuando se calcule el conjunto de objetivos de nivel superior para compilar/ejecutar para los comandos build, test y coverage. No afectará el comodín de destino o la expansión del paquete de pruebas en otros contextos, como Comando query. Ten en cuenta que manual no implica que un objetivo deba no pueden compilarse ni ejecutarse automáticamente mediante sistemas continuos de compilación o prueba. Por ejemplo, podría ser desea excluir un objetivo de bazel test ... porque requiere requisitos Características de Bazel, pero que igual se incluyen en las pruebas continuas o el envío previo configurados correctamente. o en cualquier plataforma que ejecute Knative.
  • La palabra clave external forzará que la prueba se realice de forma incondicional ejecutado (independientemente de --cache_test_results valor).
Consulta Convenciones de etiquetas en la Enciclopedia de pruebas para conocer más convenciones sobre las etiquetas adjuntas a los objetivos de prueba.
target_compatible_with

Lista de etiquetas; el valor predeterminado es []

Una lista de constraint_values debe estar presente en la plataforma de segmentación para que se considere. compatible. Esto se suma a las restricciones ya establecidas por el tipo de regla. Si la plataforma de destino no cumple con todas las restricciones indicadas, el destino se considera incompatible. Los destinos incompatibles son se omite para la compilación y la prueba cuando se expande el patrón de destino. (p.ej., //..., :all). Cuando se especifica de forma explícita en el línea de comandos, los destinos incompatibles provocan que Bazel imprima un error y cause una errores de compilación o prueba.

Los objetivos que dependen transitivamente de objetivos incompatibles son ellos mismos considerada incompatible. También se omiten para la compilación y las pruebas.

Una lista vacía (predeterminada) significa que el destino es compatible. con todas las plataformas.

Todas las reglas que no sean reglas de Workspace admiten esto. . En algunas reglas, este atributo no tiene efecto. Por ejemplo, si especificas target_compatible_with para un cc_toolchain no es útil.

Consulta la Plataformas para obtener más información sobre la omisión de objetivos incompatibles.

testonly

Boolean; no configurable; el valor predeterminado es False excepto para los objetivos de los paquetes de pruebas y pruebas

Si es True, solo los destinos de solo prueba (como las pruebas) pueden depender de este objetivo.

De forma equivalente, una regla que no sea testonly no puede depender de cualquier regla que sea testonly.

Pruebas (*_test reglas) y paquetes de pruebas (reglas test_suite) son testonly de forma predeterminada.

Con este atributo se pretende indicar que el destino no debe contenidos en objetos binarios que se lanzan a producción.

Debido a que testonly se aplica en el tiempo de compilación, no en el de ejecución, y se propaga viralmente a través del árbol de dependencia, debería aplicarse con cuidado. Para ejemplo, stubs y falsificaciones que son útiles para las pruebas de unidades y las de integración que incluyan los mismos objetos binarios que se lanzarán en producción. por lo que no debería marcarse solo de prueba. Por el contrario, las reglas que son peligrosos, incluso, porque anular el comportamiento normal, definitivamente se debe marcar como solo de prueba.

toolchains

Lista de etiquetas; no configurable; el valor predeterminado es []

Es el conjunto de destinos cuyas variables de Make son este destino: tienen permitido el acceso. Estos objetivos son instancias de reglas que proporcionan TemplateVariableInfo o destinos especiales para tipos de cadenas de herramientas integrados en Bazel. Estos incluyen:

  • @bazel_tools//tools/cpp:current_cc_toolchain
  • @bazel_tools//tools/jdk:current_java_runtime

Ten en cuenta que esto es diferente del concepto de resolución de la cadena de herramientas que usan las implementaciones de reglas para la configuración dependiente de la plataforma. No puedes usar esto para determinar qué cc_toolchain o java_toolchain específicos que usará el destino.

visibility

Lista de etiquetas; no configurable; la configuración predeterminada es default_visibility de package si se especifica, o bien "//visibility:private" de lo contrario

El atributo visibility de un destino controla si este puede usarse en otros paquetes. Consulta la documentación para visibilidad.

Atributos comunes a todas las reglas de prueba (*_test)

En esta sección, se describen los atributos comunes a todas las reglas de prueba.

Atributo Descripción
args

Lista de cadenas; sujeto a $(location) y Sustitución "Make variable" y Asignación de token de shell de Bourne; la configuración predeterminada es []

Son los argumentos de línea de comandos que Bazel pasa al destino cuando es se ejecuta con bazel test.

Estos argumentos se pasan antes que cualquier valor --test_arg. especificadas en la línea de comandos de bazel test.

env

Diccionario de cadenas; están sujetos a $(location) y Sustitución "Make variable"; el valor predeterminado es []

Especifica las variables de entorno adicionales que se deben configurar cuando se ejecuta la prueba. bazel test

Este atributo solo se aplica a las reglas nativas, como cc_test, py_test y sh_test. No se aplica a Reglas de prueba definidas por Starlark. Para tus propias reglas de Starlark, puedes agregar un “env” y usarlo para completar un TestEnvironment Proveedor

env_inherit

Lista de cadenas; el valor predeterminado es []

Especifica las variables de entorno adicionales que se heredarán del Un entorno externo cuando bazel test ejecuta la prueba.

Este atributo solo se aplica a las reglas nativas, como cc_test, py_test, y sh_test. No se aplica a las reglas de prueba definidas por Starlark.

size

String "enormous", "large", "medium" o "small"; no configurable; el valor predeterminado es "medium"

Especifica la “pesura” de un objetivo de prueba, es decir, cuánto tiempo o recursos necesita para ejecutarse.

Las pruebas de unidades se consideran "pequeñas", las de integración "medias" y las de extremo a extremo "grandes". o “enorme”. Bazel usa el tamaño para determinar un tiempo de espera predeterminado, que se puede anular con el atributo timeout. El tiempo de espera corresponde a todas las pruebas del destino de COMPILACIÓN, no a cada una una prueba individual. Cuando la prueba se ejecuta de forma local, se usa size de manera adicional para con fines de programación: Bazel intenta respetar --local_{ram,cpu}_resources en lugar de y sobrecargar la máquina local ejecutando muchas pruebas al mismo tiempo.

Los tamaños de las pruebas corresponden a los siguientes tiempos de espera predeterminados y a los recursos locales máximos supuestos usos:

Tamaño RAM (en MB) CPU (en núcleos de CPU) Tiempo de espera predeterminado
poco a poco 20 1 corto (1 minuto)
media 100 1 moderado (5 minutos)
grandes 300 1 largo (15 minutos)
enorme 800 1 eternal (60 minutos)

La variable de entorno TEST_SIZE se configurará como de este atributo durante la generación de la prueba.

timeout

String "short", "moderate", "long" o "eternal"; no configurable; se deriva de forma predeterminada del atributo size de la prueba

El tiempo que se espera que se ejecute la prueba antes de devolverse.

Si bien el atributo de tamaño de una prueba controla la estimación de recursos, el tiempo de espera se puede establecer de forma independiente. Si no se especifica de forma explícita, el de espera se basa en el tamaño de la prueba. La prueba El tiempo de espera se puede anular con la marca --test_timeout, p.ej., para se ejecuta en ciertas condiciones que se sabe que son lentas. Cómo probar los valores de tiempo de espera corresponden a los siguientes períodos:

Valor de tiempo de espera Período
short 1 minuto
Moderada 5 minutos
long 15 minutos
eterno 60 minutos

En los casos que no sean los mencionados anteriormente, el tiempo de espera de la prueba se puede anular con Marca de Bazel de --test_timeout, p.ej., para ejecutar manualmente condiciones que se sabe que son lentas. Los valores --test_timeout en segundos. Por ejemplo, --test_timeout=120 establecerá la prueba. el tiempo de espera en dos minutos.

La variable de entorno TEST_TIMEOUT se establecerá en el tiempo de espera de la prueba (en segundos) cuando se genere la prueba.

flaky

Boolean; no configurable; el valor predeterminado es False

Marca la prueba como inestable.

Si está configurada, ejecuta la prueba hasta tres veces y la marca como errónea solo si falla cada vez. De forma predeterminada, este atributo se establece en falso, y la prueba se ejecutado solo una vez. Ten en cuenta que, en general, no se recomienda usar este atributo. las pruebas deben pasar de manera confiable cuando se mantienen sus aserciones.

shard_count

Número entero no negativo menor o igual que 50 el valor predeterminado es -1

Especifica la cantidad de fragmentos paralelos usar para ejecutar la prueba.

Si se establece, este valor anulará cualquier heurística utilizada para determinar la cantidad de fragmentos paralelos con los que se ejecutará la prueba. Ten en cuenta que, para algunas pruebas, reglas, es posible que se requiera este parámetro para habilitar la fragmentación en primer lugar. Consulta también --test_sharding_strategy.

Si la fragmentación de pruebas está habilitada, la variable de entorno TEST_TOTAL_SHARDS se establecerá en este valor cuando se genere la prueba.

La fragmentación requiere que el ejecutor de pruebas admita el protocolo de fragmentación de pruebas. De lo contrario, lo más probable es que ejecute todas las pruebas en cada fragmento, no es lo que quieres.

Consulta Fragmentación de pruebas en la Enciclopedia de pruebas para obtener detalles sobre la fragmentación.

local

Boolean; no configurable; el valor predeterminado es False

Fuerza la ejecución de la prueba de manera local, sin zona de pruebas.

Si estableces esta política como verdadera, equivale a proporcionar una configuración “local” como etiqueta (tags=["local"]).

Atributos comunes a todas las reglas binarias (*_binary)

En esta sección, se describen los atributos comunes a todas las reglas binarias.

Atributo Descripción
args

Lista de cadenas; sujeto a $(location) y Sustitución "Make variable" y Asignación de token de shell de Bourne; no configurable; el valor predeterminado es []

Argumentos de línea de comandos que Bazel pasará al destino cuando se ejecute. con el comando run o como prueba. Estos argumentos son pasan antes que los que se especifican en el archivo bazel run Línea de comandos de bazel test

NOTA: Los argumentos no se pasan cuando ejecutas el destino fuera de Bazel (por ejemplo, ejecutando manualmente el objeto binario en bazel-bin/).

env

Diccionario de cadenas; están sujetos a $(location) y Sustitución "Make variable"; el valor predeterminado es {}

Especifica las variables de entorno adicionales que se deben configurar cuando el destino ejecutado por bazel run.

Este atributo solo se aplica a las reglas nativas, como cc_binary, py_binary, y sh_binary. No se aplica a las reglas ejecutables definidas por Starlark.

NOTA: Las variables de entorno no se configuran cuando ejecutas el destino fuera de Bazel (por ejemplo, ejecutando manualmente el objeto binario en bazel-bin/).

output_licenses

Lista de cadenas; el valor predeterminado es []

Son las licencias de los archivos de salida que genera este objeto binario. Esto forma parte de una API de licencias obsoleta que Bazel ya no usa. Lo que no debes hacer usan esto.

Atributos configurables

La mayoría de los atributos son “configurables”, lo que significa que sus valores pueden cambiar cuando el objetivo se construye de diferentes maneras. Específicamente, atributos configurables puede variar según las marcas que se pasen a la línea de comandos de Bazel una dependencia descendente solicita el destino. Esto se puede usar para para personalizar el destino para varias plataformas o modos de compilación.

En el siguiente ejemplo, se declaran diferentes fuentes para distintos destinos arquitecturas. Ejecutando bazel build :multiplatform_lib --cpu x86 compilará el destino con x86_impl.cc y sustituirá al En su lugar, --cpu arm hará que use arm_impl.cc.

cc_library(
    name = "multiplatform_lib",
    srcs = select({
        ":x86_mode": ["x86_impl.cc"],
        ":arm_mode": ["arm_impl.cc"]
    })
)
config_setting(
    name = "x86_mode",
    values = { "cpu": "x86" }
)
config_setting(
    name = "arm_mode",
    values = { "cpu": "arm" }
)

La función select() elige entre diferentes valores alternativos para un atributo configurable basado en cuál config_setting o constraint_value con los criterios que satisface la configuración del destino.

Bazel evalúa los atributos configurables después de procesar las macros y antes de procesamiento de lenguaje natural (técnicamente, entre fases de carga y análisis). Cualquier procesamiento previo a la evaluación de select() no sabe qué que elija select(). Las macros, por ejemplo, no pueden cambiar su comportamiento en función de la rama elegida, y bazel query puede solo hacer conjeturas conservadoras sobre las dependencias configurables de un objetivo. Consulta esta sección de Preguntas frecuentes para obtener más información sobre el uso de select() con reglas y macros.

Los atributos marcados con nonconfigurable en su documentación no pueden usan esta función. Por lo general, un atributo no es configurable porque Bazel necesita conocer internamente su valor antes de poder determinar cómo resolver un select()

Consulta Atributos de compilación configurables para obtener una descripción general detallada.

Destinos de salida implícitos

Las salidas implícitas en C++ dejaron de estar disponibles. No lo uses en otros idiomas cuando sea posible. Aún no tenemos una ruta de baja pero, con el tiempo, también dejarán de estar disponibles.

Cuando se define una regla de compilación en un archivo de COMPILACIÓN, se generan declarar un nuevo destino de la regla con nombre en un paquete. Regla de compilación muchas también implican de forma implícita uno o más archivos de salida objetivos, cuyo contenido y significado son específicos de la regla. Por ejemplo, cuando declaras explícitamente un java_binary(name='foo', ...), también La declaración implícita de un archivo de salida se orienta a foo_deploy.jar como miembro del mismo paquete. (Este destino en particular es un archivo Java autónomo adecuado para la implementación).

Los objetivos de salida implícitos son miembros de primera clase de la red gráfico de destino. Al igual que otros objetivos, se crean a pedido ya sea cuando se especifican en el comando de compilación de nivel superior o cuando son requisitos previos necesarios para otros destinos de compilación. Pueden ser se denominan dependencias en archivos BUILD y se pueden observar en El resultado de las herramientas de análisis, como bazel query

Para cada tipo de regla de compilación, la documentación de la regla contiene un una sección especial que detalla los nombres y contenidos de cualquier resultados que incluye una declaración de ese tipo de regla.

Una distinción importante, pero un poco sutil entre los dos espacios de nombres que usa el sistema de compilación: Las etiquetas identifican objetivos. que pueden ser reglas o archivos, y los objetivos de los archivos pueden dividirse en los destinos del archivo de origen (o de entrada) y el archivo derivado (o de salida) objetivos. Estos son los elementos que puedes mencionar en los archivos BUILD, compilar desde la línea de comandos o examinar con bazel query este es el espacio de nombres de destino. Cada destino de archivo corresponde en un archivo real en el disco (el “espacio de nombres del sistema de archivos”) cada regla el destino puede corresponder a cero, a uno o más archivos en el disco. Es posible que haya archivos en el disco que no tengan un destino correspondiente. para Ejemplo: archivos de objeto .o producidos durante la compilación de C++ no se puede hacer referencia desde los archivos BUILD ni desde la línea de comandos. De esta manera, la herramienta de compilación puede ocultar ciertos detalles de implementación de cómo hace su trabajo. Esto se explica con más detalle en la Referencia de conceptos de COMPILACIÓN