Definiciones comunes

Denuncia un problema Ver código fuente Nightly · 8.0 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

Contenido

Tokenización de shell de Bourne

Ciertos atributos de cadena de algunas reglas se dividen en varias palabras según las reglas de tokenización de la shell de Bourne: los espacios sin comillas delimitan palabras separadas, y se usan caracteres de virgulillas y comillas simples y dobles para evitar la tokenización.

Los atributos que están sujetos a esta tokenización se indican de forma explícita como tales en sus definiciones en este documento.

Los atributos sujetos a la expansión de variables "Make" y la tokenización de shell de Bourne suelen usarse para pasar opciones arbitrarias a compiladores y otras herramientas. cc_library.copts y java_library.javacopts son ejemplos de esos atributos. En conjunto, estas sustituciones permiten que una variable de cadena única se expanda en una lista de palabras de opción específicas de la configuración.

Expansión de etiquetas

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

Algunos ejemplos de atributos son genrule.cmd y cc_binary.linkopts. Los detalles pueden variar de forma significativa en cada caso, en función de cuestiones como si se expanden las etiquetas relativas, cómo se tratan las etiquetas que se expanden a varios archivos, etcétera. Consulta la documentación de los 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

Es una lista de etiquetas. El valor predeterminado es [].

Archivos que necesita esta regla durante el tiempo de ejecución. Puede enumerar objetivos de archivos o reglas. Por lo general, permite cualquier objetivo.

Los resultados y los archivos de ejecución predeterminados de los destinos en el atributo data deberían aparecer en el área *.runfiles de cualquier ejecutable que genere este destino o tenga una dependencia del entorno de ejecución en él. Esto puede incluir archivos de datos o objetos binarios que se usan cuando se ejecuta el srcs de este objetivo. Consulta la sección Dependencias de datos para obtener más información sobre cómo depender de archivos de datos y usarlos.

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

deps

Es una lista de etiquetas. El valor predeterminado es [].

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

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

La semántica precisa de lo que significa que un objetivo dependa de otro con deps es específica del tipo de regla, y la documentación específica de la regla profundiza en los detalles. En el caso de 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 símbolos definidos en otro módulo escrito en el mismo lenguaje de programación y compilado por separado. En muchos casos, también se permiten dependencias entre idiomas. Por ejemplo, un destino java_library puede depender del código C++ en un destino cc_library, si se indica este último en el atributo deps. Consulta la definición de dependencias para obtener más información.

licenses

Es una lista de cadenas no configurable. El valor predeterminado es ["none"].

Es 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

Es una lista de etiquetas. El valor predeterminado es [].

Archivos que esta regla procesa o incluye. Por lo general, enumera los archivos directamente, pero puede enumerar los objetivos de reglas (como filegroup o genrule) para incluir sus resultados predeterminados.

Las reglas específicas de idioma suelen requerir que los archivos enumerados tengan extensiones de archivo específicas.

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

Es una lista de etiquetas no configurables. 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 forma parte del sistema de restricciones de Bazel, que permite a los usuarios declarar qué objetivos pueden depender entre sí y cuáles no. Por ejemplo, los objetos binarios implementables de forma externa no deben depender de bibliotecas con código secreto de la empresa. Consulta ConstraintSemantics para obtener más detalles.

deprecation

Cadena; no configurable; el valor predeterminado es None

Es un mensaje de advertencia explicativo asociado con este objetivo. Por lo general, se usa para notificar a los usuarios que un objetivo dejó de estar disponible, que otra regla lo reemplazó, que es privado para 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 fácilmente qué cambios se requieren para evitar el mensaje. Si hay un objetivo nuevo que se puede usar como reemplazo directo, es una buena idea migrar a todos los usuarios del objetivo anterior.

Este atributo no tiene efecto en la forma en que se compilan 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 un destino en otro paquete depende de una regla con un atributo deprecation.

Las dependencias intrapaquete están exentas de esta advertencia, de modo que, por ejemplo, la compilación de las pruebas de una regla obsoleta no encuentre 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 puede quitar el objetivo.

distribs

Es una lista de cadenas no configurable. El valor predeterminado es [].

Es una lista de cadenas de métodos 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

Es una lista de etiquetas no configurables. 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 las restricciones que ya estableció 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 {}

Es un diccionario de cadenas que se agregará al exec_properties de una plataforma seleccionada para este objetivo. Consulta exec_properties de la regla platform.

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

features

Es una lista de cadenas de feature. El valor predeterminado es [].

Una función es una etiqueta de cadena que se puede habilitar o inhabilitar en un objetivo. El significado de una función depende de la regla en sí.

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

restricted_to

Es una lista de etiquetas no configurables. El valor predeterminado es [].

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

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

tags

Es una lista de cadenas no configurable. El valor predeterminado es [].

Las etiquetas se pueden usar en cualquier regla. Las etiquetas en las pruebas y las reglas test_suite son útiles para categorizar las pruebas. Las etiquetas en los destinos que no son de prueba se usan para controlar la ejecución en zona de pruebas de las acciones de genrule y Starlark, y para el análisis por parte de humanos 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 objetivo 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 almacenen en la zona de pruebas. Aún se puede almacenar en caché o ejecutar de forma remota. Usa no-cache o no-remote para evitar cualquiera de estas opciones o ambas.
  • La palabra clave no-cache hace que la acción o la prueba nunca se almacenen en caché (de forma local o remota). Nota: A los efectos de esta etiqueta, la caché del disco se considera una caché local, mientras que las cachés de HTTP y gRPC se consideran remotas. Otras cachés, como Skyframe o la caché de acciones persistentes, no se ven afectadas.
  • La palabra clave no-remote-cache hace que la acción o la prueba nunca se almacenen en caché de forma remota (pero se pueden almacenar en caché de forma local o ejecutar de forma remota). Nota: A los efectos de esta etiqueta, la caché del disco se considera una caché local, mientras que las cachés de HTTP y gRPC se consideran remotas. Otras cachés, como Skyframe o la caché de acciones persistentes, no se ven afectadas. 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 ejecuten de forma remota (pero se pueden 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 forma remota. Esto equivale a usar no-remote-cache y no-remote-exec.
  • La palabra clave no-remote-cache-upload inhabilita la parte de carga de la caché remota de un inicio. no inhabilita la ejecución remota.
  • La palabra clave local impide que la acción o la prueba se almacenen en caché de forma remota, se ejecuten de forma remota o se ejecuten dentro de la zona de pruebas. En el caso de las genrules y las 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 dentro de la zona de pruebas. Esta etiqueta solo tiene efecto si está habilitada la zona de pruebas.
  • La palabra clave block-network bloquea el acceso a la red externa desde dentro de la zona de pruebas. En este caso, solo se permite la comunicación con localhost. Esta etiqueta solo tiene efecto si está habilitada la zona de pruebas.
  • requires-fakeroot ejecuta la prueba o 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 en las pruebas se usan para anotar el rol 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 cualquier capacidad de anotación del entorno de ejecución. El uso de etiquetas y elementos de tamaño brinda flexibilidad para ensamblar paquetes de pruebas basados en 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á que la prueba se ejecute en el modo "exclusivo", lo que garantiza que no se ejecuten otras pruebas al mismo tiempo. Estas pruebas se ejecutarán de forma serial después de que se completen todas las pruebas de actividad de compilación y no exclusivas. La ejecución remota está inhabilitada para esas pruebas porque Bazel no tiene control sobre lo que se está ejecutando en una máquina remota.
  • exclusive-if-local forzará que la prueba se ejecute 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 destinos de nivel superior para compilar o ejecutar los comandos build, test y coverage. No afecta la expansión de comodín de destino ni del paquete de pruebas en otros contextos, incluido el comando query. Ten en cuenta que manual no implica que un destino no se deba compilar o ejecutar automáticamente mediante sistemas de compilación o prueba continuos. Por ejemplo, puede ser conveniente excluir un destino de bazel test ... porque requiere marcas específicas de Bazel, pero aún así incluirlo en ejecuciones de pruebas continuas o previas al envío configuradas correctamente.
  • La palabra clave external forzará que la prueba se ejecute de forma incondicional (independientemente del valor de --cache_test_results).
Consulta Convenciones de etiquetas en la Enciclopedia de pruebas para obtener más convenciones sobre las etiquetas adjuntas a los destinos de prueba.
target_compatible_with

Es una lista de etiquetas. El valor predeterminado es [].

Es una lista de constraint_value que deben estar presentes en la plataforma de destino para que esta se considere compatible. Esto se suma a cualquier restricción que ya haya establecido el tipo de regla. Si la plataforma de destino no satisface todas las restricciones enumeradas, se considera que el destino es incompatible. Se omiten los destinos incompatibles para la compilación y las pruebas cuando se expande el patrón de destino (p.ej., //..., :all). Cuando se especifican de forma explícita en la línea de comandos, los destinos incompatibles hacen que Bazel imprima un error y provoque una compilación o una prueba fallida.

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

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

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

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

testonly

Booleano; no configurable; el valor predeterminado es False, excepto para los destinos de prueba y suite de pruebas

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

De manera equivalente, una regla que no sea testonly no puede depender de ninguna regla que sea testonly.

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

El objetivo de este atributo es indicar que el objetivo no debe estar contenido en objetos binarios que se lanzan a producción.

Debido a que testonly se aplica de forma forzosa 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 dependencias, se debe aplicar con prudencia. Por ejemplo, los stubs y los objetos falsos 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, es probable que no deban marcarse como testonly. Por el contrario, las reglas que son peligrosas incluso para vincular, quizás porque anulan de forma incondicional el comportamiento normal, deben marcarse como solo para pruebas.

toolchains

Es una lista de etiquetas no configurables. 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. Estos incluyen lo siguiente:

  • @bazel_tools//tools/cpp:current_cc_toolchain
  • @rules_java//toolchains:current_java_runtime

Ten en cuenta que esto es distinto del concepto de resolución de 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ífico usará un destino.

visibility

Es una lista de etiquetas; no se puede configurar; el valor predeterminado varía.

El atributo visibility controla si los objetivos de otras ubicaciones pueden depender del objetivo. Consulta la documentación sobre la visibilidad.

Para los destinos declarados directamente en un archivo BUILD o en macros heredadas que se llaman desde un archivo BUILD, el valor predeterminado es el default_visibility del paquete si se especifica, o bien ["//visibility:private"]. Para los destinos declarados en una o más macros simbólicas, el valor predeterminado siempre es solo ["//visibility:private"] (lo que hace que solo se pueda usar dentro del paquete que contiene el código de la macro).

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

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

Atributo Descripción
args

Es una lista de cadenas sujeta a la sustitución de $(location) y "Make variable", y a la tokenización de Bourne shell. El valor predeterminado es [].

Son los 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 de --test_arg especificado en la línea de comandos bazel test.

env

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

Especifica variables de entorno adicionales que se deben configurar 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. Para tus propias reglas de Starlark, puedes agregar un atributo "env" y usarlo para propagar un proveedor de TestEnvironment.

env_inherit

Es una lista de cadenas. El valor predeterminado es [].

Especifica variables de entorno adicionales para heredar del 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

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

Especifica la "carga" de un objetivo de prueba: cuánto tiempo o recursos necesita para ejecutarse.

Las pruebas de unidades se consideran “pequeñas”, las pruebas de integración “medianas” y las pruebas 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 es para todas las pruebas del destino BUILD, no para cada prueba individual. Cuando la prueba se ejecuta de forma local, size también se usa con fines de programación: Bazel intenta respetar --local_{ram,cpu}_resources y no abrumar a la máquina local ejecutando muchas pruebas pesadas al mismo tiempo.

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

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 Larga (15 minutos)
enorme 800 1 eterno (60 minutos)

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

timeout

Cadena "short", "moderate", "long" o "eternal"; no configurable; el valor predeterminado se deriva del atributo size de la prueba

Es la cantidad de tiempo que se espera que se ejecute la prueba antes de que se muestre el 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 otros tiempos que no sean los anteriores, el tiempo de espera de la prueba se puede anular con la marca --test_timeout de Bazel, p.ej., para ejecutarlo de forma manual en condiciones que se sabe que son lentas. Los valores de --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 cree la prueba.

flaky

Booleano; no configurable; el valor predeterminado es False

Marca la prueba como inestable.

Si se establece, 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, por lo general, no se recomienda el uso de este atributo. Las pruebas deben aprobarse de forma confiable cuando se confirman sus aserciones.

shard_count

Es un número entero no negativo menor o igual a 50. El valor predeterminado es -1.

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

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

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

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

Consulta Cómo probar el particionamiento en la Enciclopedia de pruebas para obtener detalles sobre el particionamiento.

local

Booleano; no configurable; el valor predeterminado es False

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

Establecerlo en "true" equivale a proporcionar "local" como etiqueta (tags=["local"]).

Atributos comunes a todas las reglas binarias (*_binary)

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

Atributo Descripción
args

Es una lista de cadenas sujeta a sustitución de $(location) y "Make variable", y tokenización de Bourne shell. No se puede configurar. El valor predeterminado es [].

Son 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 de 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, cuando ejecutas el objeto binario de forma manual en bazel-bin/).

env

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

Especifica variables de entorno adicionales que se establecerán cuando bazel run ejecute el destino.

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 establecen cuando ejecutas el destino fuera de Bazel (por ejemplo, cuando ejecutas el objeto binario de forma manual en bazel-bin/).

output_licenses

Es una lista de cadenas. El valor predeterminado es [].

Las licencias de los archivos de salida que genera este 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 objetivo se compila de diferentes maneras. Específicamente, 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 solicita el destino. Esto 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 diferentes arquitecturas de destino. Si ejecutas bazel build :multiplatform_lib --cpu x86, se compilará el destino con x86_impl.cc, mientras que si sustituyes --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 según los criterios de config_setting o constraint_value que satisface la configuración del objetivo.

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 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 destino. 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 antes de poder determinar cómo resolver un select().

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

Objetivos de salida implícitos

Los resultados implícitos en C++ dejaron de estar disponibles. Si es posible, evita usarlo en otros idiomas. Aún no tenemos una ruta de baja, pero también dejarán de estar disponibles.

Cuando defines una regla de compilación en un archivo BUILD, declaras de forma explícita un nuevo destino de regla con nombre en un paquete. Muchas funciones de la regla de compilación también implícitamente implican uno o más destinos de archivo de salida, cuyo contenido y significado son específicos de la regla. Por ejemplo, cuando declaras de forma explícita una regla java_binary(name='foo', ...), también declaras de forma implícita un objetivo 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 destinos de salida implícitos son miembros de primera clase del gráfico 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 los archivos BUILD y se pueden observar en el resultado de 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 los resultados implícitos que implica una declaración de ese tipo de regla.

Una distinción importante, pero algo 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 se pueden dividir en objetivos de archivo de origen (o entrada) y objetivos de archivo derivados (o salida). 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 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. Es posible que haya archivos en el disco que no tengan el destino correspondiente. Por ejemplo, no se puede hacer referencia a los archivos de objetos .o que se producen durante la compilación de C++ 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 realiza su trabajo. Esto se explica con más detalle en la Referencia de conceptos de BUILD.