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/salida declarados.
Consulte también: Documentación sobre las reglas
Caché de acción
Caché en el disco que almacena una asignación de las acciones ejecutadas a los resultados que crearon. La tecla de caché se conoce como la clave de acción. Un componente principal para el 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 actions y los artefactos que estas acciones leen y generan El grafo puede incluir artefactos que existen como archivos de origen (por ejemplo, en el sistema de archivos) y artefactos generados intermedios o finales que no se mencionan en archivos BUILD. Se produce durante la fase de análisis y se usa durante la fase de ejecución.
Consulta de gráfico de acción (consulta)
Una herramienta de consulta que puede consultar sobre las acciones de compilación Esto permite analizar cómo se traducen las reglas de compilación en las compilaciones de trabajo reales.
Tecla de acción
La clave de caché de una acción. Se calculan según 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 las bibliotecas o los encabezados del sistema, según la acción. Permite que Bazel almacene en caché o invalide acciones individuales de forma determinista.
Fase de análisis
La 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 a varias acciones, pero solo se debe generar como máximo en una acción.
Un artefacto que corresponde a un destino de archivo se puede abordar con 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 desvíe hacia un borde de dependencia a B y ejecute acciones adicionales en B para generar y recopilar archivos de salida adicionales. Estas acciones adicionales se almacenan en caché y se vuelven a usar entre destinos que requieren el mismo aspecto. Creado con la función aspect() de la API de compilación de Starlark. Puede usarse, por ejemplo, a fin de generar metadatos para IDE y crear acciones para el análisis con lint.
Consulta también: Documentación sobre los aspectos
Aspecto en perspectiva
Un mecanismo de composición en el que se pueden aplicar aspectos a los resultados de otros aspectos. Por ejemplo, un aspecto que genera información para el uso de IDE puede aplicarse sobre un aspecto que genera archivos .java a partir de un proto.
Para que un A de aspecto se aplique sobre 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 a fin de expresar la información de la compilación por orientación.
Los ejemplos incluyen srcs, deps y copts, que declaran respectivamente los archivos de origen, las dependencias y las opciones personalizadas del compilador de un destino. Los atributos
particulares disponibles para un destino determinado dependen de su tipo de regla.
bazelrc
El archivo de configuración de Bazel que se usa para cambiar los valores predeterminados de las marcas de inicio y las marcas de comandos, y definir grupos comunes de opciones que se pueden configurar en conjunto en la línea de comandos de Bazel mediante una marca --config. Bazel puede combinar la configuración de varios archivos bazelrc
(para 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 sistema de compilación principal de Google para su repositorio mono.
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 hacerlo. Bazel
toma un archivo BUILD como entrada y lo usa a fin de crear un grafo 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 un 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. Estos se pueden importar en archivos BUILD con la función load().
Gráfico de compilación
El grafo de dependencia 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 están verificados como actualizados.
Configuración de compilación
Una configuración definida por Starlark. Las transiciones pueden establecer la configuración 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 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
los comandos, pero se detiene automáticamente después de un período de inactividad (o de manera explícita a través del
cierre de bazel). La división de 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 acciones permanece en la memoria entre 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 del comando
Un conjunto de marcas específicas para 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 más. 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 grafos en la memoria y reinicie la fase de análisis.
Configuración
Información fuera de las definiciones de rule que afecta cómo 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 herramientas de host o compilación cruzada.
Consulta también: Configuraciones
Recorte de la configuración
Es el proceso que solo incluye las configuraciones que un objetivo necesita. Por ejemplo, si compilas el objeto binario //:j de Java con //:c como dependencia de C++, es desperdiciado incluir el valor de --javacopt en la configuración de //:c porque cambiar --javacopt anula innecesariamente la capacidad de almacenamiento en caché de la compilación de C++.
Consulta configurada (cquery)
Una herramienta de consulta que consulta objetivos 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 consulta
Destino configurado
El resultado de evaluar un objetivo con una configuración. En la fase de análisis, esto se produce cuando se combinan 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, 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ética y reproducible, y hacer que el análisis de la compilación y la ejecución de acciones sean deterministas.
Dependencia
Un borde dirigido entre dos objetivos. Un //:foo de destino tiene una dependencia de destino en el destino //:bar si los valores de los atributos 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.
Baja
Una estructura de datos para recopilar datos sobre dependencias transitivas. Se optimiza para que la fusión de dependencias sea eficiente en cuanto al tiempo y el espacio, ya que es común tener dependencias muy grandes (cientos de miles de archivos). Se implementa para hacer referencia de forma recurrente a otros bloqueos por razones de eficiencia del espacio. Las implementaciones de Rule no deben “aplanar” los depósitos. Para ello, deben convertirse en listas, a menos que la regla esté en el nivel superior del grafo de compilación. Si se compactan grandes dependencias, se consume mucho memoria. También conocido como conjuntos anidados en la implementación interna de Bazel.
Consulta también: Documentación de
Caché de disco
Un almacenamiento de BLOB local en el disco para la función de almacenamiento en caché remoto. Se puede usar junto con un almacén de BLOB remoto real.
Destildar
Un directorio de solo lectura que contiene archivos que, de lo contrario, Bazel recuperaría de Internet mediante reglas de repositorio. Permite que las compilaciones se ejecuten completamente sin conexión.
Ejecución dinámica
Una estrategia de ejecución que selecciona entre 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. Ciertas acciones se ejecutan más rápido de forma local (por ejemplo, vinculación) y otras son más rápidas de forma remota (por ejemplo, compilación altamente paralelizable). Una estrategia de ejecución dinámica puede proporcionar los mejores tiempos de compilación incrementales y limpios.
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 y secuencias de comandos) para leer y escribir artefactos. Las estrategias de propagació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 salida del lugar de trabajo donde las acciones locales se ejecutan en compilaciones que no son de zona de pruebas El contenido del directorio es, en su mayoría, symlinks de artefactos de entrada desde el 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 vínculos simbólicos de los directorios que representan el cierre transitivo de los paquetes de los que depende una compilación. 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 suelen no permitir el acceso de red a las acciones, restringir el acceso a entradas declaradas, usar marcas de tiempo y zonas horarias fijas, restringir el acceso a variables de entorno y usar valores iniciales 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. El objetivo de la verificación de dependencias y el almacenamiento en caché son 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. Una etiqueta completamente calificada, como //path/to/package:target, consta de // para marcar el directorio raíz del lugar de trabajo, path/to/package como el directorio que contiene el archivo BUILD que declara el destino y :target como el nombre del destino declarado en el archivo BUILD antes mencionado. También puede contener el prefijo @my_repository//<..> para indicar que el destino se declara en un repositorio externo llamado my_repository.
Cargando fase
La primera fase de una compilación en la que Bazel analiza los archivos WORKSPACE, BUILD y .bzl para crear paquetes Las macros y algunas funciones como glob() se evalúan en esta fase. Está intercalada con la segunda fase de la compilación, la fase de análisis, para crear un gráfico de destino.
Macro
Un mecanismo para redactar varias declaraciones de destino de regla en una sola función de Starlark. Habilita la reutilización de patrones de declaración de reglas comunes en archivos BUILD. Se expandió a las declaraciones de destino de la regla subyacente
durante la fase de carga.
Consulte también: Documentación de macros
Mnemotecnia
Una string corta y legible seleccionada por un autor de reglas, 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 la estrategia 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.
Reglas nativas
Reglas que se compilan en Bazel y se implementan en Java. Estas reglas aparecen en 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 mediante 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. Se ubican en la raíz del usuario de salida.
Grupos de salida
Un grupo de archivos que se espera que se compile cuando Bazel termina 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 el grupo de salida 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. 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 objetivos definidos por un archivo BUILD. El nombre de un paquete es la ruta de acceso del archivo BUILD en relación con la raíz del lugar de trabajo. Un paquete puede contener subpaquetes o subdirectorios que contienen archivos BUILD, por lo tanto, forma una jerarquía de paquetes.
Grupo de paquetes
Un objetivo que representa un conjunto de paquetes. A menudo, se usa en los valores del atributo visibility.
Plataforma
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áquina se ejecutan en las plataformas (“exec”) y los destinos de las máquinas se compilan (“plataformas de destino”).
Proveedor
Esquema que describe una unidad de información para pasar entre los objetivos de la regla a lo largo de las relaciones de dependencia. Por lo general, contiene información como las opciones de compilador, los archivos de origen o de salida transitivos, y los 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)
Proceso de analizar un grafo de compilación para comprender las propiedades del objetivo y las estructuras de dependencia. Bazel admite tres variantes de consulta: query, cquery y aquery.
consulta (comando)
Una herramienta de consulta que opera sobre 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: Instructivos sobre consultas, Referencias de consultas
Caché del repositorio
Una caché de archivos direccionable de contenido descargado por Bazel para compilaciones
que se puede compartir entre lugares de trabajo. Habilita las compilaciones sin conexión después de la
descarga inicial. Por lo general, se usa para almacenar en caché los archivos descargados a través de reglas de repositorio como http_archive y las API de reglas de repositorio como repository_ctx.download. Los archivos se almacenan en caché solo si sus sumas de verificación SHA-256 se especifican para la descarga.
Reproducibilidad
La propiedad de una compilación o prueba que un conjunto de entradas a la compilación o a la prueba siempre producirá el mismo conjunto de resultados cada vez, independientemente del tiempo, el método o el entorno. Ten en cuenta que esto no implica necesariamente que los resultados sean correctos o los deseados.
Regla
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 consiste en un conjunto de atributos y lógica de caja negra. 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 entornos y lenguajes de programación.
Se crean instancias de reglas a fin de producir objetivos de reglas en la fase de carga. En la fase de análisis, los objetivos comunican la información a sus dependencias descendentes en forma de proveedores y registran las acciones que describen cómo generar sus artefactos de salida. Estas acciones se ejecutan en la fase de ejecución.
Consulte también: Documentación sobre las reglas
Objetivo de la regla
Un objetivo que es una instancia de una regla. Contrastes con objetivos de archivo y grupos de paquetes No se debe confundir con la regla.
Archivos en 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 runrun son dependencias de datos de tiempo de ejecución de la prueba. Antes de la invocación del ejecutable (durante la prueba de Bazel), Bazel prepara el árbol de runfiles junto con el ejecutable de la prueba según su estructura de directorio de origen.
Consulta también: Documentación de runfiles
Zona de pruebas
Técnica para aislar una acción en ejecución dentro de una raíz de ejecución restringida y temporal, a fin de garantizar que no lea entradas no declaradas ni escriba salidas no declaradas. La zona de pruebas mejora en gran medida la hermeticidad, pero, por lo general, tiene un costo de rendimiento y requiere asistencia del 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 principal de evaluación incremental, funcional y paralelo de Bazel.
Estampado
Una función para incorporar información adicional en artefactos
basados en Bazel. Por ejemplo, esto se puede usar con el fin de controlar el código fuente, el tiempo de compilación y otros datos relacionados 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 estampilla.
Starlark
El lenguaje de extensión para escribir macros y reglas Un subconjunto restringido de Python (de manera sintáctica y gramatical) que se utilice a los fines de la configuración y para obtener un mejor rendimiento Usa la extensión de 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 de 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 hace que se reinicie el 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 destino 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 se pueden probar (como cc_test). Los objetivos de reglas suelen depender de otros destinos mediante sus atributos (como deps). Estas dependencias forman la base del gráfico de destino.
Además de los objetivos de reglas, también hay objetivos de archivo y de grupo de paquetes. Los objetivos 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 del 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 objetivos configurados.
Gráfico de destino
Un gráfico en la memoria con objetivos y sus dependencias Se produce durante la fase de carga y se usa como entrada en la fase de análisis.
Patrón de objetivo
Una forma de especificar un grupo de objetivos en la línea de comandos. Los patrones que se usan con frecuencia son :all (todos los destinos de reglas), :* (todos los destinos de reglas y archivos), ... (el paquete actual y todos los subpaquetes de forma recurrente). Se puede usar en combinación; por ejemplo, //...:* significa que todos los destinos de reglas y archivos en todos los paquetes son recurrentes desde la raíz del lugar de trabajo.
Pruebas
La regla targets se crea a partir de reglas de prueba y, por lo tanto, contiene un ejecutable de prueba. Un código de retorno de cero desde la finalización del ejecutable indica que la prueba se realizó de forma correcta. El contrato exacto entre Bazel y las pruebas (como las variables del entorno de prueba y los métodos de recopilación de resultados de la prueba) se especifica en la Enciclopedia de pruebas.
Cadena de herramientas
Un conjunto de herramientas para crear resultados para un lenguaje. Por lo general, una cadena de herramientas incluye compiladores, vinculadores, intérpretes o lintes. 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 diferir para la variante de Windows, incluso si es para el mismo lenguaje. Seleccionar la cadena de herramientas adecuada para la plataforma se conoce como resolución de la cadena de herramientas.
Objetivo de nivel superior
Un objetivo de compilación es el 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 objetivos de nivel superior y los que no son de nivel superior es que las marcas de
comando establecidas en la línea de comandos de Bazel (o mediante
.bazelrc) establecerán la configuración para los objetivos de nivel superior, pero pueden modificarse con una transición para los objetivos de
nivel superior.
Transición
Una asignación del estado de la configuración de un valor a otro Permite que los objetivos del 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 mediante 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, una acción que opera en ellos debe registrar el artefacto de árbol como entrada o salida.
Visibilidad
Uno de los dos mecanismos para evitar dependencias no deseadas en el sistema de compilación es visibilidad de objetivos, a fin de controlar si otros destinos pueden depender de un objetivo y cargar visibilidad 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 de destino.
Consulta también: Documentación sobre la visibilidad
Lugar de trabajo
Un directorio que contiene un archivo WORKSPACE y un código fuente para el software que deseas compilar. Las etiquetas que comienzan con // se relacionan con el directorio del lugar de trabajo.
Archivo WORKSPACE
Define que un directorio sea un lugar de trabajo. El archivo puede estar vacío, aunque suele contener declaraciones de repositorio externo para recuperar dependencias adicionales de la red o del sistema de archivos local.