Acción
Un comando para ejecutar durante la compilación, por ejemplo, una llamada a un compilador que toma artefactos como entradas y los produce como salidas. Incluye metadatos como los argumentos de la línea de comandos, la clave de acción, las variables de entorno y los artefactos de entrada y salida declarados.
Consulta también: Documentación sobre las reglas
Caché de acciones
Una caché en disco que almacena una asignación de las acciones ejecutadas a los resultados que crearon. La clave de caché se conoce como clave de acción. Un componente principal del modelo de incrementalidad de Bazel. La caché se almacena en el directorio base de salida y, por lo tanto, sobrevive a los reinicios del servidor de Bazel.
Gráfico de acción
Un gráfico en la memoria de las acciones y los artefactos que estas acciones leen y generan. El gráfico puede incluir artefactos que existen como archivos de origen (por ejemplo, en el sistema de archivos) y artefactos intermedios y finales generados que no se mencionan en los archivos BUILD. Se produce durante la fase de análisis y se usa durante la fase de ejecución.
Consulta de grafo de acción (aquery)
Una herramienta de consulta que puede consultar sobre las acciones de compilación. Esto permite analizar cómo lo hacen las reglas de compilación en las compilaciones de trabajo reales.
Tecla de acción
La clave de caché de una acción. Se calcula en función de los metadatos de la acción, que pueden incluir el comando que se ejecutará en la acción, las marcas del compilador, las ubicaciones de la biblioteca o los encabezados del sistema, según la acción. Permite que Bazel almacene en caché o invalide acciones individuales de manera determinista.
Fase de análisis
La segunda fase de una compilación. Procesa el gráfico de destino especificado en archivos BUILD para producir un gráfico de acciones en la memoria que determina el orden de las acciones que se ejecutarán durante la fase de ejecución. Esta es la fase en la que se evalúan las implementaciones de reglas.
Artifact
Un archivo de origen o un archivo generado. También puede ser un directorio de archivos, conocido como artefactos de árbol.
Un artefacto puede ser una entrada para varias acciones, pero solo lo debe generar una acción, como máximo.
Se puede abordar un artefacto que corresponde a un destino de archivo mediante una etiqueta.
Aspecto
Un mecanismo para que las reglas creen acciones adicionales en sus dependencias. Por ejemplo, si el destino A depende de B, se puede aplicar un aspecto en A que desvía hacia arriba un perímetro de dependencia hasta B y ejecute acciones adicionales en B para generar y recopilar archivos de salida adicionales. Estas acciones adicionales se almacenan en caché y se reutilizan entre los destinos que requieren el mismo aspecto. Se crea con la función aspect() de la API de Starlark Build. Se puede usar, por ejemplo, a fin de generar metadatos para IDE y crear acciones de análisis con lint.
Consulta también: Documentación sobre los aspectos
Aspecto en aspecto
Un mecanismo de composición en el que los aspectos se pueden aplicar a los resultados de otros aspectos. Por ejemplo, un aspecto que genera información para que los IDE la usen se puede aplicar sobre un aspecto que genera archivos .java a partir de un proto.
Para que un aspecto A se aplique sobre el aspecto B, los proveedores que B anuncia en su atributo provides deben coincidir con lo que A declara que desea en su atributo required_aspect_providers.
Atributo
Un parámetro para una regla, que se usa para expresar información de compilación por destino.
Entre los ejemplos, se incluyen srcs, deps y copts, que declaran respectivamente los archivos de origen, las dependencias y las opciones del compilador personalizado de un destino. Los atributos específicos disponibles para un objetivo determinado dependen de su tipo de regla.
Bazelrc
El archivo de configuración de Bazel se usa para cambiar los valores predeterminados de las marcas
de inicio y las marcas de comando, y para definir grupos
comunes de opciones que, luego, se pueden configurar juntos en la línea de comandos de Bazel con
una marca --config. Bazel puede combinar la configuración de varios archivos de Bazelrc
(en todo el sistema, por espacio de trabajo, por usuario o desde una ubicación personalizada), y un
archivo bazelrc también puede importar la configuración de otros archivos bazelrc.
Blaze
Es la versión interna de Google de Bazel. el principal sistema de compilación de Google para su repositorio mono.
Archivo BUILD
Un archivo BUILD es el archivo de configuración principal que le indica a Bazel qué software
debe compilar, cuáles son sus dependencias y cómo compilarlas. Bazel
toma un archivo BUILD como entrada y lo usa para crear un gráfico de dependencias
y derivar las acciones que deben completarse para compilar resultados de software
intermedios y finales. Un archivo BUILD marca un directorio y cualquier subdirectorio que no contenga un archivo BUILD como paquete, y puede contener destinos creados por reglas. El archivo también puede tener el nombre BUILD.bazel.
Archivo BUILD.bazel
Consulta Archivo BUILD. Tiene prioridad sobre un archivo BUILD en el mismo directorio.
Archivo .bzl
Es un archivo que define reglas, macros y constantes escritas en Starlark. Luego, estos se pueden importar a archivos BUILD con la función load().
Gráfico de compilación
El gráfico de dependencias que Bazel construye y recorre para realizar una compilación. Incluye nodos como objetivos, objetivos configurados, acciones y artefactos. Una compilación se considera completa cuando todos los artefactos de los que depende un conjunto de destinos solicitados se verifican como actualizados.
Configuración de la compilación
Una configuración definida por Starlark. Las transiciones pueden establecer configuraciones de compilación para cambiar la configuración de un subgrafo. Si se expone al usuario como una marca de línea de comandos, también conocida como marca de compilación.
Compilación limpia
Una compilación que no usa los resultados de compilaciones anteriores. Por lo general, esto es más lento que una compilación incremental, pero se considera que es más correcto. Bazel garantiza que las compilaciones incrementales y limpias siempre sean correctas.
Modelo cliente-servidor
El cliente de línea de comandos de bazel inicia de forma automática un servidor en segundo plano en la
máquina local para ejecutar los comandos de Bazel. El servidor persiste en todos los comandos, pero se detiene automáticamente después de un período de inactividad (o de manera explícita mediante el cierre de Bazel). Dividir Bazel en un servidor y un cliente ayuda a amortizar el tiempo de inicio de JVM y admite compilaciones incrementales más rápidas, ya que el gráfico de acciones permanece en la memoria de todos los comandos.
Comando
Se usa en la línea de comandos para invocar diferentes funciones de Bazel, como bazel
build, bazel test, bazel run y bazel query.
Marcas de comando
Un conjunto de marcas específicas de un comando. Las marcas de comando se especifican después del comando (bazel build <command flags>). Las marcas se pueden aplicar a uno o más comandos. Por ejemplo, --configure es una marca exclusiva para el comando bazel sync, pero --keep_going se aplica a sync, build, test y otros elementos. Las marcas suelen usarse para fines de configuración, por lo que los cambios en los valores de las marcas pueden hacer que Bazel invalide los gráficos en la memoria y reinicie la fase de análisis.
Configuración
Información fuera de las definiciones de regla que afecta la manera en que las reglas generan acciones. Cada compilación tiene al menos una configuración que especifica la plataforma de destino, las variables de entorno de acción y las marcas de compilación de la línea de comandos. Las transiciones pueden crear configuraciones adicionales, como para herramientas de host o compilación cruzada.
Consulta también: Configuraciones
Recorte de configuración
El proceso de incluir solo las partes de la configuración que un objetivo realmente necesita. Por ejemplo, si compilas el objeto binario //:j de Java con la dependencia //:c de C++, es un desperdicio incluir el valor de --javacopt en la configuración de //:c, ya que cambiar --javacopt rompe innecesariamente la capacidad de almacenamiento en caché de la compilación de C++.
Consulta configurada (cquery)
Una herramienta de consulta que realiza consultas sobre destinos configurados (después de que se completa la fase de análisis) Esto significa que select() y las marcas de compilación (como --platforms) se reflejan con precisión en los resultados.
Consulta también: documentación de cquery
Destino configurado
El resultado de evaluar un objetivo con una configuración. Para la fase de análisis, esto se logra combinando las opciones de la compilación con los destinos que se deben compilar.
Por ejemplo, si //:foo compila para dos arquitecturas diferentes en la misma
compilación, tendrá dos destinos configurados: <//:foo, x86> y <//:foo, arm>.
Precisión
Una compilación es correcta cuando su salida refleja fielmente el estado de sus entradas transitivas. Para lograr compilaciones correctas, Bazel se esfuerza por ser hermético y reproducible, además de hacer que el análisis de la compilación y la ejecución de acciones sean deterministas.
Dependencia
Un perímetro dirigido entre dos objetivos Un //:foo de destino tiene una dependencia de //:bar de destino si los valores del atributo de //:foo contienen una referencia a //:bar. //:foo tiene una dependencia de acciones en //:bar si una acción de //:foo depende de un artefacto de entrada creado por una acción en //:bar.
En algunos contextos, también podría hacer referencia a una dependencia externa; consulta módulos.
Depset
Es una estructura de datos para recopilar datos sobre dependencias transitivas. Se optimizó para que la combinación de dependencias sea eficiente en el tiempo y el espacio, ya que es común tener dependencias muy grandes (cientos de miles de archivos). Se implementa para hacer referencia de manera recursiva a otras salidas por razones de eficiencia del espacio. Las implementaciones de reglas no deben "compactar" los repositorios convirtiéndolos en listas, a menos que la regla esté en el nivel superior del gráfico de compilación. Compactar los depsets grandes genera un gran consumo de memoria. También se conocen como conjuntos anidados en la implementación interna de Bazel.
Consulta también: Documentación de Depset
Caché de disco
Un almacén local de BLOB en el disco para la función de almacenamiento en caché remoto. Se puede usar en conjunto con un almacén de BLOB remoto real.
Distdir
Un directorio de solo lectura que contiene archivos que Bazel recuperaría de Internet mediante reglas de repositorio. Permite que las compilaciones se ejecuten por completo sin conexión.
Ejecución dinámica
Es una estrategia de ejecución que selecciona entre la ejecución local y remota según varias heurísticas y usa los resultados de ejecución del método exitoso más rápido. Algunas acciones se ejecutan más rápido de forma local (por ejemplo, la vinculación) y otras son más rápidas de forma remota (por ejemplo, la compilación altamente paralelizable). Una estrategia de ejecución dinámica puede proporcionar los mejores tiempos de compilación incrementales y limpios posibles.
Fase de ejecución
La tercera fase de una compilación. Ejecuta las acciones en el gráfico de acciones creado durante la fase de análisis. Estas acciones invocan ejecutables (compiladores, secuencias de comandos) para leer y escribir artefactos. Las estrategias de generación controlan cómo se ejecutan estas acciones: de forma local, remota, dinámica, en zona de pruebas, Docker, etcétera.
Raíz de ejecución
Un directorio en el directorio base de salida del lugar de trabajo en el que las acciones locales se ejecutan en compilaciones que no están en la zona de pruebas. El contenido del directorio son, en su mayoría, symlinks de artefactos de entrada del lugar de trabajo. La raíz de ejecución también contiene symlinks a repositorios externos como otras entradas y el directorio bazel-out para almacenar resultados. Se preparan durante la fase de carga mediante la creación de un bosque de symlink de los directorios que representan el cierre transitivo de los paquetes de los que depende una compilación. Se puede acceder con bazel info
execution_root en la línea de comandos.
Archivo
Consulta Artefacto.
Hermeticidad
Una compilación es hermética si no hay influencias externas en sus operaciones de compilación y prueba, lo que ayuda a garantizar que los resultados sean deterministas y correctos. Por ejemplo, las compilaciones herméticas generalmente no permiten el acceso de red a las acciones, restringen el acceso a entradas declaradas, usan marcas de tiempo y zonas horarias fijas, restringen el acceso a variables de entorno y usan valores iniciales fijos para generadores de números aleatorios.
Compilación incremental
Una compilación incremental reutiliza los resultados de compilaciones anteriores para reducir el tiempo de compilación y el uso de recursos. La verificación de dependencias y el almacenamiento en caché tienen como objetivo producir resultados correctos para este tipo de compilación. Una compilación incremental es lo opuesto a una compilación limpia.
Etiqueta
Un identificador para un objetivo. Por lo general, tiene el formato @repo//path/to/package:target, en el que repo es el nombre (aparente) del repositorio que contiene el destino, path/to/package es la ruta al directorio que contiene el archivo BUILD que declara el destino (este directorio también se conoce como paquete) y target es el nombre del destino en sí. Según la situación, es posible que se omitan partes de esta sintaxis.
Consulta también: Etiquetas
Fase de carga
Es la primera fase de una compilación en la que Bazel ejecuta archivos BUILD para
crear paquetes. En esta fase, se evalúan las macros y ciertas funciones, como glob(). Intercalado con la segunda fase de la compilación, la fase de análisis, para crear un grafo de destino.
Macro
Un mecanismo para componer varias declaraciones de destino rule juntas en una sola función Starlark. Permite la reutilización de patrones comunes de declaración de reglas en archivos BUILD. Se expande a las declaraciones de objetivo de la regla subyacentes durante la fase de carga.
Consulta también: Documentación de macros
Mnemónico
Es una cadena corta y legible por humanos que el autor de la regla selecciona para comprender rápidamente lo que hace una acción en la regla. Los mnemónicos se pueden usar como identificadores para las selecciones de estrategias de generación. Algunos ejemplos de mnemotecnias de acciones son Javac de reglas de Java, CppCompile de reglas de C++ y AndroidManifestMerger de reglas de Android.
Módulo
Un proyecto de Bazel que puede tener varias versiones, cada una de las cuales puede tener dependencias en otros módulos. Esto es análogo a los conceptos conocidos de otros sistemas de administración de dependencias, como un artefacto de Maven, un paquete de npm, un módulo de Go o un contenedor de Cargo. Los módulos son la base del sistema de administración de dependencias externo de Bazel.
Cada módulo está respaldado por un repositorio con un archivo MODULE.bazel en la raíz. Este archivo contiene metadatos sobre el módulo en sí (como su nombre y versión), sus dependencias directas y muchos otros datos, incluidos los registros de la cadena de herramientas y la entrada de extensión del módulo.
Los metadatos del módulo se alojan en los registros de Bazel.
Consulta también: Módulos de Bazel
Extensión del módulo
Es un fragmento de lógica que se puede ejecutar para generar repositorios mediante la lectura de entradas desde todo el gráfico de dependencia del módulo y la invocación de reglas de repositorio. Las extensiones de módulo tienen capacidades similares a las reglas de repositorio, lo que les permite acceder a Internet, realizar E/S de archivos, etcétera.
Consulta también: Extensiones de módulos
Reglas nativas
Las reglas que se compilan en Bazel y se implementan en Java. Estas reglas aparecen en los archivos .bzl como funciones del módulo nativo (por ejemplo, native.cc_library o native.java_library). Las reglas definidas por el usuario (no nativas) se crean con Starlark.
Base de salida
Un directorio específico de workspace para almacenar archivos de salida de Bazel. Se usa para separar los resultados del árbol de fuentes del lugar de trabajo (el repositorio principal). Se encuentra en la raíz de usuario de salida.
Grupos de salida
Un grupo de archivos que se espera que se compile cuando Bazel termine de compilar un
destino. Las reglas colocan sus resultados habituales en el "grupo de salida predeterminado" (p. ej., el archivo .jar de un java_library, .a y .so para objetivos cc_library). El grupo de salida predeterminado es aquel cuyos artefactos se compilan cuando se solicita un destino en la línea de comandos.
Las reglas pueden definir más grupos de salida con nombre que se pueden especificar de forma explícita en archivos BUILD (regla filegroup) o en la línea de comandos (marca --output_groups).
Raíz de usuario de salida
Un directorio específico del usuario para almacenar los resultados de Bazel. El nombre del directorio deriva del nombre de usuario del sistema del usuario. Evita las colisiones de archivos de salida si varios usuarios compilan el mismo proyecto en el sistema al mismo tiempo. Contiene subdirectorios que corresponden a las salidas de compilación de lugares de trabajo individuales, también conocidos como bases de salida.
Paquete
Es el conjunto de destinos definido por un archivo BUILD. El nombre de un paquete es la ruta de acceso del archivo BUILD relativa a la raíz del repositorio. Un paquete puede contener subpaquetes o subdirectorios con archivos BUILD, lo que forma una jerarquía de paquetes.
Grupo de paquetes
Un objetivo que representa un conjunto de paquetes Se suele usar en los valores del atributo visibility.
Plataforma
Es un “tipo de máquina” involucrado en una compilación. Esto incluye la máquina en la que se ejecuta Bazel (la plataforma “host”), las herramientas de compilación de las máquinas se ejecutan en las plataformas “ejecutivas” y las máquinas para los que se compilan los destinos de las máquinas (“plataformas de destino”).
Proveedor
Es un esquema que describe una unidad de información para pasar entre objetivos de la regla junto con las relaciones de dependencia. Por lo general, contiene información como opciones del compilador, archivos de origen o de salida transitivos y metadatos de compilación. Por lo general, se usa junto con depsets para almacenar de manera eficiente los datos transitivos acumulados. Un ejemplo de un proveedor integrado es DefaultInfo.
Consulta también: Documentación para proveedores
Consulta (concepto)
Es el proceso de analizar un gráfico de compilación para comprender las propiedades de destino y las estructuras de dependencia. Bazel admite tres variantes de consulta: query, cquery y aquery.
query (comando)
Una herramienta de consulta que opera sobre el grafo de destino posterior a la fase de carga de la compilación. Este proceso es relativamente rápido, pero no se pueden analizar los efectos de select(), las marcas de compilación, los artefactos ni las acciones de compilación.
Consulta también: Instructivo para consultas, Referencia de consultas
Repositorio
Un árbol de directorios con un archivo de marcador de límite en la raíz que contiene archivos de origen que se pueden usar en una compilación de Bazel A menudo se abrevia como repo.
Un archivo de marcador de límite del repositorio puede ser MODULE.bazel (lo que indica que este repositorio representa un módulo de Bazel), REPO.bazel o, en contextos heredados, WORKSPACE o WORKSPACE.bazel. Cualquier archivo de marcador de límite del repositorio indicará el límite de un repositorio; pueden coexistir varios archivos de este tipo en un directorio.
El repositorio principal es el repositorio en el que se ejecuta el comando actual de Bazel.
Para definir los repositorios externos, especifica módulos en archivos MODULE.bazel
o invoca reglas de repositorio en extensiones
de módulos. Se pueden recuperar a pedido en una ubicación “mágica” predeterminada del disco.
Cada repositorio tiene un nombre canónico único y constante, y nombres aparentes potencialmente diferentes cuando se visualiza desde otros repositorios.
Consulta también: Descripción general de las dependencias externas
Caché del repositorio
Una caché compartida de contenido direccionable de archivos descargados por Bazel para compilaciones,
que se puede compartir entre espacios de trabajo. Habilita compilaciones sin conexión después de la descarga inicial. Por lo general, se usa para almacenar en caché archivos descargados a través de reglas del repositorio, como http_archive, y APIs de reglas de repositorio, como repository_ctx.download. Los archivos se almacenan en caché solo si se especifican sus sumas de verificación SHA-256 para la descarga.
Regla del repositorio
Un esquema para las definiciones de repositorios que le indica a Bazel cómo materializar (o “recuperar”) un repositorio. A menudo se abrevia como regla del repositorio.
Bazel invoca de forma interna las reglas de repositorio para definir repositorios respaldados por
módulos, o pueden invocarse mediante extensiones de módulos.
Las reglas de repositorio pueden acceder a Internet o realizar operaciones de E/S de archivos. La regla de repositorio más común es http_archive para descargar un archivo que contenga archivos de origen de Internet.
Consulta también: Documentación de reglas de repositorio
Reproducibilidad
La propiedad de una compilación o prueba de que un conjunto de entradas a la compilación o la prueba siempre producirá el mismo conjunto de salidas siempre, sin importar el tiempo, el método o el entorno. Ten en cuenta que esto no implica necesariamente que los resultados sean correctos o que sean los deseados.
Regla
Un esquema para definir destinos de la regla en un archivo BUILD, como cc_library. Desde la perspectiva del autor de un archivo BUILD, una regla consta de un conjunto de atributos y lógica de caja negra. La lógica le indica al destino de la regla cómo producir artefactos de salida y pasar información a otros destinos de la regla. Desde la perspectiva de los autores de .bzl, las reglas son la forma principal de extender Bazel para admitir nuevos lenguajes de programación y entornos.
Se crea una instancia de las reglas para producir objetivos de reglas en la fase de carga. En la fase de análisis, los objetivos comunican información a sus dependencias descendentes en forma de proveedores y registran acciones que describen cómo generar sus artefactos de salida. Estas acciones se ejecutan en la fase de ejecución.
Consulta también: Documentación sobre las reglas
Objetivo de la regla
Un objetivo que es una instancia de una regla. Compara esto con los objetivos de archivos y los grupos de paquetes. No se debe confundir con la regla.
Archivos de ejecución
Las dependencias del entorno de ejecución de un destino ejecutable. Por lo general, el ejecutable es el resultado ejecutable de una regla de prueba, y los archivos de ejecución son dependencias de datos del entorno de ejecución de la prueba. Antes de invocar el archivo ejecutable (durante la prueba de Bazel), Bazel prepara el árbol de archivos de ejecución junto con el ejecutable de prueba según la estructura de su directorio de origen.
Consulta también: Documentación de archivos de ejecución
Zona de pruebas
Es una técnica para aislar una acción en ejecución dentro de una raíz de ejecución restringida y temporal, lo que ayuda a garantizar que no lea entradas no declaradas ni escriba salidas no declaradas. Las zonas de pruebas mejoran en gran medida la hermeticidad, pero, por lo general, tienen un costo de rendimiento y requieren compatibilidad con el sistema operativo. El costo de rendimiento depende de la plataforma. En Linux, no es significativo, pero en macOS puede hacer que la zona de pruebas sea inutilizable.
Skyframe
Skyframe es el marco de trabajo de evaluación incremental, funcional y paralelo principal de Bazel.
Estampado
Una función para incorporar información adicional en artefactos compilados por Bazel. Por ejemplo, se puede usar para el control de la fuente, el tiempo de compilación y otra información relacionada con el lugar de trabajo o el entorno para las compilaciones de lanzamiento.
Habilítalo a través de la marca --workspace_status_command y las reglas que admiten el atributo de sello.
Starlark
El lenguaje de extensión para escribir reglas y macros Un subconjunto restringido de Python (sintáctica y gramaticalmente) destinado al propósito de configuración y un mejor rendimiento. Usa la extensión del archivo .bzl. Los archivos BUILD usan una versión aún más restringida de Starlark (por ejemplo, no usar definiciones de la función def), antes conocida como Skylark.
Consulta también: documentación sobre lenguaje de Starlark
Marcas de inicio
Es el conjunto de marcas especificadas entre bazel y el comando, por ejemplo, la compilación --host_jvm_debug de bazel. Estas marcas modifican la
configuración del servidor de Bazel, por lo que cualquier modificación de
las marcas de inicio hace que se reinicie el servidor. Las marcas de inicio no son específicas de ningún comando.
Objetivo
Es un objeto que se define en un archivo BUILD y que se identifica con una etiqueta. Los destinos representan las unidades que se pueden compilar de un lugar de trabajo desde la perspectiva del usuario final.
Un objetivo que se declara mediante la creación de una instancia de una regla se denomina objetivo de la regla. Según la regla, estos pueden ejecutarse (como cc_binary) o probarse (como cc_test). Los objetivos de la regla suelen depender de otros objetivos a través de sus atributos (como deps). Estas dependencias forman la base del gráfico de destino.
Además de los objetivos de las reglas, también existen los objetivos de archivos y los de grupos de paquetes. Los destinos de archivo corresponden a los artefactos a los que se hace referencia en un archivo BUILD. Como un caso especial, el archivo BUILD de cualquier paquete siempre se considera un archivo de origen de destino en ese paquete.
Los objetivos se descubren durante la fase de carga. Durante la fase de análisis, los objetivos se asocian con las configuraciones de compilación para formar objetivos configurados.
Gráfico de destino
Un gráfico en la memoria de objetivos y sus dependencias. Se generan durante la fase de carga y se usan como entrada en la fase de análisis.
Patrón de objetivo
Una manera de especificar un grupo de destinos en la línea de comandos. Los patrones que se usan con mayor frecuencia son :all (todos los objetivos de la regla), :* (todos los objetivos de la regla y el archivo), ... (el paquete actual y todos los subpaquetes de forma recurrente). Se puede usar en combinación. Por ejemplo, //...:* significa todos los destinos de reglas y archivos en todos los paquetes de manera recurrente desde la raíz del lugar de trabajo.
Pruebas
Los destinos de las reglas crearon instancias de las reglas de prueba y, por lo tanto, contienen un ejecutable de prueba. Un código de retorno de cero luego de la finalización del ejecutable indica que la prueba se completó correctamente. El contrato exacto entre Bazel y las pruebas (como las variables de entorno de prueba y los métodos de recopilación de resultados de pruebas) se especifica en la enciclopedia de pruebas.
Cadena de herramientas
Un conjunto de herramientas para generar resultados para un lenguaje. Por lo general, una cadena de herramientas incluye compiladores, vinculadores, intérpretes o linters. Una cadena de herramientas también puede variar según la plataforma, es decir, los componentes de la cadena de herramientas de un compilador Unix pueden diferir para la variante de Windows, aunque la cadena de herramientas sea para el mismo lenguaje. Seleccionar la cadena de herramientas correcta para la plataforma se conoce como resolución de la cadena de herramientas.
Objetivo de nivel superior
Un destino de compilación es de nivel superior si se solicita en la línea de comandos de
Bazel. Por ejemplo, si //:foo depende de //:bar y se llama a bazel build //:foo, para esta compilación, //:foo es de nivel superior y //:bar no de nivel superior, aunque se deberán compilar ambos destinos. Una diferencia importante
entre los objetivos de nivel superior y los que no son de nivel superior es que las marcas
de comandos establecidas en la línea de comandos de Bazel (o mediante
.bazelrc) establecerán la configuración de los objetivos de
nivel superior, pero se podrían modificar con una transición para los objetivos
que no son de
nivel superior.
Condición
Es una asignación del estado de la configuración de un valor a otro. Permite que los destinos en el gráfico de compilación tengan configuraciones diferentes, incluso si se crearon instancias de la misma regla. Un uso común de las transiciones es con las transiciones divididas, en las que ciertas partes del gráfico de destino se bifurcan con configuraciones distintas para cada bifurcación. Por ejemplo, se puede compilar un APK de Android con objetos binarios nativos compilados para ARM y x86 usando transiciones divididas en una sola compilación.
Consulta también: Transiciones definidas por el usuario
Artefacto de árbol
Un artefacto que representa una colección de archivos. Dado que estos archivos no son artefactos en sí mismos, una acción que opere en ellos debe registrar el artefacto de árbol como su entrada o salida.
Visibilidad
Uno de los dos mecanismos que evitan dependencias no deseadas en el sistema de compilación: la visibilidad del objetivo para controlar si otros destinos pueden depender de un objetivo y la visibilidad de la carga para controlar si un archivo BUILD o .bzl puede cargar un archivo .bzl determinado. Sin contexto, por lo general, "visibilidad" se refiere a la visibilidad del objetivo.
Consulta también: Documentación sobre visibilidad
Espacio de trabajo
El entorno que comparten todos los comandos de Bazel se ejecutan desde el mismo repositorio principal.
Ten en cuenta que, históricamente, los conceptos de "repositorio" y "lugar de trabajo" se combinaron. El término "espacio de trabajo" a menudo se usa para referirse al repositorio principal y, a veces, incluso se usa como sinónimo de "repositorio". Para mayor claridad, se debe evitar ese uso.