Definiciones comunes

Informar un problema Ver fuente

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 string de algunas reglas se dividen en varias palabras de acuerdo con las reglas de asignación de tokens de la shell de Bourne: los espacios sin comillas delimitan las palabras separadas, y se usan caracteres de comillas simples y dobles, y barras inversas para evitar la asignación de token.

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

Por lo general, los atributos sujetos a la expansión variable "Make" y la asignación de tokens de shell de Bourne se usan 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 unas pocas reglas están sujetos a la expansión de etiquetas: si esas strings contienen una etiqueta válida como substring, como //mypkg:target, y esa etiqueta es un requisito previo declarado de la regla actual, se expande al nombre de ruta del archivo representado por el //mypkg:target de destino.

Entre los atributos de ejemplo, se incluyen genrule.cmd y cc_binary.linkopts. Los detalles pueden variar significativamente en cada caso, por ejemplo, si se expanden las etiquetas relativas, cómo se tratan las etiquetas que se expanden a varios archivos, etc. Consulta la documentación de atributos de 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 todas.

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. Por lo general, permite cualquier destino.

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

Las reglas nuevas deben definir un atributo data si procesan entradas que podrían usar otras entradas en el tiempo de ejecución. Las funciones de implementación de las reglas también deben propagar los archivos runfiles del destino desde los archivos de salida y los archivos de ejecución de cualquier atributo data, así como los archivos de ejecución 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. (Aunque algunas reglas permiten que los archivos se enumeren directamente en deps, esto debe evitarse siempre que sea posible).

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

La semántica precisa de lo que significa que un destino dependa de otro mediante deps es específica del tipo de regla, y la documentación específica de la regla entra en más detalles. Para las reglas que procesan código fuente, deps suele especificar 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 símbolos definidos en otro módulo escritos 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 destino java_library puede depender del código C++ en un objetivo cc_library si se enumera 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. No la uses.

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 enumerar los objetivos de las reglas (como filegroup o genrule) para incluir sus resultados predeterminados.

Las reglas específicas de un lenguaje a menudo requieren que los archivos en la lista 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

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

Es la lista de entornos para los que se puede compilar este destino, además de los entornos compatibles de forma predeterminada.

Esto es parte del sistema de restricciones de Bazel, que permite a los usuarios declarar qué destinos pueden depender unos de otros y cuáles no. Por ejemplo, los objetos binarios implementables de forma externa no deberían 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 se volvió obsoleto, que se reemplazó por otra regla, que es privado de un paquete o que se considera dañino por algún motivo. Es una buena idea incluir alguna referencia (como una página web, un número de error o ejemplos de CL de migración) para que se pueda averiguar con facilidad qué cambios se requieren para evitar el mensaje. Si hay un destino nuevo que se puede usar como una bajada de reemplazo, conviene migrar a todos los usuarios del destino anterior.

Este atributo no tiene efecto en la forma en que se compilan, pero puede afectar el resultado de 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 destino en otro paquete.

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

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

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. No la uses.

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. Esto se suma a cualquier restricción que ya haya establecido 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

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 significado de un atributo depende de la regla misma.

Este atributo features se combina con el atributo features a nivel del paquete. Por ejemplo, si las funciones [“a”, “b”] están habilitadas a nivel del paquete y el atributo features de un destino contiene [“-a”, “c”], las funciones habilitadas para la regla serán “b” y “c”. Consulta un 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 entornos compatibles con valores predeterminados.

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

tags

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

Las etiquetas se pueden usar en cualquier regla. Las etiquetas de las reglas test_suite y de prueba son útiles para categorizar las pruebas. Las etiquetas de destinos que no son de prueba se usan para controlar la ejecución en la zona de pruebas de acciones de genrule y Starlark, y para el análisis con 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 hace que la acción o la prueba nunca se coloque en la zona de pruebas; aún puede almacenarse en caché o ejecutarse de forma remota. Usa no-cache o no-remote para evitar una de esas acciones o ambas.
  • La palabra clave no-cache hace que la acción o la prueba nunca se almacene en caché (de forma remota o local)
  • La palabra clave no-remote-cache hace que la acción o la prueba nunca se almacene en caché de forma remota (pero se puede almacenar en caché de forma local y también se puede ejecutar de manera remota). Nota: Para los fines 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 se configure --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 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 ejecuten de forma remota o se almacenen en caché de manera remota. Esto equivale a usar 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 almacenen en caché, se ejecuten de forma remota o se ejecuten dentro de la zona de pruebas de forma remota. Para genrules y pruebas, 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 el interior de 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 el interior de la zona de pruebas. En este caso, solo se permite la comunicación con el host local. Esta etiqueta solo tiene efecto si la zona de pruebas está habilitada.
  • requires-fakeroot ejecuta la prueba o la acción como uid y gid 0 (es decir, el usuario raíz). Esta función solo es compatible con 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 el 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 de entorno de ejecución. El uso de etiquetas y elementos de tamaño brinda flexibilidad para organizar conjuntos de pruebas en función de la política de registro de la base de código.

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 modo “exclusivo”, lo que garantiza que no se ejecuten otras pruebas al mismo tiempo. Esas pruebas se ejecutarán en serie una vez que se hayan completado toda la actividad de compilación y las pruebas 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 lo hará 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 manera explícita cuando se calcula el conjunto de objetivos de nivel superior que se compilarán o ejecutarán para los comandos build, test y coverage. No afecta el 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 continuos de compilación o prueba no deban compilar ni ejecutar un destino automáticamente. Por ejemplo, puede ser conveniente excluir un destino de bazel test ... porque requiere marcas de Bazel específicas, pero aun así se debe incluir en el envío previo o en ejecuciones de prueba continuas configuradas correctamente.
  • La palabra clave external forzará la ejecución de la prueba de forma incondicional (independientemente del valor --cache_test_results).
Consulta las 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 los objetos constraint_value que deben estar presentes en la plataforma de destino para que este destino se considere compatible. Esto se suma a cualquier restricción que ya haya establecido el tipo de regla. Si la plataforma de destino no cumple con todas las restricciones enumeradas, se considera que el destino es incompatible. Los destinos incompatibles se omiten durante la compilación y las pruebas cuando se expande el patrón de destino (p.ej., //... o :all). Cuando se especifican de forma explícita en la línea de comandos, los destinos incompatibles provocan que Bazel imprima un error y cause una falla de compilación o de prueba.

Los objetivos que dependen transitivamente de objetivos incompatibles se consideran incompatibles. 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 lugar de trabajo admiten este atributo. En 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 objetivos incompatibles.

testonly

Booleano, no configurable; la configuración predeterminada es False, excepto para los objetivos de prueba y conjunto de pruebas

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

De manera equivalente, 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.

El propósito de este atributo es significa que el destino no debe estar contenido en objetos binarios que se lanzan para producción.

Debido a que testonly se aplica en el tiempo de compilación, no en el tiempo de ejecución, y se propaga de forma viral a través del árbol de dependencia, debe aplicarse con precaución. 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 deban marcarse como solo de prueba. Por el contrario, las reglas que son peligrosas para vincularse, quizás porque anulan de forma incondicional el comportamiento normal, deben marcarse como solo de prueba.

toolchains

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

Es el conjunto de destinos a cuyas variables de Make puede acceder este destino. Estos destinos son instancias de reglas que proporcionan TemplateVariableInfo o destinos especiales para tipos de cadenas de herramientas integradas en Bazel. Por ejemplo:

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

Ten en cuenta que esto es distinto 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 este atributo para determinar qué cc_toolchain o java_toolchain específicos usará un destino.

visibility

Lista de etiquetas; no configurable; el valor predeterminado es default_visibility de package si se especifica, o bien "//visibility:private" de lo contrario

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

Lista de cadenas, sujeta a la sustitución $(location) y "Make variable", y la asignación de token de shell de Bourne; el valor predeterminado es []

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

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

env

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

Especifica las variables de entorno adicionales que se establecerán 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 para propagar un proveedor de TestEnvironment.

env_inherit

Lista de cadenas; el valor predeterminado es []

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" 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 "enormes". 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 prueba individual. Cuando la prueba se ejecuta de forma local, size se usa adicionalmente con fines de programación: Bazel intenta respetar --local_{ram,cpu}_resources y no abrumar la máquina local con la ejecución de muchas pruebas pesadas al mismo tiempo.

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

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

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

timeout

String "short", "moderate", "long" o "eternal" no configurable; el valor predeterminado se deriva 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 de una prueba puede establecerse 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., cuando se ejecuta en ciertas condiciones que se sabe que son lentas. Los valores de tiempo de espera de prueba corresponden a los siguientes períodos:

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

En otros momentos distintos de los anteriores, el tiempo de espera de la prueba se puede anular con la marca de Bazel --test_timeout, p.ej., para la ejecución manual en condiciones que se sabe que son lentas. Los valores --test_timeout están 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

Booleano; no configurable; el valor predeterminado es False

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 falso, y la prueba se ejecuta solo una vez. Ten en cuenta que, en general, no se recomienda usar este atributo, ya que 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 que se usarán para ejecutar la prueba.

Si se configura, este valor anulará cualquier heurística utilizada para determinar la cantidad de fragmentos paralelos con los que se ejecuta la prueba. Ten en cuenta que, en el caso de algunas reglas de prueba, es posible que este parámetro sea necesario 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. Si no es así, lo más probable es que ejecute todas las pruebas en cada fragmento, que no es lo que quieres.

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

local

Booleano; no configurable; el valor predeterminado es False

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

Configurar esta opción como verdadera equivale a proporcionar una etiqueta “local” (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; sujeta a la sustitución $(location) y "Make variable", y la asignación de token de shell de Bourne; no configurable; el valor predeterminado es []

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

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

env

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

Especifica las variables de entorno adicionales que se deben configurar cuando bazel run ejecuta 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, si ejecutas el objeto binario en bazel-bin/ de forma manual).

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. No la uses.

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. Específicamente, los atributos configurables pueden variar según las marcas que se pasen a la línea de comandos de Bazel o qué dependencia downstream solicita el destino. Se puede usar, por ejemplo, para personalizar el destino para varias plataformas o modos de compilación.

En el siguiente ejemplo, se declaran diferentes fuentes para distintas arquitecturas de destino. La ejecución de bazel build :multiplatform_lib --cpu x86 compilará el destino con x86_impl.cc, mientras que, si se sustituye --cpu arm, se usará 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 en función de los criterios 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 previo a 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 necesita conocer su valor de forma interna para 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. Evita usarlo en otros idiomas siempre que sea posible. Aún no tenemos una ruta de baja, pero con el tiempo también quedarán obsoletas.

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

Los objetivos de salida implícitos son miembros de primera clase del grafo de destino global. Al igual que otros destinos, se compilan 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. Se puede hacer referencia a ellos 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 en la que se detallan los nombres y el contenido de cualquier salida implícita que implica 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 destinos, que pueden ser reglas o archivos, y los objetivos de archivo pueden dividirse en objetivos de archivo de origen (o entrada) y destinos de archivo derivados (o de salida). Estos son los aspectos 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 la regla puede corresponder a cero, a uno o más archivos reales en el disco. Es posible que haya archivos en el disco que no tengan un destino correspondiente. Por ejemplo, no se puede hacer referencia a los archivos de objeto .o producidos durante la compilación de C++ desde archivos BUILD ni desde la línea de comandos. De esta manera, la herramienta de compilación puede ocultar ciertos detalles de implementación relacionados con su trabajo. Esto se explica con más detalle en la Referencia de conceptos de COMPILACIÓN.