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 y el entorno variables de entrada y artefactos de entrada y salida declarados.
Consulta también: Documentación sobre las reglas
Caché de acciones
Una caché en el disco que almacena una asignación de las acciones ejecutadas al los resultados que crearon. La clave de caché se conoce como clave de acción. R Es el componente principal del modelo de incrementalidad de Bazel. La caché se almacena y, por lo tanto, sobrevive a los reinicios del servidor de Bazel.
Gráfico de acción
Un gráfico en la memoria de acciones y los artefactos que
se leen y generan estas acciones. El grafo podría incluir artefactos que existen como
archivos de origen (por ejemplo, en el sistema de archivos) y los archivos
artefactos intermedios o finales que no se mencionan en los archivos BUILD Producida
durante la fase de análisis y se usarán durante la ejecución
por fases.
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 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 calcula en función de los metadatos de la acción, que podría incluir el comando que se ejecutará en la acción, los indicadores del compilador, la biblioteca ubicaciones o encabezados del sistema, según la acción. Permite que Bazel almacene en caché o invalidar 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 una acción en la memoria
gráfico que determina el orden de las acciones que se ejecutarán durante
fase de ejecución. Esta es la fase en la que la regla
implementaciones de AA.
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 lo debe generar como máximo, una acción.
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 objetivo A depende de B, se puede aplicar un aspecto en
A que desvía hacia arriba una arista de dependencia hasta B y ejecuta acciones adicionales en B
para generar y recopilar archivos de salida adicionales. Estas acciones adicionales son
almacenar en caché y reutilizarse entre destinos que requieran el mismo aspecto. Se crea con el
aspect() función de la API de Starlark Build. Pueden usarse, por ejemplo, para generar
metadatos para IDE y crea 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 se pueden aplicar aspectos a los resultados
de otros aspectos. Por ejemplo, un aspecto que genera información para que la usen
Los IDEs se pueden aplicar sobre un aspecto que genere archivos .java a partir de un
proto.
Para que un aspecto A se aplique sobre el aspecto B, los proveedores que
B publica anuncios en su atributo provides.
debe coincidir con lo que A declara que desea en su 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 un
archivos de origen del destino, dependencias y opciones de compiladores personalizados. El cliente potencial
disponibles para un destino determinado dependen de su tipo de regla.
.bazelrc
Archivo de configuración de Bazel usado para cambiar los valores predeterminados del inicio
marcas y las marcas de comando, y definir reglas
grupos de opciones que luego se pueden configurar juntas en la línea de comandos de Bazel usando
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) y una
Es posible que el archivo bazelrc también importe 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 mono.
Archivo BUILD
Un archivo BUILD es el archivo de configuración principal que le indica a Bazel qué software
salidas a 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 llevarse a cabo para crear objetivos intermedios y finales
las salidas de software. Un archivo BUILD marca un directorio y cualquier subdirectorio
con un archivo BUILD como package y puede contener
destinos creados por reglas. También se puede asignar un nombre al archivo
BUILD.bazel
Archivo BUILD.bazel
Consulta Archivo BUILD. Tiene prioridad sobre un archivo BUILD del mismo
.
Archivo .bzl
Archivo que define reglas, macros y constantes escritas en
Starlark. Luego, se pueden importar a BUILD.
archivos 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, configurados destinos, acciones y artefactos. R compilación se considera completa cuando todos los artefactos en los que un conjunto de los 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 configuración. Si se expone al usuario como una marca de línea de comandos, también conocido como indicador 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 comúnmente se considera más correcta. Bazel garantiza compilaciones limpias e incrementales. siempre son correctas.
Modelo cliente-servidor
El cliente de línea de comandos bazel inicia automáticamente un servidor en segundo plano en la
para ejecutar comandos de Bazel. El servidor persiste en
comandos, pero se detiene automáticamente tras un período de inactividad (o de manera explícita mediante
apagado de Bazel). Dividir Bazel en un servidor y un cliente ayuda a amortizar JVM
tiempo de inicio y admite compilaciones incrementales más rápidas
ya que el gráfico de acción 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. Se especifican las marcas de comando
después del comando (bazel build <command flags>). Las marcas pueden aplicarse
uno o más comandos. Por ejemplo, --configure es una marca exclusivamente para el
El comando bazel sync, pero --keep_going es aplicable a sync, build,
test y más. Las marcas se usan a menudo para la configuración
por lo que los cambios en los valores de las marcas pueden hacer que Bazel invalide en la memoria
gráficos y reiniciar la fase de análisis.
Configuración
Información fuera de las definiciones de regla que afecta la forma en que estas generan acciones. Cada compilación tiene al menos una configuración que especifica la la plataforma de destino, las variables de entorno de acción y la compilación marcas. Las transiciones pueden crear más del servidor, como herramientas de host o compilación cruzada.
Consulta también: Configuraciones
Recorte de configuración
Es el proceso de incluir solo las partes de la configuración de un
que el objetivo realmente necesita. Por ejemplo, si compilas el objeto binario //:j de Java con C++
dependencia //:c, es un desperdicio incluir el valor de --javacopt en el
la configuración de //:c porque cambiar --javacopt rompe innecesariamente C++.
crea capacidad de almacenamiento
en caché de compilación.
Consulta configurada (cquery)
Una herramienta de consulta que consulta datos sobre configuración
objetivos (después de la fase de análisis
finaliza). Esto significa select() y 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. La fase de análisis produce
esto combinando las opciones de compilación con los objetivos que se deben compilar.
Por ejemplo, si //:foo compila para dos arquitecturas diferentes en la misma
tiene dos destinos configurados: <//:foo, x86> y <//:foo, arm>.
Precisión
Una compilación es correcta cuando su resultado refleja fielmente el estado de su las entradas transitivas. Para lograr compilaciones correctas, Bazel se esfuerza por herméticos, reproducibles y que generan análisis y ejecución de acciones son deterministas.
Dependencia
Un perímetro dirigido entre dos objetivos Un //:foo de destino tiene un objetivo
dependencia en el //:bar de destino si los valores del atributo de //:foo contienen un
referencia a //:bar. //:foo tiene una dependencia de acciones en //:bar si un
acción en //:foo depende de un artefacto de entrada creado por un
acción en //:bar.
En algunos contextos, también podría referirse a una dependencia externa. ver módulos.
Depset
Es una estructura de datos para recopilar datos sobre dependencias transitivas. Optimizado para que la combinación de dependencias es eficiente en el tiempo y el espacio, porque es común tener dependencias muy grandes (cientos de miles de archivos). Se implementa en se refieren de manera recursiva a otros depósitos por razones de eficiencia del espacio. Regla implementaciones no deben “compactarse” de clientes convirtiéndolos en listas, a menos 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 base de datos interna de Bazel. para implementarlos.
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 utilizar en en conjunción con un almacén remoto real de BLOB.
Distdir
Un directorio de solo lectura que contiene archivos que Bazel recuperaría de otro modo del en Internet con reglas de repositorio. Permite que las compilaciones se ejecuten por completo sin conexión.
Ejecución dinámica
Una estrategia de ejecución que selecciona entre la ejecución local y remota según diferentes heurísticas y usa los resultados de ejecución de la aplicación . Algunas acciones se ejecutan más rápido de forma local (por ejemplo, vínculos) y otras son más rápidas de forma remota (por ejemplo, altamente paralelizables compilación). Una estrategia de ejecución dinámica puede brindar la mejor tiempos de compilación incrementales y limpios.
Fase de ejecución
La tercera fase de una compilación. Ejecuta las acciones en la acción gráfico 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 la forma en que estas acciones se ejecutan de forma local, remota, dinámica, en zona de pruebas, Docker, etcétera.
Raíz de ejecución
Un directorio en la base de salida del lugar de trabajo
en el que las acciones locales se ejecutan en
compilaciones sin zona de pruebas. El contenido del directorio es mayormente 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 bazel-out
para almacenar resultados. Se prepara durante la fase de carga.
con la creación de un bosque de symlink de los directorios que representan el
cierre de paquetes de los que depende una compilación. Se puede acceder con bazel info
execution_root en la línea de comandos.
Archivo
Consulta Artifact.
Hermeticity
Una compilación es hermética si no hay influencias externas en su compilación y prueba. lo que ayuda a garantizar que los resultados sean deterministas y correcto. Por ejemplo, las compilaciones herméticas generalmente no permiten el uso acceso a acciones, restringe el acceso a entradas declaradas, usa marcas de tiempo fijas y zonas horarias, restringir el acceso a variables de entorno y usar 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 los recursos. La verificación de dependencias y el almacenamiento en caché tienen como objetivo producir para este tipo de compilación. Una compilación incremental es lo contrario a una compilación limpia compilar.
Etiqueta
Un identificador para un objetivo. Suele tener la forma
@repo//path/to/package:target, en el que repo es el nombre (aparente) de la
repositorio que contiene el destino, path/to/package es la ruta de acceso.
al directorio que contiene el archivo BUILD que declara el
target (este directorio también se conoce como el paquete) y target
es el nombre del objetivo en sí. Según la situación, algunas partes
pero la sintaxis se puede omitir.
Consulta también: Etiquetas
Fase de carga
La primera fase de una compilación, en la que Bazel ejecuta archivos BUILD para
crear paquetes. Macros y ciertas funciones, como
glob() se evalúan en esta fase. Intercalado con la segunda fase del
compilar, la fase de análisis, para crear un objetivo
gráfico.
Macro
Un mecanismo para componer varias declaraciones de destino rule juntas en
una sola función Starlark. Permite volver a usar la declaración de reglas comunes
patrones en los archivos BUILD. Se expandió al destino de la regla subyacente
declaraciones de estado durante la fase de carga.
Consulta también: Documentación de macros
Mnemónico
Una cadena corta y legible por humanos, seleccionada por el autor de la regla, para comprenderla rápidamente
lo que hace una acción en la regla. Los mnemónicos se pueden usar como
identificadores para las selecciones de estrategia de generación. Algunos ejemplos de mnemotecnias de acción
son Javac de reglas de Java, CppCompile de reglas de C++ y
AndroidManifestMerger de las 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 similar a los conceptos familiares en otras de administración de dependencias, como un artefacto de Maven, un paquete de npm, un Ve a module o a un cajón de carga. Los módulos forman la columna vertebral de la infraestructura de administración de dependencias.
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
version), sus dependencias directas y muchos otros datos, incluida la cadena de herramientas
registros y la entrada de extensión de 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
Un fragmento de lógica que se puede ejecutar para generar repositorios mediante la lectura entradas de todo el gráfico de dependencia module y de invocación del repositorio de usuario. Las extensiones de módulo tienen funciones similares a las de repo. de firewall, lo que les permite acceder a Internet, realizar operaciones de 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
aparecerán en archivos .bzl como funciones en el módulo nativo (para
por ejemplo, native.cc_library o native.java_library). Reglas definidas por el usuario
(no nativos) se crean con Starlark.
Base de salida
Un directorio específico de workspace para almacenar archivos de salida de Bazel. Usado para separar los resultados del árbol de fuentes del espacio de trabajo (el espacio de trabajo principal) repo). 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
objetivo. 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 cc_library
objetivos). El grupo de salida predeterminado es aquel cuyo
Los 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 pueden especificarse explícitamente en
Archivos BUILD (regla filegroup) o 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 es derivadas 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 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 definido por un archivo BUILD. R
el nombre del paquete es la ruta del archivo BUILD en relación con el repositorio
raíz. Un paquete puede contener subpaquetes o subdirectorios que contengan BUILD
archivos, lo que forma una jerarquía de paquetes.
Grupo de paquetes
Un objetivo que representa un conjunto de paquetes Se usa con frecuencia en visibility
valores de atributos.
Plataforma
Un “tipo de máquina” involucradas en una compilación. Esto incluye la máquina en la que se ejecuta Bazel (la plataforma “anfitrión”), las herramientas de compilación de las máquinas se ejecutan en las plataformas “ejecutivas” (exec), y las máquinas para los que se crean los objetivos (“plataformas de destino”).
Proveedor
Un esquema que describe una unidad de información para pasar
destinos de la regla junto con las relaciones de dependencia. Normalmente, esto
contiene información como opciones del compilador, archivos de origen o de salida transitivos,
y compilar metadatos. Se usa con frecuencia junto con depsets para
para almacenar con eficiencia
los datos transitivos acumulados. Ejemplo de un proveedor integrado
es DefaultInfo.
Consulta también: Documentación para proveedores
Consulta (concepto)
El proceso de analizar un gráfico de compilación para comprender propiedades objetivo y estructuras de dependencias. Bazel admite tres variantes de consulta: query, cquery y aquery.
query (comando)
Una herramienta de consulta que opera durante la carga posterior a la carga de la compilación
fase gráfico de destino. Es relativamente rápido,
pero no puede analizar los efectos de select(), las marcas de compilación
artefactos o 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 contenga el código fuente 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.
WORKSPACE.bazel Cualquier archivo de marcador de límite del repositorio indicará el límite de un
repo; pueden coexistir en un directorio.
El repositorio principal es el repositorio en el que se ejecuta el comando actual de Bazel.
Los repositorios externos se definen especificando módulos en MODULE.bazel
o invocar reglas de repositorio en el módulo
extensiones. Se pueden recuperar a pedido a una red
"mágico" ubicación en el disco.
Cada repositorio tiene un nombre canónico único y constante que puede ser diferente apparent cuando se ven desde otros repositorios.
Consulta también: Descripción general de las dependencias externas
Caché del repositorio
Una caché de contenido compartido direccionable de archivos que descarga Bazel para compilaciones
que se puede compartir en los espacios de trabajo. Habilita compilaciones sin conexión después de
descarga inicial. De uso general para almacenar en caché archivos descargados a través de repositorios
reglas como http_archive y APIs de reglas de repositorio, como
repository_ctx.download Los archivos se almacenan en caché solo si sus sumas de verificación SHA-256 son
especificadas para la descarga.
Regla del repositorio
Un esquema para definiciones de repositorios que le indica a Bazel cómo materializar (o
"fetch") un repositorio. A menudo se abrevia como regla del repositorio.
Bazel invoca internamente las reglas de repo para definir repositorios respaldados por
módulos o que se puedan invocar a través de extensiones de módulos.
Las reglas de Repo pueden acceder a Internet o realizar E/S de archivos. el repositorio más común
regla es http_archive para descargar un archivo con archivos fuente de la
a Internet.
Consulta también: Documentación de reglas de repositorio
Reproducibilidad
Propiedad de una compilación o prueba que mostrará un conjunto de entradas producen siempre el mismo conjunto de resultados cada vez, sin importar el tiempo, el método o entorno. Esto no implica necesariamente que las salidas correct o para obtener los resultados 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 lo siguiente:
un conjunto de atributos y lógica de caja negra. La lógica le indica
de destino cómo producir artefactos de salida y pasar información a
otros objetivos de la regla. Desde la perspectiva de los autores de .bzl, las reglas son
forma principal de extender Bazel para admitir nuevos lenguajes de programación y
entornos de prueba.
Se crean instancias de las reglas para generar objetivos de reglas en la fase de carga. En la regla de la fase de análisis los objetivos comunican información a sus dependencias descendentes en forma de proveedores de servicios en la nube y registrar acciones que describan cómo generan sus artefactos de salida. Estas acciones se ejecutan en la fase de ejecución fase de análisis.
Consulta también: Documentación sobre las reglas
Objetivo de la regla
Un objetivo que es una instancia de una regla. Contrasta con 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 runfiles son el entorno de ejecución las dependencias de datos de la prueba. Antes de invocar el archivo ejecutable (durante bazel), Bazel prepara el árbol de los archivos de ejecución junto con el ejecutable de prueba. según su estructura de directorio del código fuente.
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 temporal, lo que ayuda a garantizar que leer entradas no declaradas o escribir salidas no declaradas La zona de pruebas mejora considerablemente hermeticidad, pero suele tener 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 de evaluación incremental, funcional y paralelo principal de Bazel.
Estampado
Una función para incorporar información adicional en entornos
artefactos. Se puede usar para controlar el código fuente, compilar
y otra información relacionada con el espacio 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 R
subconjunto restringido de Python (sintáctica y gramaticalmente) destinado a las
de la configuración y para mejorar el rendimiento. Usa el .bzl
. BUILD archivos usan un
versión restringida de Starlark (como sin definiciones de función def), que antes se
conocido como Skylark.
Consulta también: documentación sobre lenguaje de Starlark
Marcas de inicio
El conjunto de marcas especificadas entre bazel y el comando
Por ejemplo, la compilación de bazel --host_jvm_debug. Estas marcas modifican el
configuración del servidor de Bazel, por lo que cualquier modificación del
las marcas de inicio reinician el servidor. Las marcas de inicio no son específicas de ninguna
.
Objetivo
Un objeto que se define en un archivo BUILD y se identifica con un
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 regla
objetivo. Según la regla, estos se pueden ejecutar (como
cc_binary) o se pueden probar (como cc_test). Los objetivos de las reglas
suelen depender de
otras orientaciones mediante sus atributos (como deps) estas
las dependencias forman la base del gráfico objetivo.
Además de los objetivos de las reglas, también existen los objetivos de archivo y los grupos de paquetes.
objetivos. Los destinos de archivo corresponden a los artefactos a los que se hace referencia
dentro de un archivo BUILD. Como caso especial, el archivo BUILD de cualquier paquete se
se considera siempre como destino
del archivo fuente en ese paquete.
Los objetivos se descubren durante la fase de carga. Durante el fase de análisis, los objetivos están asociados con compilación de Terraform para formar configuraciones objetivos.
Gráfico de destino
Un gráfico en la memoria de objetivos y sus dependencias. Producida durante la fase de carga y se utiliza como entrada para el análisis por fases.
Patrón de objetivo
Una manera de especificar un grupo de destinos en la línea de comandos. Comúnmente
los patrones utilizados son :all (todos los objetivos de la regla), :* (todos los destinos de la regla y del archivo),
... (el paquete actual y todos los subpaquetes, de forma recurrente). Se puede usar
en conjunto, por ejemplo, //...:* significa todos los objetivos de reglas y archivos de todos
paquetes de manera recurrente desde la raíz de workspace.
Pruebas
Reglas que se crearon en destinos a partir de reglas de prueba y, por lo tanto, contienen un ejecutable de prueba. Un código de retorno de cero desde la finalización del ejecutable indica que la prueba fue exitosa. El contrato exacto entre Bazel y las pruebas (como los variables de entorno o métodos de recopilación de resultados de pruebas) se especifica en la sección Enciclopedia.
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 es decir, los componentes del conjunto de herramientas del compilador Unix pueden diferir Variante de Windows, aunque la cadena de herramientas es para el mismo idioma. Selección el conjunto de herramientas adecuado para la plataforma se conoce como resolución del conjunto de herramientas.
Objetivo de nivel superior
Un destino de compilación es de nivel superior si se solicita en el comando de Bazel.
línea. Por ejemplo, si //:foo depende de //:bar, y bazel build //:foo es
se llama, entonces, para esta compilación, //:foo es de nivel superior y //:bar no es
nivel superior, aunque deberán crearse ambos objetivos. Una diferencia importante
entre objetivos de nivel superior y no de nivel superior es que comando
de marcas establecidas en la línea de comandos de Bazel (o mediante
.bazelrc) establecerá la configuración para los
pero se pueden modificar con una transición para los segmentos
objetivos.
Transición
Es una asignación del estado de la configuración de un valor a otro. Permite que los objetivos en el gráfico de compilación tengan valores diferentes parámetros de configuración, incluso si se crearon instancias de la misma regla. R El uso común de las transiciones es con las transiciones divididas, en las que ciertas partes el gráfico de destino se bifurca con parámetros de configuración distintos para cada tenedor. Por ejemplo, se puede compilar un APK de Android con objetos binarios nativos compilada para ARM y x86 con 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 estas no son artefactos en sí mismos, una acción que opera en ellos debe sino que lo registra como su entrada o salida.
Visibilidad
Uno de estos dos mecanismos para evitar dependencias no deseadas en el sistema de compilación:
visibilidad del objetivo para controlar si se puede depender de un objetivo
por otros objetivos; y visibilidad de carga para controlar si un 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
Lugar de trabajo
El entorno que comparten todos los comandos de Bazel se ejecutan desde la misma instancia principal. Cloud Storage.
Históricamente, los conceptos de “repositorio” y “espacio de trabajo” han sido combinadas; el término “espacio de trabajo” se suele usar para referirse a los principales repositorio y, a veces, incluso se usa como sinónimo de "repositorio". Dicho uso debe evitarse para mayor claridad.