Se usó la API de Cloud Translation para traducir esta página.

Compila programas con Bazel

En esta página, se explica cómo compilar un programa con Bazel, la sintaxis del comando de compilación y la sintaxis de patrones de destino.

Guía de inicio rápido

Para ejecutar Bazel, ve al directorio base workspace o cualquiera de sus subdirectorios y escribe bazel. Consulta compilación si necesitas crear un lugar de trabajo nuevo.

bazel help
                             [Bazel release bazel version]
Usage: bazel command options ...

Comandos disponibles:

analyze-profile: Analiza los datos de perfil de compilación.
aquery: Ejecuta una consulta en el gráfico de acción posterior al análisis.
build: Compila los destinos especificados.
canonicalize-flags: Canonicaliza marcas de Bazel.
clean: Quita los archivos de salida y, de manera opcional, detiene el servidor.
cquery: Ejecuta una consulta de gráfico de dependencia posterior al análisis.
dump: Vuelca el estado interno del proceso del servidor de Bazel.
help: Muestra la ayuda para los comandos o el índice.
info: Muestra la información del entorno de ejecución del servidor de Bazel.
fetch: Recupera todas las dependencias externas de un destino.
mobile-install: Instala apps en dispositivos móviles.
query: Ejecuta una consulta de gráfico de dependencia.
run: Ejecuta el destino especificado.
shutdown: Detiene el servidor de Bazel.
test: Compila y ejecuta los destinos de prueba especificados.
version: Imprime la información de la versión de Bazel.

Cómo obtener ayuda

bazel help command: Imprime la ayuda y las opciones para command.
bazel helpstartup_options: Opciones para la JVM que aloja a Bazel
bazel helptarget-syntax: Explica la sintaxis para especificar objetivos.
bazel help info-keys: Muestra una lista de teclas que usa el comando de información.

La herramienta bazel realiza muchas funciones llamadas comandos. Las más usadas son bazel build y bazel test. Puedes explorar los mensajes de ayuda en línea con bazel help.

Creación de un objetivo

Antes de iniciar una compilación, necesitas un espacio de trabajo. Un lugar de trabajo es un árbol de directorios que contiene todos los archivos de origen necesarios para compilar la aplicación. Bazel te permite realizar una compilación desde un volumen de solo lectura.

Para compilar un programa con Bazel, escribe bazel build seguido del destino que quieras compilar.

bazel build //foo

Después de ejecutar el comando para compilar //foo, verás un resultado similar a este:

INFO: Analyzed target //foo:foo (14 packages loaded, 48 targets configured).
INFO: Found 1 target...
Target //foo:foo up-to-date:
  bazel-bin/foo/foo
INFO: Elapsed time: 9.905s, Critical Path: 3.25s
INFO: Build completed successfully, 6 total actions

Primero, Bazel carga todos los paquetes en el gráfico de dependencias de tu destino. Esto incluye las dependencias declaradas, los archivos que se enumeran directamente en el archivo BUILD del destino y las dependencias transitivas, los archivos que se enumeran en los archivos BUILD de las dependencias del destino. Después de identificar todas las dependencias, Bazel las analiza para comprobar su precisión y crea las acciones de compilación. Por último, Bazel ejecuta los compiladores y otras herramientas de la compilación.

Durante la fase de ejecución de la compilación, Bazel imprime mensajes de progreso. Los mensajes de progreso incluyen el paso de compilación actual (como el compilador o el vinculador) cuando se inicia y la cantidad completada sobre el total de acciones de compilación. A medida que comienza la compilación, la cantidad total de acciones suele aumentar a medida que Bazel descubre el gráfico de acciones completo, pero el número se estabiliza en pocos segundos.

Al final de la compilación, Bazel imprime qué destinos se solicitaron, sin que se hayan compilado de forma correcta y, de ser así, dónde se pueden encontrar los archivos de salida. Las secuencias de comandos que ejecutan compilaciones pueden analizar este resultado de manera confiable. Consulta --show_result para obtener más detalles.

Si vuelves a escribir el mismo comando, la compilación finalizará mucho más rápido.

bazel build //foo
INFO: Analyzed target //foo:foo (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //foo:foo up-to-date:
  bazel-bin/foo/foo
INFO: Elapsed time: 0.144s, Critical Path: 0.00s
INFO: Build completed successfully, 1 total action

Esta es una null build. Debido a que nada cambió, no hay paquetes para volver a cargar ni pasos de compilación para ejecutar. Si algo cambiaba en "foo" o en sus dependencias, Bazel volvería a ejecutar algunas acciones de compilación o completaba una compilación incremental.

Cómo compilar varios destinos

Bazel permite varias formas de especificar los destinos que se compilarán. En conjunto, estos se conocen como patrones objetivo. Esta sintaxis se usa en comandos como build, test o query.

Mientras que las etiquetas se usan para especificar destinos individuales, por ejemplo, para declarar dependencias en archivos BUILD, los patrones de destino de Bazel especifican varios objetivos. Los patrones de destino son una generalización de la sintaxis de las etiquetas para conjuntos de destinos mediante comodines. En el caso más simple, cualquier etiqueta válida también es un patrón de destino válido, que identifica un conjunto de exactamente un objetivo.

Todos los patrones de destino que comienzan con // se resuelven en relación con el lugar de trabajo actual.

`//foo/bar:wiz`	Solo el `//foo/bar:wiz` objetivo.
`//foo/bar`	Equivale a `//foo/bar:bar`.
`//foo/bar:all`	Todos los objetivos de la regla del paquete `foo/bar`
`//foo/...`	Los objetivos de todas las reglas en todos los paquetes debajo del directorio `foo`
`//foo/...:all`	Los objetivos de todas las reglas en todos los paquetes debajo del directorio `foo`
`//foo/...:*`	Todos los destinos (reglas y archivos) en todos los paquetes debajo del directorio `foo`.
`//foo/...:all-targets`	Todos los destinos (reglas y archivos) en todos los paquetes debajo del directorio `foo`.
`//...`	Todos los destinos en paquetes del lugar de trabajo. Esto no incluye destinos de repositorios externos.
`//:all`	Todos los destinos en el paquete de nivel superior, si hay un archivo “BUILD” en la raíz del lugar de trabajo.

Los patrones de destino que no comienzan con // se resuelven en relación con el directorio de trabajo actual. En estos ejemplos, se supone que hay un directorio de trabajo de foo:

`:foo`	Equivale a `//foo:foo`.
`bar:wiz`	Equivale a `//foo/bar:wiz`.
`bar/wiz`	Equivale a lo siguiente: `//foo/bar/wiz:wiz` si `foo/bar/wiz` es un paquete `//foo/bar:wiz` si `foo/bar` es un paquete `//foo:bar/wiz` por lo demás
`bar:all`	Equivale a `//foo/bar:all`.
`:all`	Equivale a `//foo:all`.
`...:all`	Equivale a `//foo/...:all`.
`...`	Equivale a `//foo/...:all`.
`bar/...:all`	Equivale a `//foo/bar/...:all`.

De forma predeterminada, se siguen los symlinks de directorio para los patrones de destino recursivos, excepto aquellos que apuntan a la base de salida, como los symlinks de conveniencia que se crean en el directorio raíz del lugar de trabajo.

Además, Bazel no sigue symlinks cuando evalúa patrones de destino recursivos en ningún directorio que contenga un archivo con el siguiente nombre: DONT_FOLLOW_SYMLINKS_WHEN_TRAVERSING_THIS_DIRECTORY_VIA_A_RECURSIVE_TARGET_PATTERN

foo/... es un comodín sobre paquetes que indica todos los paquetes de forma recurrente debajo del directorio foo (para todas las raíces de la ruta del paquete). :all es un comodín sobre objetivos, que coincide con todas las reglas dentro de un paquete. Estos dos se pueden combinar, como en foo/...:all, y cuando se usan ambos comodines, esto puede abreviarse como foo/....

Además, :* (o :all-targets) es un comodín que coincide con todos los destinos de los paquetes coincidentes, incluidos los archivos que normalmente no compilan ninguna regla, como los archivos _deploy.jar asociados con reglas java_binary.

Esto implica que :* denota un superconjunto de :all; aunque puede ser confusa, esta sintaxis permite que se use el comodín :all conocido para compilaciones típicas, en las que no se desea compilar destinos como _deploy.jar.

Además, Bazel permite usar una barra en lugar de los dos puntos requeridos por la sintaxis de la etiqueta, lo que suele ser conveniente cuando se usa la expansión de nombre de archivo Bash. Por ejemplo, foo/bar/wiz equivale a //foo/bar:wiz (si hay un paquete foo/bar) o a //foo:bar/wiz (si hay un paquete foo).

Muchos comandos de Bazel aceptan una lista de patrones de destino como argumentos y todos respetan el operador de negación de prefijo -. Puedes usar esta opción para restar un conjunto de objetivos del conjunto especificado en los argumentos anteriores. Ten en cuenta que esto significa que el orden es importante. Por ejemplo,

bazel build foo/... bar/...

significa "compilar todos los destinos por debajo de foo y todos los destinos por debajo de bar", mientras que

bazel build -- foo/... -foo/bar/...

significa "compilar todos los destinos debajo de foo, excepto los que están debajo de foo/bar". (Se requiere el argumento -- para evitar que los argumentos posteriores que comiencen con - se interpreten como opciones adicionales).

Sin embargo, es importante señalar que restar los objetivos de esta manera no garantizará que no se compilen, ya que pueden ser dependencias de objetivos que no se restaron. Por ejemplo, si hubiera un //foo:all-apis de destino que, entre otros, dependiera de //foo/bar:api, este último se compilaría como parte de la compilación del primero.

Los destinos con tags = ["manual"] no se incluyen en patrones de destino comodín (..., :*, :all, etc.) cuando se especifican en comandos como bazel build y bazel test. Debes especificar esos destinos de prueba con patrones de destino explícitos en la línea de comandos si deseas que Bazel los compile o pruebe. Por el contrario, bazel query no realiza ninguno de estos filtros automáticamente (eso anularía el propósito de bazel query).

Recupera dependencias externas

De forma predeterminada, Bazel descargará dependencias externas y vinculará mediante symlinks externos durante la compilación. Sin embargo, esto puede no ser conveniente, ya sea porque deseas saber cuándo se agregan nuevas dependencias externas o porque deseas realizar una "carga previa" de las dependencias (por ejemplo, antes de un vuelo en el que te conectarás). Si deseas evitar que se agreguen dependencias nuevas durante las compilaciones, puedes especificar la marca --fetch=false. Ten en cuenta que esta marca solo se aplica a las reglas del repositorio que no apuntan a un directorio en el sistema de archivos local. Los cambios, por ejemplo, en local_repository, new_local_repository y las reglas del repositorio del SDK de Android y del NDK, siempre se aplicarán, sin importar el valor --fetch .

Si no permites la recuperación durante las compilaciones y Bazel encuentra dependencias externas nuevas, tu compilación fallará.

Para recuperar las dependencias de forma manual, ejecuta bazel fetch. Si inhabilitas la recuperación durante la compilación, deberás ejecutar bazel fetch:

Antes de compilar por primera vez
Después de agregar una dependencia externa nueva.

Una vez que se haya ejecutado, no será necesario que vuelvas a ejecutarla hasta que cambie el archivo WORKSPACE.

fetch toma una lista de destinos para los que se recuperarán las dependencias. Por ejemplo, esto recuperaría las dependencias necesarias para compilar //foo:bar y //bar:baz:

bazel fetch //foo:bar //bar:baz

Para recuperar todas las dependencias externas de un lugar de trabajo, ejecuta el siguiente comando:

bazel fetch //...

No es necesario que ejecutes la recuperación de Bazel si tienes todas las herramientas que usas (desde archivos jar de bibliotecas hasta el JDK mismo) en la raíz de tu lugar de trabajo. Sin embargo, si usas algo fuera del directorio del lugar de trabajo, Bazel ejecutará automáticamente bazel fetch antes de ejecutar bazel build.

La caché del repositorio

Bazel intenta evitar recuperar el mismo archivo varias veces, incluso si se necesita el mismo archivo en lugares de trabajo diferentes o si cambia la definición de un repositorio externo, pero necesita el mismo archivo para descargarlo. Para ello, bazel almacena en caché todos los archivos descargados en la caché del repositorio, que, de forma predeterminada, se encuentra en ~/.cache/bazel/_bazel_$USER/cache/repos/v1/. Se puede cambiar la ubicación con la opción --repository_cache. La caché se comparte entre todos los lugares de trabajo y las versiones instaladas de Bazel. Se toma una entrada de la caché si Bazel sabe con certeza que tiene una copia del archivo correcto, es decir, si la solicitud de descarga tiene una suma SHA256 del archivo especificado y un archivo con ese hash está en la caché. Por lo tanto, especificar un hash para cada archivo externo no solo es una buena idea desde una perspectiva de seguridad, sino que también ayuda a evitar descargas innecesarias.

Con cada acierto de caché, se actualiza la hora de modificación del archivo en la caché. De esta manera, el último uso de un archivo en el directorio de caché se puede determinar con facilidad, por ejemplo, para limpiar la caché de forma manual. La caché nunca se limpia automáticamente, ya que puede contener una copia de un archivo que ya no está disponible en sentido ascendente.

Directorios de archivos de distribución

El directorio de distribución es otro mecanismo de Bazel para evitar descargas innecesarias. Bazel busca directorios de distribución antes de la caché del repositorio. La diferencia principal es que el directorio de distribución requiere preparación manual.

Con la opción --distdir=/path/to-directory, puedes especificar directorios de solo lectura adicionales para buscar archivos en lugar de recuperarlos. Se toma un archivo de ese directorio si el nombre del archivo es igual al nombre base de la URL y, además, si el hash del archivo es igual al especificado en la solicitud de descarga. Esto solo funciona si el hash del archivo se especifica en la declaración WORKSPACE.

Si bien la condición del nombre del archivo no es necesaria para la precisión, reduce la cantidad de archivos candidatos a uno por directorio especificado. De esta manera, la especificación de directorios de archivos de distribución sigue siendo eficiente, incluso si la cantidad de archivos en ese directorio aumenta.

Ejecución de Bazel en un entorno aislado

Para mantener pequeño el tamaño del objeto binario de Bazel, se recuperan las dependencias implícitas de Bazel a través de la red mientras se ejecutan por primera vez. Estas dependencias implícitas contienen cadenas de herramientas y reglas que pueden no ser necesarias para todos. Por ejemplo, las herramientas de Android no están agrupadas y se recuperan solo cuando se compilan proyectos de Android.

Sin embargo, estas dependencias implícitas pueden causar problemas cuando se ejecuta Bazel en un entorno aislado, incluso si creaste proveedores de todas tus dependencias de WORKSPACE. Para solucionar esto, puedes preparar un directorio de distribución que contenga estas dependencias en una máquina con acceso a la red y, luego, transferirlas al entorno aislado con un enfoque sin conexión.

Para preparar el directorio de distribución, usa la marca --distdir. Deberás hacerlo una vez para cada versión nueva del objeto binario de Bazel, ya que las dependencias implícitas pueden ser diferentes en cada versión.

Para compilar estas dependencias fuera de tu entorno aislado, primero confirma la compra del árbol de fuentes de Bazel en la versión correcta:

git clone https://github.com/bazelbuild/bazel "$BAZEL_DIR"
cd "$BAZEL_DIR"
git checkout "$BAZEL_VERSION"

Luego, compila el archivo tarball que contiene las dependencias implícitas del entorno de ejecución para esa versión específica de Bazel:

bazel build @additional_distfiles//:archives.tar

Exporta este archivo comprimido a un directorio que se pueda copiar en tu entorno aislado. Observa la marca --strip-components, ya que --distdir puede ser bastante complejo con el nivel de anidamiento del directorio:

tar xvf bazel-bin/external/additional_distfiles/archives.tar \
  -C "$NEW_DIRECTORY" --strip-components=3

Por último, cuando uses Bazel en tu entorno aislado, pasa la marca --distdir que apunta al directorio. Para mayor comodidad, puedes agregarla como una entrada .bazelrc:

build --distdir=path/to/directory

Configuraciones de compilación y compilación cruzada

Todas las entradas que especifican el comportamiento y el resultado de una compilación determinada se pueden dividir en dos categorías distintas. El primer tipo es la información intrínseca almacenada en los archivos BUILD de tu proyecto: la regla de compilación, los valores de sus atributos y el conjunto completo de sus dependencias transitivas. El segundo son los datos externos o ambientales que proporciona el usuario o la herramienta de compilación: la elección de la arquitectura de destino, las opciones de compilación y vinculación, y otras opciones de configuración de la cadena de herramientas. Nos referimos a un conjunto completo de datos del entorno como una configuración.

En una compilación determinada, puede haber más de una configuración. Considera una compilación cruzada, en la que compilas un ejecutable //foo:bin para una arquitectura de 64 bits, pero tu estación de trabajo es una máquina de 32 bits. Claramente, la compilación requerirá compilar //foo:bin con una cadena de herramientas capaz de crear ejecutables de 64 bits, pero el sistema de compilación también debe compilar varias herramientas utilizadas durante la compilación (por ejemplo, herramientas que se compilan a partir de la fuente y, luego, se usan en, por ejemplo, una genrule) y estas deben compilarse para ejecutarse en tu estación de trabajo. Por lo tanto, podemos identificar dos configuraciones: la configuración de host, que se usa para compilar herramientas que se ejecutan durante la compilación, y la configuración de destino (o configuración de solicitud, pero decimos "configuración de destino" con mayor frecuencia, aunque esa palabra ya tiene muchos significados), que se usa para compilar el objeto binario que solicitaste en última instancia.

Por lo general, hay muchas bibliotecas que son requisitos previos tanto del destino de compilación solicitado (//foo:bin) como de una o más de las herramientas de host, por ejemplo, algunas bibliotecas base. Esas bibliotecas deben compilarse dos veces, una para la configuración del host y otra para la configuración de destino. Bazel se encarga de garantizar que se compilen ambas variantes y que los archivos derivados se mantengan separados para evitar interferencias. Por lo general, esos destinos se pueden compilar de forma simultánea, ya que son independientes entre sí. Si ves mensajes de progreso que indican que un destino determinado se está compilando dos veces, es probable que esta sea la explicación.

Bazel usa una de dos maneras para seleccionar la configuración del host, según la opción --distinct_host_configuration. Esta opción booleana es sutil y la configuración puede mejorar (o empeorar) la velocidad de tus compilaciones.

`--distinct_host_configuration=false`

Cuando esta opción es falsa, las configuraciones del host y de la solicitud son idénticas: todas las herramientas requeridas durante la compilación se compilarán de la misma manera que los programas de destino. Esta configuración significa que no es necesario compilar bibliotecas dos veces durante una sola compilación.

Sin embargo, significa que cualquier cambio en la configuración de la solicitud también afecta la configuración del host, lo que hace que se vuelvan a compilar todas las herramientas y, luego, se vuelva a compilar todo lo que dependa del resultado de la herramienta. Entonces, por ejemplo, el simple cambio de una opción de vinculador entre compilaciones puede hacer que todas las herramientas se vuelvan a vincular y, luego, todas las acciones que las usan se vuelvan a ejecutar, y así sucesivamente, lo que daría como resultado una recompilación muy grande.

`--distinct_host_configuration=true` (predeterminado)

Si esta opción es verdadera, en lugar de usar la misma configuración para el host y la solicitud, se usa una configuración de host completamente distinta. La configuración del host deriva de la configuración de destino de la siguiente manera:

Usa la misma versión de Crosstool (--crosstool_top) según se especifica en la configuración de la solicitud, a menos que se especifique --host_crosstool_top.
Usa el valor de --host_cpu para --cpu (valor predeterminado: k8).
Usa los mismos valores de estas opciones que se especifican en la configuración de la solicitud: --compiler, --use_ijars. Si se usa --host_crosstool_top, se usa el valor de --host_cpu a fin de buscar un default_toolchain en Crosstool (sin tener en cuenta --compiler) para la configuración del host.
Usa el valor de --host_javabase para --javabase
Usa el valor de --host_java_toolchain para --java_toolchain
Usa compilaciones optimizadas para código C++ (-c opt).
No genera información de depuración (--copt=-g0).
Quita la información de depuración de archivos ejecutables y bibliotecas compartidas (--strip=always).
Coloca todos los archivos derivados en una ubicación especial, distinta de la que usa cualquier configuración de solicitud posible.
Elimina el sello de objetos binarios con datos de compilación (consulta las opciones de --embed_*).
Todos los demás valores permanecen con su configuración predeterminada.

Existen muchos motivos por los que puede ser preferible seleccionar una configuración de host distinta de la configuración de la solicitud. Algunos son demasiado esotéricos para mencionarlos aquí, pero vale la pena señalar dos de ellos.

En primer lugar, cuando usas objetos binarios optimizados y separados, reduces el tiempo dedicado a vincular y ejecutar las herramientas, el espacio en el disco que ocupan las herramientas y el tiempo de E/S de la red en compilaciones distribuidas.

En segundo lugar, si separas las configuraciones de host y de solicitud en todas las compilaciones, evitas las recompilaciones muy costosas que resultarían de cambios menores en la configuración de la solicitud (como el cambio de opciones de vinculador), como se describió antes.

Dicho esto, para ciertas compilaciones, esta opción puede ser un impedimento. En particular, es posible que no se beneficien las compilaciones en las que los cambios de configuración son poco frecuentes (en especial, ciertas compilaciones de Java) y las compilaciones en las que la cantidad de código que se debe compilar en las configuraciones del host y el destino es grande.

Corregir recompilaciones incrementales

Uno de los objetivos principales del proyecto de Bazel es garantizar recompilaciones incrementales correctas. Las herramientas de compilación anteriores, en especial las basadas en Make, realizan varias suposiciones incorrectas en su implementación de compilaciones incrementales.

Primero, las marcas de tiempo de los archivos aumentan monótonamente. Si bien este es el caso típico, es muy fácil equivocarse con esta suposición. La sincronización con una revisión anterior de un archivo disminuye el tiempo de modificación de ese archivo y los sistemas basados en la marca no se volverán a compilar.

En general, si bien Make detecta cambios en los archivos, no detecta los cambios en los comandos. Si modificas las opciones que se pasan al compilador en un paso de compilación determinado, Make no volverá a ejecutar el compilador, y es necesario descartar de forma manual los resultados no válidos de la compilación anterior usando make clean.

Además, Make no es sólida ante la finalización fallida de uno de sus subprocesos después de que ese subproceso comenzó a escribir en su archivo de salida. Si bien la ejecución actual de Make fallará, la invocación posterior de Make asumirá ciegamente que el archivo de salida truncado es válido (porque es más reciente que sus entradas) y que no se volverá a compilar. De manera similar, si se finaliza el proceso de Make, puede ocurrir una situación similar.

Bazel evita estas suposiciones y otras. Bazel mantiene una base de datos de todo el trabajo realizado anteriormente y solo omitirá un paso de compilación si descubre que el conjunto de archivos de entrada (y sus marcas de tiempo) de ese paso y el comando de compilación para ese paso de compilación coinciden exactamente con uno en la base de datos y que el conjunto de archivos de salida (y sus marcas de tiempo) para la entrada de la base de datos coincide exactamente con las marcas de tiempo de los archivos en el disco. Cualquier cambio en los archivos de entrada o de salida, o en el propio comando, hará que se vuelva a ejecutar el paso de compilación.

El beneficio para los usuarios de las compilaciones incrementales correctas es que se pierde menos tiempo debido a la confusión. (Además, se destinó menos tiempo a esperar recompilaciones causadas por el uso de make clean, ya sea necesario o preventivo).

Coherencia de la compilación y compilaciones incrementales

De manera formal, definimos el estado de una compilación como coherente cuando existen todos los archivos de salida esperados y su contenido es correcto, según se especifica en los pasos o las reglas necesarios para crearlos. Cuando editas un archivo fuente, se dice que el estado de la compilación es incoherente y que no es coherente hasta que ejecutes la herramienta de compilación de forma correcta. Describimos esta situación como una inconsistencia inestable porque es solo temporal, y la coherencia se restablece cuando ejecutas la herramienta de compilación.

Existe otro tipo de inconsistencia que es pernicioso: la inconsistencia estable. Si la compilación alcanza un estado incoherente estable, la invocación correcta de la herramienta de compilación no restablece la coherencia: la compilación se "atascó", y los resultados siguen siendo incorrectos. Los estados incoherentes estables son la razón principal por la que los usuarios de Make (y otras herramientas de compilación) escriben make clean. Descubrir que la herramienta de compilación falló de esta manera (y, luego, recuperarse de ella) puede llevar mucho tiempo y ser muy frustrante.

Conceptualmente, la forma más simple de lograr una compilación coherente es descartar todos los resultados de la compilación anterior y comenzar de nuevo: hacer que cada compilación sea una compilación limpia. Obviamente, este enfoque lleva demasiado tiempo para ser práctico (excepto tal vez para los ingenieros de lanzamientos) y, por lo tanto, para ser útil, la herramienta de compilación debe poder realizar compilaciones incrementales sin comprometer la coherencia.

Corregir el análisis incremental de dependencias es difícil y, como se describió antes, muchas otras herramientas de compilación hacen un mal trabajo al evitar estados incoherentes estables durante las compilaciones incrementales. Por el contrario, Bazel ofrece la siguiente garantía: después de una invocación correcta de la herramienta de compilación durante la cual no hiciste ediciones, la compilación estará en un estado coherente. (Si editas los archivos de origen durante una compilación, Bazel no garantiza la coherencia del resultado de la compilación actual. Sin embargo, sí garantiza que los resultados de la siguiente compilación restablecerán la coherencia).

Al igual que con todas las garantías, hay algunas condiciones pequeñas: existen algunas formas conocidas de caer en un estado inestable y estable con Bazel. No podemos garantizar la investigación de estos problemas que surjan de intentos deliberados de encontrar errores en el análisis de dependencia incremental, pero investigaremos y haremos todo lo posible para solucionar todos los estados incoherentes estables que surjan del uso normal o "razonable" de la herramienta de compilación.

Si alguna vez detectas un estado incoherente estable con Bazel, informa el error.

Ejecución en la zona de pruebas

Bazel usa zonas de pruebas para garantizar que las acciones se ejecuten de forma hermética y correcta. Bazel ejecuta generaciones (en pocas palabras, acciones) en zonas de pruebas que solo contienen el conjunto mínimo de archivos que la herramienta requiere para realizar su trabajo. Actualmente, la zona de pruebas funciona en Linux 3.12 o versiones posteriores con la opción CONFIG_USER_NS habilitada y también en macOS 10.11 o versiones posteriores.

Bazel mostrará una advertencia si tu sistema no admite la zona de pruebas para alertarte sobre el hecho de que no se garantiza que las compilaciones sean herméticas y podrían afectar al sistema host de maneras desconocidas. Para inhabilitar esta advertencia, puedes pasar la marca --ignore_unsupported_sandboxing a Bazel.

En algunas plataformas, como los nodos del clúster de Google Kubernetes Engine o Debian, los espacios de nombres de los usuarios se desactivan de forma predeterminada debido a cuestiones de seguridad. Para verificar esto, observa el archivo /proc/sys/kernel/unprivileged_userns_clone: si existe y contiene un 0, los espacios de nombres del usuario se pueden activar con sudo sysctl kernel.unprivileged_userns_clone=1.

En algunos casos, la zona de pruebas de Bazel no ejecuta las reglas debido a la configuración del sistema. Por lo general, el síntoma es una falla que genera un mensaje similar a namespace-sandbox.c:633: execvp(argv[0], argv): No such file or directory. En ese caso, intenta desactivar la zona de pruebas para genrules con --strategy=Genrule=standalone y para otras reglas con --spawn_strategy=standalone. Además, informa un error en nuestra Herramienta de seguimiento de errores y menciona qué distribución de Linux estás utilizando para que podamos investigar el problema y proporcionar una solución en una versión posterior.

Fases de una compilación

En Bazel, una compilación ocurre en tres fases distintas. Como usuario, comprender la diferencia entre ellas proporciona estadísticas sobre las opciones que controlan una compilación (consulta a continuación).

Fase de carga

El primero es la carga, durante la cual se cargan, analizan, evalúan y almacenan en caché todos los archivos BUILD necesarios para los destinos iniciales y su cierre transitivo de dependencias.

En la primera compilación después de que se inicia un servidor de Bazel, la fase de carga suele tardar muchos segundos, ya que muchos archivos BUILD se cargan desde el sistema de archivos. En las compilaciones posteriores, en especial si no cambiaron archivos BUILD, la carga se produce muy rápido.

Los errores informados durante esta fase incluyen los siguientes: no se encontró el paquete, el objetivo no se encontró, los errores léxicos y gramaticales en un archivo BUILD, y los errores de evaluación.

Fase de análisis

La segunda fase, el análisis, implica el análisis semántico y la validación de cada regla de compilación, la construcción de un gráfico de dependencia de compilación y la determinación exacta del trabajo que se debe realizar en cada paso de la compilación.

Al igual que la carga, el análisis también tarda varios segundos cuando se calcula en su totalidad. Sin embargo, Bazel almacena en caché el gráfico de dependencia de una compilación a la siguiente y solo vuelve a analizar lo que debe hacer, lo que puede hacer que las compilaciones incrementales sean extremadamente rápidas en caso de que los paquetes no hayan cambiado desde la compilación anterior.

Los errores informados en esta etapa incluyen dependencias inapropiadas, entradas no válidas a una regla y todos los mensajes de error específicos de la regla.

Las fases de carga y análisis son rápidas porque Bazel evita la E/S de archivos necesaria en esta etapa y solo lee archivos BUILD para determinar el trabajo que se realizará. Esto es así por diseño y hace que Bazel sea una buena base para las herramientas de análisis, como el comando query de Bazel, que se implementa en la parte superior de la fase de carga.

Fase de ejecución

La tercera y última fase de la compilación es la ejecución. Esta fase garantiza que los resultados de cada paso de la compilación sean coherentes con sus entradas y vuelve a ejecutar las herramientas de compilación, vinculación, etc. según sea necesario. En este paso, la compilación pasa la mayor parte del tiempo, que va desde unos segundos hasta más de una hora para una compilación grande. Los errores informados durante esta fase incluyen archivos de origen faltantes, errores en una herramienta ejecutada por alguna acción de compilación o fallas de una herramienta para producir el conjunto esperado de resultados.