Definiciones comunes

Informar sobre un problema Ver la fuente

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

Contenido

Asignación de token de shell Bourne

Ciertos atributos de string de algunas reglas se dividen en varias palabras según las reglas de asignación de token de la shell Bourne: los espacios sin comillas delimitan palabras separadas, y se usan comillas simples y dobles, y barras inversas para evitar la asignación de token.

Esos atributos que están sujetos a esta asignación de token se indican explícitamente como tales en sus definiciones en este documento.

Los atributos sujetos a la expansión de la variable "Make" y a la asignación de token de shell Bourne se usan generalmente para pasar opciones arbitrarias a compiladores y otras herramientas. Algunos ejemplos de estos atributos son cc_library.copts y java_library.javacopts. En conjunto, estas sustituciones permiten que una sola variable de string se expanda en una lista de palabras de opción específica de la configuración.

Expansión de etiquetas

Algunos atributos de string de muy pocas reglas están sujetos a la expansión de etiquetas: si esas strings contienen una etiqueta válida como una substring, como //mypkg:target, y esa etiqueta es un requisito declarado de la regla actual, se expande en el nombre de ruta del archivo representado por el //mypkg:target target.

Los atributos de ejemplo incluyen genrule.cmd y cc_binary.linkopts. Los detalles pueden variar significativamente en cada caso, en función de problemas como: si se expanden las etiquetas relativas; cómo se tratan las etiquetas que se expanden a varios archivos, etc. Consulta la documentación sobre los atributos de las reglas para obtener 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 todos.

Atributo Descripción
data

List of labels ; optional

Archivos necesarios para esta regla en el tiempo de ejecución. Puede enumerar los objetivos del archivo o la regla. Por lo general, permite cualquier destino.

Los resultados predeterminados y los runfiles de objetivos en el atributo data deben aparecer en el área *.runfiles de cualquier ejecutable que sea saliente o tenga una dependencia del entorno de ejecución en este destino. Esto puede incluir objetos binarios o archivos de datos que se usan cuando se ejecuta el srcs de este destino. Consulta la sección dependencias de datos para obtener más información sobre cómo depender de los archivos de datos y cómo usarlos.

Las reglas nuevas deben definir un atributo data si procesan entradas que podrían usar otras entradas en el entorno de ejecución. Las funciones de implementación de las reglas también deben propagar los runfiles del destino desde los resultados y los archivos runrun de cualquier atributo data, así como desde cualquier atributo de dependencia que proporcione código fuente o dependencias del entorno de ejecución.

deps

List of labels ; optional

Dependencias para este objetivo. Por lo general, solo se deben enumerar los objetivos de la regla. (Aunque algunas reglas permiten que los archivos se enumeren directamente en deps, esto se debe evitar cuando sea posible).

Por lo general, las reglas específicas del lenguaje limitan los destinos enumerados para aquellos con proveedores específicos.

La semántica exacta de lo que significa que un destino dependa de otro mediante deps es específica para el tipo de regla, y la documentación específica de la regla se detalla más a continuación. En el caso de las reglas que procesan código fuente, deps suele especificar las dependencias de código que usa el código en srcs.

En la mayoría de los casos, se usa una dependencia deps para permitir que un módulo use símbolos definidos en otro módulo escrito en el mismo lenguaje de programación y compilados por separado. Las dependencias entre lenguajes también se permiten en muchos casos: por ejemplo, un objetivo java_library puede depender del código C++ en un objetivo cc_library. Para ello, debes enumerar este último en el atributo deps. Consulta la definición de dependencias para obtener más información.

licenses

List of strings; optional; nonconfigurable

Una lista de strings de tipo de licencia que se usará para este destino en particular. Esto es parte de una API de licencias obsoleta que ya no usa Bazel. No uses esto.

srcs

List of labels ; optional

Archivos procesados o incluidos en esta regla. Por lo general, los archivos se enumeran directamente, pero pueden enumerar los objetivos de la regla (como filegroup o genrule) para incluir sus resultados predeterminados.

A menudo, las reglas específicas del lenguaje requieren que los archivos enumerados tengan extensiones de archivo particulares.

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 reglas de compilación.

Atributo Descripción
compatible_with

List of labels ; optional; nonconfigurable

La lista de entornos para los que se puede compilar este destino, además de los entornos compatibles predeterminados.

Esto forma parte del sistema de restricciones de Bazel, que permite a los usuarios declarar qué destinos pueden depender entre sí y cuáles no. Por ejemplo, los objetos binarios de implementación externa no deben depender de bibliotecas con código secreto de la empresa. Consulta ConstraintSemantics para obtener más detalles.

deprecation

String; optional; nonconfigurable

Un mensaje de advertencia explicativo asociado con este destino. Por lo general, se usa para notificar a los usuarios que un destino se volvió obsoleto, que se reemplazó por otra regla, que es privado para un paquete o que se considera perjudicial por algún motivo. Es una buena idea incluir alguna referencia (como una página web, un número de error o CL de migración) a fin de que se pueda averiguar con facilidad qué cambios se requieren para evitar el mensaje. Si hay un objetivo nuevo que se puede usar como una disminución en el reemplazo, es una buena idea migrar a todos los usuarios del destino anterior.

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

Las dependencias dentro del paquete están exentas de esta advertencia, por lo que, por ejemplo, compilar las pruebas de una regla obsoleta no tiene una advertencia.

Si un destino obsoleto depende de otro destino obsoleto, no se emite ningún mensaje de advertencia.

Una vez que las personas dejan de usar el destino, se lo quita.

distribs

List of strings; optional; nonconfigurable

Una lista de strings de método de distribución para usar en este destino en particular. Esto es parte de una API de licencias obsoleta que ya no usa Bazel. No uses esto.

exec_compatible_with

List of labels ; optional; nonconfigurable

Una lista de constraint_values que debe estar presente en la plataforma de ejecución para este destino. Esto se suma a las restricciones ya establecidas por el tipo de regla. Las restricciones se usan para restringir la lista de plataformas de ejecución disponibles. Para obtener más detalles, consulta la descripción de la resolución de la cadena de herramientas.

exec_properties

Dictionary of strings; optional

Es el diccionario de strings que se agregará al exec_properties de una plataforma seleccionada para este destino. Consulta exec_properties de la regla de platform.

Si una clave está presente tanto en la plataforma como en las propiedades a nivel de la orientación, el valor se tomará del objetivo.

features

List of feature strings; optional

Un elemento es una etiqueta de string que se puede habilitar o inhabilitar en un destino. El significado de un atributo depende de la regla en sí.

Este atributo features se combina con el atributo features del nivel del paquete. Por ejemplo, si los atributos [“a”, “b”] están habilitados a nivel del paquete y el atributo features de un objetivo contiene [“-a”, “c”], los atributos habilitados para la regla serán “b” y “c”. Ver un ejemplo.

restricted_to

List of labels ; optional; nonconfigurable

La lista de entornos para la que se puede compilar este destino, en su lugar, en los entornos compatibles con la configuración predeterminada.

Esto forma parte del sistema de restricciones de Bazel. Consulta compatible_with para obtener más información.

tags

List of strings; optional; nonconfigurable

Las etiquetas se pueden usar en cualquier regla. Las etiquetas en las reglas de prueba y test_suite son útiles para clasificar las pruebas. Las etiquetas en destinos que no son de prueba se usan para controlar la ejecución de las acciones de genrule y Starlark en la zona de pruebas, y para el análisis realizado por personas o herramientas externas.

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

  • La palabra clave no-sandbox da como resultado que la acción o la prueba nunca se coloque en una zona de pruebas. De todos modos, se puede almacenar en caché o ejecutar de forma remota. Usa no-cache o no-remote para evitar cualquiera de ellas.
  • La palabra clave no-cache da como resultado que la acción o la prueba nunca se almacene en caché (de forma remota o local).
  • La palabra clave no-remote-cache da como resultado que la acción o la prueba nunca se almacene en caché de manera remota (pero puede almacenarse en caché de forma local y también puede ejecutarse de forma remota). Nota: A los fines de esta etiqueta, la caché de disco se considera una caché local, mientras que las cachés HTTP y gRPC se consideran remotas. Si se usa una combinación de caché local de disco y caché remota (caché combinada), se trata como una caché remota y se inhabilita por completo, a menos que se establezca --incompatible_remote_results_ignore_disk, en cuyo caso se usarán los componentes locales.
  • La palabra clave no-remote-exec da como resultado que la acción o la prueba nunca se ejecute de forma remota (pero se puede almacenar en caché de forma remota).
  • La palabra clave no-remote evita que la acción o la prueba se ejecute de forma remota o se almacene en caché de forma remota. Esto equivale a usar no-remote-cache y no-remote-exec.
  • La palabra clave no-remote-cache-upload inhabilita la carga de parte 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é, se ejecute de forma remota o se ejecute dentro de la zona de pruebas de forma remota. Para las reglas de prueba y reglas, marcar la regla con el atributo local = True tiene el mismo efecto.
  • La palabra clave requires-network permite el acceso a la red externa desde la zona de pruebas. Esta etiqueta solo tiene efecto si la zona de pruebas está habilitada.
  • La palabra clave block-network bloquea el acceso a la red externa desde la zona de pruebas. En este caso, solo se permite la comunicación con localhost. Esta etiqueta solo tiene efecto si la zona de pruebas está habilitada.
  • requires-fakeroot ejecuta la prueba o acción como uid y gid 0 (es decir, el usuario raíz). Solo se admite en Linux. Esta etiqueta tiene prioridad sobre la opción de línea de comandos --sandbox_fake_username.

Por lo general, las etiquetas de las pruebas se usan para anotar la función de una prueba en tu proceso de depuración y lanzamiento. Por lo general, las etiquetas son más útiles para las pruebas de C++ y Python, que carecen de capacidad de anotación en el tiempo de ejecución. El uso de etiquetas y elementos de tamaño brinda flexibilidad para el conjunto de conjuntos de pruebas en torno a la política de registro de la base de código.

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

  • exclusive forzará la ejecución de la prueba en modo "exclusivo", lo que garantiza que no se ejecuten otras pruebas al mismo tiempo. Estas pruebas se ejecutarán en serie después de que se completen todas las actividades de compilación y las no exclusivas. La ejecución remota está inhabilitada para esas pruebas porque Bazel no tiene control sobre lo que se ejecuta en una máquina remota.
  • exclusive-if-local forzará la ejecución de la prueba en el modo "exclusivo" si se ejecuta de forma local, pero ejecutará la prueba en paralelo si se ejecuta de forma remota.
  • La palabra clave manual excluirá el objetivo de la expansión de comodines de patrones de destino (..., :*, :all, etc.) y las reglas test_suite que no enumeran la prueba de forma explícita cuando se calcula el conjunto de objetivos de nivel superior para compilar o ejecutar los comandos build, test y coverage. No afecta la comodín de destino ni la expansión del conjunto de pruebas en otros contextos, incluido el comando query. Ten en cuenta que manual no implica que los sistemas de compilación o prueba continuas no compilen ni ejecuten automáticamente un destino. Por ejemplo, es posible que se quiera excluir un destino de bazel test ... porque requiere marcas específicas de Bazel, pero aun así se incluye en las ejecuciones de pruebas previas o previas que se configuraron de forma correcta.
  • La palabra clave external forzará la prueba para que se ejecute de manera incondicional (sin importar el valor de --cache_test_results).
Consulta Convenciones de etiqueta en la Enciclopedia de Pruebas para obtener más convenciones sobre etiquetas adjuntas a objetivos de prueba.
target_compatible_with

List of labels ; optional

Una lista de constraint_value que deben estar presentes en la plataforma de destino para que este se considere compatible. Esto se suma a las restricciones ya establecidas por el tipo de regla. Si la plataforma de destino no satisface todas las restricciones enumeradas, se considera que no es compatible. Los destinos incompatibles se omiten para la compilación y la prueba cuando se expande el patrón de destino (p.ej., //..., :all). Cuando se especifica de manera explícita en la línea de comandos, los destinos incompatibles hacen que Bazel imprima un error y cause una falla de compilación o prueba.

Los destinos que dependen de forma transitiva de destinos incompatibles se consideran incompatibles. También se omiten para la compilación y la prueba.

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

Todas las reglas, excepto las Reglas de lugar de trabajo, admiten este atributo. Para algunas reglas, este atributo no tiene efecto. Por ejemplo, no es útil especificar target_compatible_with para una cc_toolchain.

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

testonly

Boolean; optional; default False except for test and test suite targets; nonconfigurable

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

Del mismo modo, una regla que no sea testonly no puede depender de ninguna regla que sea testonly.

Las pruebas (reglas *_test) y los conjuntos de pruebas (reglas test_suite) son testonly de forma predeterminada.

Este atributo significa que el objetivo no debe estar contenido en objetos binarios que se lancen a producción.

Debido a que solo se aplica la prueba en el momento de la compilación, no en el tiempo de ejecución, y se propaga de forma virtual por el árbol de dependencias, se debe aplicar con criterio. Por ejemplo, los stubs y las falsificaciones que son útiles para las pruebas de unidades también pueden ser útiles para las pruebas de integración que involucran los mismos objetos binarios que se lanzarán a producción y, por lo tanto, probablemente no deberían marcarse como de solo prueba. Por el contrario, las reglas que son peligrosas e incluso establecer vínculos, quizás porque anulan incondicionalmente el comportamiento normal, definitivamente deben marcarse como de solo prueba.

toolchains

List of labels ; optional; nonconfigurable

El conjunto de objetivos cuyas variables de Make pueden acceder. Estos destinos son instancias de reglas que proporcionan TemplateVariableInfo o destinos especiales para tipos de cadenas de herramientas integrados en Bazel. por ejemplo:

  • @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 que depende de la plataforma. No puedes usar este atributo para determinar qué cc_toolchain o java_toolchain específicos usará un objetivo.

visibility

List of labels ; optional; default default_visibility from package if specified, or //visibility:private otherwise; nonconfigurable

El atributo visibility de un destino controla si este se puede usar en otros paquetes. Consulta la documentación sobre la 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

List of strings; optional; subject to $(location) and "Make variable" substitution, and Bourne shell tokenization

Argumentos de línea de comandos que Bazel pasa al destino cuando se ejecuta con bazel test.

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

env

Dictionary of strings; optional; values are subject to $(location) and "Make variable" substitution

Especifica variables de entorno adicionales para establecer cuando bazel test ejecute la prueba.

Este atributo solo se aplica a reglas nativas, como cc_test, py_test y sh_test. No se aplica a las reglas de prueba definidas por Starlark. Para tus propias reglas de Starlark, puedes agregar un atributo "env" y usarlo a fin de propagar un proveedor TestEnvironment.

env_inherit

List of strings; optional

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

Este atributo solo se aplica a 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" or "small", default is "medium"; optional; nonconfigurable

Especifica el "peso" de un destino de prueba: la cantidad de tiempo y recursos que debe ejecutarse.

Las pruebas de unidades se consideran "pequeñas", las pruebas de integración "medianas" y de extremo a extremo "grandes" o "enormes". Bazel usa el tamaño para determinar el tiempo de espera predeterminado, que se puede anular mediante el atributo timeout. El tiempo de espera es para todas las pruebas del destino de BUILD, no para cada prueba individual. Cuando se ejecuta la prueba de forma local, el size también se usa con fines de programación: Bazel intenta respetar el --local_{ram,cpu}_resources y no abrumar la máquina local mediante la ejecución de muchas pruebas pesadas al mismo tiempo.

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

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

La variable de entorno TEST_SIZE se establecerá en el valor de este atributo cuando genere la prueba.

timeout

String "short", "moderate", "long", "eternal" (with the default derived from the test's size attribute); nonconfigurable

El tiempo que se espera que se ejecute la prueba antes de mostrar un resultado.

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

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

Para tiempos diferentes a los anteriores, se puede anular el tiempo de espera de la prueba con la marca del bazel --test_timeout, p.ej., para ejecutar manualmente en condiciones que se sabe que son lentas. Los valores --test_timeout se expresan en segundos. Por ejemplo, --test_timeout=120 establecerá el tiempo de espera de la prueba 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; optional; default False; nonconfigurable

Marca la prueba como inestable.

Si se configura, ejecuta la prueba hasta tres veces y la marca como fallida solo si falla cada vez. De forma predeterminada, este atributo se establece en False y la prueba se ejecuta solo una vez. Ten en cuenta que no se recomienda el uso de este atributo. Las pruebas deben aprobarse de manera confiable cuando se mantienen sus aserciones.

shard_count

Non-negative integer less than or equal to 50; optional

Especifica la cantidad de fragmentos paralelos que se usarán para ejecutar la prueba.

Este valor anulará cualquier heurística que se use para determinar la cantidad de fragmentos paralelos con los que se ejecuta la prueba. Ten en cuenta que, para algunas reglas de prueba, este parámetro puede ser necesario a fin de habilitar la fragmentación. Consulta también --test_sharding_strategy.

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

La fragmentación requiere que el ejecutor de pruebas sea compatible con el protocolo de fragmentación de pruebas. De lo contrario, es probable que ejecute todas las pruebas en cada fragmento, que no es lo que quieres.

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

local

Boolean; default False; nonconfigurable

Hace que la prueba se ejecute de forma local, sin zona de pruebas.

Configurar esta opción como verdadera equivale a proporcionar “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

List of strings; optional; subject to $(location) and "Make variable" substitution, and Bourne shell tokenization; nonconfigurable

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

NOTA: Los argumentos no se pasan cuando ejecutas el destino fuera de Bazel (por ejemplo, mediante la ejecución manual del objeto binario en bazel-bin/).

env

Dictionary of strings; optional; values are subject to $(location) and "Make variable" substitution

Especifica las variables de entorno adicionales que se deben establecer cuando bazel run ejecute el destino.

Este atributo solo se aplica a 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, mediante la ejecución manual del objeto binario en bazel-bin/).

output_licenses

List of strings; optional

Las licencias de los archivos de salida que genera este objeto binario. Esto es parte de una API de licencias obsoleta que ya no usa Bazel. No uses esto.

Atributos configurables

La mayoría de los atributos son “configurables”, lo que significa que sus valores pueden cambiar cuando el destino se compila de diferentes maneras. En particular, los atributos configurables pueden variar según las marcas que se pasan a la línea de comandos de Bazel o la dependencia descendente que solicite el destino. Esto se puede usar, por ejemplo, para personalizar el destino de varias plataformas o modos de compilación.

En el siguiente ejemplo, se declaran diferentes fuentes para diferentes arquitecturas de destino. Ejecutar bazel build :multiplatform_lib --cpu x86 compilará el destino mediante x86_impl.cc, mientras que sustituir --cpu arm hará que en su lugar 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 según los criterios de config_setting o constraint_value que satisface la configuración del destino.

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

Los atributos marcados como nonconfigurable en su documentación no pueden usar esta función. Por lo general, un atributo no se puede configurar porque Bazel interna necesita conocer su valor para determinar cómo resolver un select().

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

Destinos de salida implícitos

Los resultados implícitos en C++ dejaron de estar disponibles. No uses esta opción en otros idiomas siempre que sea posible. Todavía no tenemos una ruta de baja, pero con el tiempo también dejarán de estar disponibles.

Cuando defines una regla de compilación en un archivo BUILD, declaras de forma explícita un destino de regla con nombre nuevo en un paquete. Muchas funciones de reglas de compilación también implican implícitamente una o más orientaciones de archivo de salida, cuyo contenido y significado son específicos de las reglas. Por ejemplo, cuando declaras una regla java_binary(name='foo', ...) de forma explícita, también declaras implícitamente un destino de archivo de salida foo_deploy.jar como miembro del mismo paquete. (Este objetivo en particular es un archivo Java independiente adecuado para la implementación).

Los objetivos de salida implícitos son miembros de primera clase del gráfico objetivo global. Al igual que otros objetivos, se compilan a pedido, ya sea cuando se especifica en el comando de compilación de nivel superior o cuando son requisitos previos necesarios para otros objetivos de compilación. Se puede hacer referencia a ellas como 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 una sección especial que detalla los nombres y el contenido de los resultados implícitos que contiene una declaración de ese tipo de regla.

Una distinción importante, pero bastante sutil, entre los dos espacios de nombres que usa el sistema de compilación: las etiquetas identifican los objetivos, que pueden ser reglas o archivos, y los objetivos de archivo pueden dividirse en objetivos de archivo de origen (o de entrada) y objetivos de archivo derivados (o de salida). Estas son las cosas 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 a un archivo real en el disco (el "espacio de nombres del sistema de archivos"); cada destino de regla puede corresponder a cero, uno o más archivos reales en el disco. Puede haber archivos en el disco que no tengan el destino correspondiente. Por ejemplo, los archivos de objetos .o producidos durante la compilación de C++ no se pueden referenciar 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 sobre cómo hace su trabajo. Esto se explica con más detalle en la Referencia de conceptos de BUILD.