Acción
Es un comando que se ejecuta 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 o salida declarados.
Consulta también: Documentación de las reglas
Caché de acciones
Es 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. Es 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
Es un gráfico en memoria de las acciones y los artefactos que estas acciones leen y generan. El gráfico puede incluir artefactos que existen como archivos fuente (por ejemplo, en el sistema de archivos), así como artefactos intermedios o 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 del gráfico de acciones (aquery)
Es una herramienta de consultas que puede consultar acciones de compilación. Esto permite analizar cómo las reglas de compilación se traducen en el trabajo real que realizan las compilaciones.
Tecla de acción
Es 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 forma determinística.
Fase de análisis
Es la segunda fase de una compilación. Procesa el gráfico de destino especificado en los archivos BUILD para generar un gráfico de acción 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.
Artefacto
Un archivo fuente 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 con una acción como máximo.
Se puede hacer referencia a un artefacto que corresponde a un destino de archivo con una etiqueta.
Aspecto
Es 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 recorre hacia arriba un borde de dependencia hacia B y ejecuta 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 creó con la función de la API de compilación de Starlark aspect(). Se puede usar, por ejemplo, para generar metadatos para IDE y crear acciones para el análisis de código.
Consulta también: Documentación de Aspects
Aspecto sobre aspecto
Es un mecanismo de composición por el cual se pueden aplicar aspectos a los resultados de otros aspectos. Por ejemplo, un aspecto que genera información para que la usen los IDE se puede aplicar sobre un aspecto que genera archivos .java a partir de un archivo .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
Es un parámetro de 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 fuente, las dependencias y las opciones de compilador personalizadas de un destino. Los atributos específicos disponibles para un objetivo determinado dependen de su tipo de regla.
.bazelrc
Archivo de configuración de Bazel que 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 establecer juntas en la línea de comandos de Bazel con una marca --config. Bazel puede combinar la configuración de varios archivos bazelrc (a nivel del 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. Es el sistema de compilación principal 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 compilar, cuáles son sus dependencias y cómo compilarlos. 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 un paquete, y puede contener objetivos creados por reglas. El archivo también se puede llamar 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, se pueden importar a archivos BUILD con la función load().
Compilar gráfico
Es el gráfico de dependencias que Bazel construye y recorre para realizar una compilación. Incluye nodos como targets, configured targets, actions y artifacts. Se considera que una compilación se completó cuando se verifican todos los artefactos de los que depende un conjunto de destinos solicitados como actualizados.
Configuración de compilación
Es una parte de la configuración definida por Starlark. Las transiciones pueden establecer parámetros de 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
Es una compilación que no usa los resultados de compilaciones anteriores. Por lo general, es más lenta que una compilación incremental, pero se considera más correcta. Bazel garantiza que las compilaciones limpias e incrementales sean siempre correctas.
Modelo cliente-servidor
El cliente de línea de comandos bazel inicia automáticamente un servidor en segundo plano en la máquina local para ejecutar 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 a través de bazel shutdown). Dividir Bazel en un servidor y un cliente ayuda a amortizar el tiempo de inicio de la JVM y admite compilaciones incrementales más rápidas, ya que 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 de comandos
Es 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 pueden aplicarse 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 muchos más. 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 memoria y reinicie la fase de análisis.
Configuración
Es la información fuera de las definiciones de 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
Reducción de la configuración
Proceso que consiste en incluir solo las partes de la configuración que un destino realmente necesita. Por ejemplo, si compilas el archivo binario de Java //:j con la dependencia de C++ //:c, es un desperdicio 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 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 cquery
Objetivo configurado
Es el resultado de evaluar un objetivo con una configuración. La fase de análisis produce esto 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, 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 por hacer que el análisis de compilación y la ejecución de acciones sean determinísticos.
Dependencia
Es un borde dirigido entre dos destinos. Un //:foo objetivo tiene una dependencia de objetivo en el objetivo //:bar si los valores de 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.
Depset
Es una estructura de datos para recopilar datos sobre las dependencias transitivas. Está optimizada para que la combinación de depsets sea eficiente en términos de tiempo y espacio, ya que es común tener depsets muy grandes (cientos de miles de archivos). Se implementó para hacer referencia de forma recursiva a otros depsets por motivos de eficiencia de espacio. Las implementaciones de reglas no deben "aplanar" los depsets convirtiéndolos en listas, a menos que la regla se encuentre en el nivel superior del gráfico de compilación. Aplanar los depsets grandes genera un consumo de memoria enorme. También se conocen como conjuntos anidados en la implementación interna de Bazel.
Consulta también: Documentación de Depset
Caché de disco
Es un almacén 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.
Distdir
Es un directorio de solo lectura que contiene archivos que Bazel, de lo contrario, recuperaría de Internet con reglas de repositorio. Permite que las compilaciones se ejecuten completamente sin conexión.
Ejecución dinámica
Es una estrategia de ejecución que selecciona entre la ejecución local y la 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, 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
Es la tercera fase de una compilación. Ejecuta las acciones en el gráfico de acción 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, en Docker, etcétera.
Raíz de ejecución
Es un directorio en el directorio base de salida del espacio de trabajo en el que se ejecutan las acciones locales en compilaciones que no son aisladas. El contenido del directorio son principalmente vínculos simbólicos de los artefactos de entrada del espacio de trabajo. La raíz de ejecución también contiene vínculos simbólicos a repositorios externos como otras entradas y el directorio bazel-out para almacenar las salidas. Se prepara durante la fase de carga creando 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. 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 determinísticos y correctos. Por ejemplo, las compilaciones herméticas suelen prohibir el acceso a la red para las acciones, restringir el acceso a las entradas declaradas, usar marcas de tiempo y zonas horarias fijas, restringir el acceso a las variables de entorno y usar semillas fijas para los 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 y el almacenamiento en caché de dependencias 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
Es un identificador de un destino. Una etiqueta completamente calificada, como //path/to/package:target, consta de // para marcar el directorio raíz del espacio 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 mencionado anteriormente. También puede tener el prefijo @my_repository//<..> para indicar que el destino se declara en un repositorio externo llamado my_repository.
Fase de carga
Es la primera fase de una compilación en la que Bazel analiza los archivos WORKSPACE, BUILD y .bzl para crear paquetes. En esta fase, se evalúan las macros y ciertas funciones, como glob(). Se intercala con la segunda fase de la compilación, la fase de análisis, para crear un gráfico de destino.
Macro
Es un mecanismo para componer varias declaraciones de destino de regla en una sola función de Starlark. Permite reutilizar patrones comunes de declaración de reglas en archivos BUILD. Se expande a las declaraciones de destino de la regla subyacente durante la fase de carga.
Consulta también: Documentación de macros
Mnemónico
Es una cadena breve y legible seleccionada por el autor de una regla para comprender rápidamente lo que hace una acción en la regla. Las mnemónicas se pueden usar como identificadores para las selecciones de estrategia de generación. Algunos ejemplos de mnemónicos de acción son Javac de las reglas de Java, CppCompile de las reglas de C++ y AndroidManifestMerger de las reglas de Android.
Reglas de anuncios nativos
Reglas integradas en Bazel y que se implementan en Java. Estas 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
Es un directorio específico del espacio de trabajo para almacenar los archivos de salida de Bazel. Se usa para separar las salidas del árbol de origen del espacio de trabajo. Se encuentra 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 resultados predeterminado" (p. ej., el archivo .jar de un java_library, .a y .so para los destinos 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 resultados 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).
Genera el usuario raíz
Es 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 colisiones de archivos de salida si varios usuarios compilan el mismo proyecto en el sistema al mismo tiempo. Contiene subdirectorios correspondientes a los resultados de compilación de espacios de trabajo individuales, también conocidos como bases de salida.
Paquete
Es el conjunto de destinos 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 espacio de trabajo. Un paquete puede contener subpaquetes o subdirectorios que contengan archivos BUILD, lo que forma una jerarquía de paquetes.
Grupo de paquetes
Un destino que representa un conjunto de paquetes. Se suele usar en los valores del atributo visibility.
Plataforma
Es un "tipo de máquina" que participa en una compilación. Esto incluye la máquina en la que se ejecuta Bazel (la plataforma "host"), las máquinas en las que se ejecutan las herramientas de compilación (las plataformas "ejec") y las máquinas para las que se compilan los destinos (las "plataformas de destino").
Proveedor
Es un esquema que describe una unidad de información para pasar entre destinos de reglas a lo largo de las relaciones de dependencia. Por lo general, contiene información como opciones del compilador, archivos de origen o salida transitivos y metadatos de compilación. Se usa con frecuencia junto con depsets para almacenar de manera eficiente los datos transitivos acumulados. Un ejemplo de proveedor integrado es DefaultInfo.
Consulta también: Documentación del proveedor
Consulta (concepto)
Proceso de análisis de un gráfico de compilación para comprender las propiedades del destino y las estructuras de dependencia. Bazel admite tres variantes de consultas: query, cquery y aquery.
consulta (comando)
Una herramienta de consulta que opera sobre el grafo de destino de la fase posterior a la carga de la compilación. Es relativamente rápido, pero no puede analizar los efectos de select(), las marcas de compilación, los artefactos ni las acciones de compilación.
Consulta también: Instructivo sobre consultas, Referencia de consultas
Caché del repositorio
Es una caché de contenido direccionable compartida de los archivos que Bazel descarga para las compilaciones y que se puede compartir entre espacios de trabajo. Habilita las compilaciones sin conexión después de la descarga inicial. Se usa comúnmente para almacenar en caché los archivos descargados a través de reglas de repositorio, como http_archive, y APIs de reglas de repositorio, como repository_ctx.download. Los archivos solo se almacenan en caché si se especifican sus sumas de comprobación SHA-256 para la descarga.
Reproducibilidad
Propiedad de una compilación o prueba que indica que un conjunto de entradas para la compilación o prueba siempre producirá el mismo conjunto de salidas 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 reglas 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 reglas. Desde la perspectiva de los autores de .bzl, las reglas son la forma principal de extender Bazel para admitir nuevos lenguajes y entornos de programación.
Las reglas se instancian para producir destinos de reglas en la fase de carga. En la regla de la fase de análisis, los destinos comunican información a sus dependencias posteriores 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 con los destinos de archivos y los grupos de paquetes. No debe confundirse con regla.
Archivos de ejecución
Son las dependencias de tiempo de ejecución de un destino ejecutable. Por lo general, el ejecutable es el resultado ejecutable de una regla de prueba, y los runfiles 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 archivos ejecutables junto con el ejecutable de prueba según la estructura del directorio fuente.
Consulta también la 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, lo que ayuda a garantizar que no lea entradas no declaradas ni escriba salidas no declaradas. El aislamiento mejora en gran medida la hermeticidad, pero suele tener un costo de rendimiento y requiere la compatibilidad del sistema operativo. El costo de rendimiento depende de la plataforma. En Linux, no es significativo, pero en macOS puede hacer que el aislamiento no se pueda usar.
Skyframe
Skyframe es el framework de evaluación central, paralelo, funcional y gradual de Bazel.
Estampado
Es una función para incorporar información adicional en los artefactos compilados con Bazel. Por ejemplo, se puede usar para el control de código fuente, el tiempo de compilación y otra información relacionada con el espacio de trabajo o el entorno para las compilaciones de versiones.
Habilita la marca --workspace_status_command y las reglas que admiten el atributo de sello.
Starlark
Es el lenguaje de extensión para escribir reglas y macros. Es un subconjunto restringido de Python (sintáctica y gramaticalmente) que tiene como objetivo la configuración y un mejor rendimiento. Usa la extensión de archivo .bzl. Los archivos BUILD usan una versión aún más restringida de Starlark (por ejemplo, no hay definiciones de funciones def), que antes se conocía como Skylark.
Consulta también la documentación del lenguaje Starlark.
Marcas de inicio
El conjunto de marcas especificadas entre bazel y el comando, por ejemplo, bazel --host_jvm_debug build. Estos parámetros modifican la configuración del servidor de Bazel, por lo que cualquier modificación en los parámetros de inicio provoca un reinicio del servidor. Las marcas de inicio no son específicas de ningún comando.
Objetivo
Objeto definido en un archivo BUILD y que se identifica con una etiqueta. Los destinos representan las unidades compilables de un espacio de trabajo desde la perspectiva del usuario final.
Un destino que se declara con la creación de una instancia de una regla se denomina destino de regla. Según la regla, estos pueden ser ejecutables (como cc_binary) o verificables (como cc_test). Los destinos de las reglas suelen depender de otros destinos a través de sus atributos (como deps); estas dependencias forman la base del gráfico de destinos.
Además de los destinos de reglas, también hay destinos de archivos y destinos de grupos de paquetes. Los destinos de archivos corresponden a artefactos a los que se hace referencia dentro de un archivo BUILD. Como caso especial, el archivo BUILD de cualquier paquete siempre se considera un destino de archivo fuente en ese paquete.
Los destinos se descubren durante la fase de carga. Durante la fase de análisis, los destinos se asocian con configuraciones de compilación para formar destinos configurados.
Gráfico de destino
Es un gráfico en memoria de los destinos y sus dependencias. Se produce durante la fase de carga y se usa como entrada para la fase de análisis.
Patrón de destino
Es una forma de especificar un grupo de destinos en la línea de comandos. Los patrones que se usan con frecuencia son :all (todos los destinos de la regla), :* (todos los destinos de la regla y del archivo) y ... (el paquete actual y todos los subpaquetes de forma recursiva). Se puede usar en combinación. Por ejemplo, //...:* significa todos los destinos de reglas y archivos en todos los paquetes de forma recursiva desde la raíz del espacio de trabajo.
Pruebas
El destino de la regla se instancia a partir de reglas de prueba y, por lo tanto, contiene un ejecutable de prueba. Un código de retorno cero de la finalización del ejecutable indica que la prueba se realizó 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
Es un conjunto de herramientas para generar resultados en un idioma. Por lo general, una cadena de herramientas incluye compiladores, enlazadores, intérpretes o verificadores de código, o todos ellos. Una cadena de herramientas también puede variar según la plataforma, es decir, los componentes de una cadena de herramientas de compilador de Unix pueden diferir para la variante de Windows, aunque la cadena de herramientas sea 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 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, entonces, para esta compilación, //:foo es de nivel superior y //:bar no lo es, aunque ambos destinos deberán compilarse. Una diferencia importante entre los destinos de nivel superior y los que no lo son es que las marcas de comando establecidas en la línea de comandos de Bazel (o a través de .bazelrc) establecerán la configuración para los destinos de nivel superior, pero una transición podría modificarlos para los destinos que no son de nivel superior.
Transición
Es una asignación del estado de configuración de un valor a otro. Permite que los destinos en el gráfico de compilación tengan diferentes configuraciones, incluso si se crearon a partir de la misma regla. Un uso común de las transiciones es con las transiciones de división, en las que se bifurcan ciertas partes del gráfico de destino con configuraciones distintas para cada bifurcación. Por ejemplo, se puede compilar un APK de Android con archivos 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
Es uno de los dos mecanismos para evitar dependencias no deseadas en el sistema de compilación: la visibilidad del destino para controlar si otros destinos pueden depender de un destino y la visibilidad de carga para controlar si un archivo BUILD o .bzl puede cargar un archivo .bzl determinado. Sin contexto, por lo general, "visibilidad" hace referencia a la visibilidad del objetivo.
Consulta también la documentación sobre la visibilidad.
Workspace
Un directorio que contiene un archivo WORKSPACE y el código fuente del software que deseas compilar Las etiquetas que comienzan con // son relativas al directorio del espacio de trabajo.
Archivo WORKSPACE
Define un directorio como un espacio de trabajo. El archivo puede estar vacío, aunque suele contener declaraciones de repositorios externos para recuperar dependencias adicionales de la red o el sistema de archivos local.