Acción
Un comando para ejecutar durante la compilación, por ejemplo, una llamada a un compilador que toma artefactos como entradas y produce otros artefactos 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 de las reglas
Caché de acciones
Una caché en el 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 central 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), así como artefactos intermedios o finales generados que no se mencionan en los archivos BUILD. Se generan durante la fase de análisis y se usan durante la fase de ejecución.
Consulta de gráfico de acción (aquery)
Herramienta de consulta que puede consultar sobre las acciones de compilación. Esto permite analizar cómo las reglas de compilación se traducen en las compilaciones de trabajo reales.
Tecla de acción
La clave de caché de una acción. Se calculan a partir de metadatos de acción, que pueden incluir el comando que se ejecutará en la acción, marcas del compilador, ubicaciones de bibliotecas o 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
Segunda fase de una compilación. Procesa el gráfico de destino especificado en los archivos BUILD para producir un gráfico de acciones en la memoria que determina el orden de las acciones que se deben ejecutar durante la fase de ejecución. Esta es la fase en la que se evalúan las implementaciones de reglas.
Artefacto
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 debe generarse mediante una acción como máximo.
Un artefacto que corresponde a un destino de archivo se puede identificar mediante una etiqueta.
Aspecto
Un mecanismo para que las reglas creen acciones adicionales en sus dependencias Por ejemplo, si el objetivo A depende de B, se puede aplicar un aspecto en A que desplace hacia arriba un borde 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 destinos que requieren el mismo aspecto. Se crea con la función aspect() de la API de Starlark Build. Se pueden usar, por ejemplo, a fin de generar metadatos para IDE y crear acciones de análisis con lint.
Consulta también: Documentación sobre aspectos
Aspecto en función
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 el uso de los IDEs se puede aplicar sobre un aspecto que genera archivos .java a partir de un proto.
Para que un A de aspecto se aplique sobre el aspecto B, los proveedores que B anuncia en su atributo provides deben coincidir con lo que A declara que quiere en su atributo required_aspect_providers.
Atributo
Un parámetro para una regla que se usa con el fin de 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 personalizados 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 se pueden configurar juntas en la línea de comandos de Bazel mediante una marca --config. Bazel puede combinar la configuración de varios archivos de bazelrc
(en todo el sistema, por lugar de trabajo, por usuario o desde una ubicación personalizada). Un archivo bazelrc también puede importar la configuración de otros archivos bazelrc.
Blaze
La versión interna de Google de Bazel. Es el principal sistema de compilación de Google para su monorepositorio.
Archivo BUILD
Un archivo BUILD es el archivo de configuración principal que le indica a Bazel qué resultados de 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 se deben completar 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 llamarse BUILD.bazel.
Archivo BUILD.bazel
Consulta Archivo BUILD. Tiene prioridad sobre un archivo BUILD en el mismo directorio.
Archivo .bzl
Un archivo que define reglas, macros y constantes escritas en Starlark. Luego, se pueden importar a archivos BUILD con la función load().
Gráfico de compilación
Gráfico de dependencias que Bazel construye y recorre para realizar una compilación Incluye nodos como destinos, destinos 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 compilación
Una pieza de configuración definida por Starlark. Las transiciones pueden establecer ajustes 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, es más lento que una compilación incremental, pero por lo general se considera 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 entre
los comandos, pero se detiene automáticamente después de un período de inactividad (o de forma 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 porque el gráfico de acción permanece en la memoria entre 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 y test, entre otras. Las marcas suelen usarse con fines de configuración, por lo que los cambios en los valores de las marcas pueden hacer que Bazel invalide los gráficos en memoria y reinicie la fase de análisis.
Configuración
Información fuera de las definiciones de las reglas que afecta la forma 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 configuración que un objetivo realmente necesita. Por ejemplo, si compilas el objeto binario de Java //:j con la dependencia //:c de C++, es una pérdida incluir el valor de --javacopt en la configuración de //:c, ya que cambiar --javacopt interrumpe 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
Es el resultado de evaluar un objetivo con una configuración. Para ello, la fase de análisis combina las opciones de compilación con los destinos que se deben compilar.
Por ejemplo, si //:foo compila para dos arquitecturas diferentes en la misma compilación, tiene dos destinos configurados: <//:foo, x86> y <//:foo, arm>.
Precisión
Una compilación es correcta cuando su resultado refleja fielmente el estado de sus entradas transitivas. Para lograr compilaciones correctas, Bazel se esfuerza por ser hermético, reproducible y que el análisis de compilación y la ejecución de la acción sean deterministas.
Dependencia
Un borde dirigido entre dos objetivos. Un //:foo de destino tiene una dependencia de destino del //:bar de destino si los valores del atributo de //:foo contienen una referencia a //:bar. //:foo tiene una dependencia de acción en //:bar si una acción en //:foo depende de un artefacto de entrada creado por una acción en //:bar.
En ciertos contextos, también podría hacer referencia a una dependencia externa. Consulta los 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 recurrente a otras dependencias por razones de eficiencia del espacio. Las implementaciones de Rule no deben "compactar" las dependencias convirtiéndolas en listas, a menos que la regla esté en el nivel superior del gráfico de compilación. La compactación de dependencias 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 de BLOB local en disco para la función de almacenamiento en caché remoto Se puede usar en junto 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 sin conexión por completo.
Ejecución dinámica
Es una estrategia de ejecución que selecciona entre la ejecución local y remota en función de 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 más limpios posibles.
Fase de ejecución
Es la tercera fase de una compilación. Ejecuta las acciones en el gráfico de acciones que se creó 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, de zona de pruebas, Docker, etcétera.
Raíz de ejecución
Un directorio en el directorio de la base de resultados 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 prepara 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. Es accesible 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 al azar.
Compilación incremental
En una compilación incremental, se reutilizan 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 de acceso 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
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 gráfico de destino.
Macro
Un mecanismo para componer varias declaraciones de destino de la regla en una sola función Starlark. Permite volver a usar patrones de declaración de reglas comunes en archivos BUILD. Se expande a las declaraciones de objetivo de la regla subyacente durante la fase de carga.
Consulta también: Documentación de Macro
Mnemónico
Es una string breve y legible por humanos seleccionada por un autor de la regla para comprender rápidamente qué 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 mnemónicos de acción 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 de otros módulos Esto es análogo a los conceptos conocidos en 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 carga. Los módulos forman la columna vertebral del sistema externo de administración de dependencias de Bazel.
Cada módulo está respaldado por un repositorio con un archivo MODULE.bazel en su raíz. Este archivo contiene metadatos sobre el módulo en sí (como su nombre y versión), sus dependencias directas y varios 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 una lógica que se puede ejecutar para generar repositorios mediante la lectura de entradas del gráfico de dependencia del módulo y la invocación de reglas del 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. Esas reglas aparecen en los archivos .bzl como funciones en el 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 del lugar de trabajo 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 ubica en la raíz del usuario de salida.
Grupos de salida
Es un grupo de archivos que se espera que se compilen 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 destinos 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 del usuario de salida
Un directorio específico del usuario para almacenar los resultados de Bazel. El nombre del directorio se deriva del nombre de usuario del sistema del usuario. Se evitan los conflictos de archivos de salida si varios usuarios compilan el mismo proyecto en el sistema al mismo tiempo. Contiene subdirectorios que corresponden a los resultados de compilación de los lugares de trabajo individuales, también conocidos como bases de salida.
Paquete
Es el conjunto de objetivos definidos por un archivo BUILD. El nombre de un paquete es la ruta del archivo BUILD relacionada con 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
Es un destino 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 máquinas se ejecutan en las plataformas (“plataformas de ejecución”) y las máquinas en las que se compilan (“plataformas de destino”).
Proveedor
Esquema que describe una unidad de información para pasar entre los objetivos de la regla junto con las relaciones de dependencia. Por lo general, contiene información como opciones de compilador, archivos transitivos de fuente o salida, y metadatos de compilación. Se usa con frecuencia 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 del proveedor
Consulta (concepto)
Es el proceso de analizar un gráfico de compilación para comprender las propiedades de destino y las estructuras de dependencias. Bazel admite tres variantes de consulta: query, cquery y aquery.
query (comando)
Una herramienta de consulta que opera en el gráfico de destino posterior a la fase de carga de la compilación. Esto es relativamente rápido,
pero no puede analizar los efectos de select(), marcas de compilación,
artefactos ni acciones de compilación.
Consulta también: Instructivo sobre consultas y Referencia de consultas
Repositorio
Un árbol de directorios con un archivo de marcador de límite en su raíz, que contiene archivos fuente que se pueden usar en una compilación de Bazel. A menudo, se abrevia como solo repo.
Un archivo de marcador de límite de 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 significará 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.
Los repositorios externos se definen a través de la especificación de módulos en archivos MODULE.bazel o de la invocación de reglas del repositorio en extensiones del módulo. Se pueden recuperar a pedido a una ubicación “mágica” predeterminada en el disco.
Cada repositorio tiene un nombre canónico único y constante, y nombres apparent potencialmente diferentes si se los visualiza desde otros repositorios.
Consulta también: Descripción general de las dependencias externas
Caché del repositorio
Una caché de contenido direccionable y compartida que descargó Bazel para las compilaciones y se puede compartir entre lugares de trabajo. Habilita las compilaciones sin conexión después de la descarga inicial. Por lo general, se usan para almacenar en caché archivos descargados a través de reglas de 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 definiciones de repositorio que le indica a Bazel cómo materializar (o “recuperar”) un repositorio. A menudo, se abrevia como solo regla del repositorio.
Bazel invoca las reglas del repositorio de forma interna 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 de Internet un archivo que contenga archivos fuente.
Consulta también: Documentación de las reglas del repositorio
Reproducibilidad
Es la propiedad de una compilación o prueba que determina que un conjunto de entradas a la compilación o la prueba siempre producirá el mismo conjunto de resultados cada vez, sin importar la hora, el método o el entorno. Ten en cuenta que esto no implica necesariamente que las salidas sean correctas o las deseadas.
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 una lógica de cuadro negro. La lógica le indica al objetivo de la regla cómo producir artefactos de salida y pasar información a otros objetivos de reglas. 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 crean instancias de las reglas para producir objetivos de reglas en la fase de carga. En la fase de análisis, los objetivos de reglas 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 de las reglas
Objetivo de la regla
Un destino que es una instancia de una regla. Contrasta los objetivos de archivo y 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 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 del directorio del código fuente.
Consulta también: Documentación de Runfiles
Zona de pruebas
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 resultados no declarados. Las zonas de pruebas mejoran 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 importante, pero en macOS puede hacer que la zona de pruebas sea inutilizable.
Skyframe
Skyframe es el framework principal de evaluación incremental, paralelo y funcional de Bazel.
Estampado
Una función para incorporar información adicional en
artefactos compilados en 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 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 la extensión para escribir reglas y macros. Un subconjunto restringido de Python (en términos sintácticas y gramaticales) orientado a la configuración y a un mejor rendimiento. Usa la extensión del archivo .bzl. Los archivos BUILD usan una versión aún más restringida de Starlark (como ninguna definición de función def), antes conocida como Skylark.
Consulta también: Documentación del lenguaje Starlark
Marcas de inicio
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 en
las marcas de inicio provoca un reinicio del servidor. Las marcas de inicio no son específicas de ningún comando.
Diana
Un objeto que se define en un archivo BUILD y se identifica con una etiqueta. Los destinos representan las unidades compilables 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 se pueden ejecutar (como cc_binary) o probar (como cc_test). Por lo general, los objetivos de las reglas dependen 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 destinos de archivos y 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 destino de archivo de origen en ese paquete.
Los destinos se descubren durante la fase de carga. Durante la fase de análisis, los objetivos se asocian con configuraciones de compilación para formar destinos configurados.
Gráfico objetivo
Un gráfico de destinos en la memoria y sus dependencias Producido durante la fase de carga y se usa como entrada a la fase de análisis.
Patrón de objetivo
Una forma de especificar un grupo de destinos en la línea de comandos. Los patrones que se usan con más frecuencia son :all (todos los objetivos de las reglas), :* (todas las reglas y los objetivos de 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
La regla objetivo se crea a partir de reglas de prueba y, por lo tanto, contiene un ejecutable de prueba. Un código de muestra de cero desde la finalización del archivo ejecutable indica que la prueba fue exitosa. El contrato exacto entre Bazel y las pruebas (como las variables de entorno de pruebas 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 compilar resultados para un idioma. 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 una cadena de herramientas del compilador Unix pueden variar para la variante de Windows, aunque la cadena de herramientas sea para el mismo lenguaje. La selección de 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 es de nivel superior, aunque se deberán compilar ambos destinos. Una diferencia importante
entre los destinos de nivel superior y los de nivel no superior es que las marcas de
comandos establecidas en la línea de comandos de Bazel (o a través de
.bazelrc) establecerán la configuración de los destinos de nivel superior, pero es posible que se modifique mediante una transición para los
destinos de nivel superior.
Transición
Una asignación del estado de configuración de un valor a otro. Permite que los destinos del gráfico de compilación tengan diferentes configuraciones, incluso si se crearon instancias de ellos desde 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, puedes 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 sobre ellos debe registrar el artefacto de árbol como su entrada o salida.
Visibilidad
Uno de los dos mecanismos que existen para evitar dependencias no deseadas en el sistema de compilación: la visibilidad del destino, que sirve para controlar si otros objetivos pueden depender de un destino, 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 la visibilidad
Espacio de trabajo
El entorno que comparten todos los comandos de Bazel se ejecuta desde el mismo repositorio principal.
Ten en cuenta que, históricamente, los conceptos de “repositorio” y “lugar de trabajo” se combinaron. A menudo, el término “lugar de trabajo” se usó para referirse al repositorio principal y, a veces, se usó como sinónimo de “repositorio”. Para mayor claridad, debe evitarse este uso.