Comandos y opciones

Informa un problemaopen_in_new Ver código fuenteopen_in_new

En esta página, se describen las opciones disponibles con varios comandos de Bazel, como bazel build, bazel run y bazel test. Esta página es un complemento de la lista de comandos de Bazel en Compilación con Bazel.

Sintaxis de destino

Algunos comandos, como build o test, pueden operar en una lista de destinos. Usan una sintaxis más flexible que las etiquetas, que se documenta en Especifica destinos para la compilación.

Opciones

En las siguientes secciones, se describen las opciones disponibles durante una compilación. Cuando se usa --long en un comando de ayuda, los mensajes de ayuda en línea proporcionan información resumida sobre el significado, el tipo y el valor predeterminado para cada opción.

La mayoría de las opciones solo se pueden especificar una vez. Cuando se especifica varias veces, la última instancia gana. Las opciones que se pueden especificar varias veces se identifican en la ayuda en línea con el texto "puede usarse varias veces".

Ubicación del paquete

--package_path

Esta opción especifica el conjunto de directorios en los que se busca el archivo BUILD para un paquete determinado.

Bazel encuentra sus paquetes en la ruta de acceso del paquete. Esta es una lista ordenada separada por dos puntos de los directorios de Bazel, cada una de las cuales es la raíz de un árbol de origen parcial.

Para especificar una ruta de paquete personalizada con la opción --package_path, haz lo siguiente:

  % bazel build --package_path %workspace%:/some/other/root

Los elementos de la ruta del paquete se pueden especificar en tres formatos:

1. Si el primer carácter es /, la ruta es absoluta.
2. Si la ruta de acceso comienza con %workspace%, se toma en relación con el directorio de Bazel que la contiene más cerca. Por ejemplo, si tu directorio de trabajo es /home/bob/clients/bob_client/bazel/foo, la string %workspace% en la ruta del paquete se expande a /home/bob/clients/bob_client/bazel.
3. Todo lo demás se toma en relación con el directorio de trabajo. Por lo general, esto no es lo que quieres hacer y puede comportarse de forma inesperada si usas Bazel desde directorios debajo del lugar de trabajo de Bazel. Por ejemplo, si usas el elemento de ruta de paquete . y, luego, seleccionas cd en el directorio /home/bob/clients/bob_client/bazel/foo, los paquetes se resolverán desde el directorio /home/bob/clients/bob_client/bazel/foo.

Si usas una ruta de paquete no predeterminada, especifícala en tu archivo de configuración de Bazel para mayor comodidad.

Bazel no requiere que ningún paquete esté en el directorio actual, por lo que puedes realizar una compilación desde un lugar de trabajo de Bazel vacío si todos los paquetes necesarios se pueden encontrar en otro lugar de la ruta del paquete.

Ejemplo: compilación a partir de un cliente vacío

  % mkdir -p foo/bazel
  % cd foo/bazel
  % touch WORKSPACE
  % bazel build --package_path /some/other/path //foo

--deleted_packages

Esta opción especifica una lista de paquetes separados por comas que Bazel debe considerar borrar y no intenta cargar desde ningún directorio de la ruta del paquete. Esto se puede usar para simular la eliminación de paquetes sin borrarlos. Esta opción se puede pasar varias veces, en cuyo caso las concatenan las listas individuales.

Comprobación de errores

Estas opciones controlan la comprobación de errores o las advertencias de Bazel.

--[no]check_visibility

Si esta opción se configura como falsa, las verificaciones de visibilidad descienden a advertencias. El valor predeterminado de esta opción es verdadero, por lo que se realiza la verificación de visibilidad de forma predeterminada.

--output_filter=regex

La opción --output_filter solo mostrará advertencias de compilación y compilación para objetivos que coincidan con la expresión regular. Si un objetivo no coincide con la expresión regular determinada y su ejecución se realiza de forma correcta, el resultado estándar y el error estándar se descartan.

Estos son algunos valores típicos de esta opción:

`--output_filter='^//(first/project|second/project):'`	Muestra el resultado de los paquetes especificados.
`--output_filter='^//((?!(first/bad_project|second/bad_project):).)*$'	No mostrar el resultado de los paquetes especificados
“--output_filter=”	Mostrar todo.
`--output_filter=DONT_MATCH_ANYTHING`	No mostrar nada.

Marcas de herramientas

Estas opciones controlan qué opciones pasará Bazel a otras herramientas.

--copt=cc-option

Esta opción toma un argumento que se pasará al compilador. El argumento se pasará al compilador cada vez que se invoque para procesar previamente, compilar o ensamblar código C, C++ o ensamblador. No se pasará durante la vinculación.

Esta opción se puede usar varias veces. Por ejemplo:

  % bazel build --copt="-g0" --copt="-fpic" //foo

compilará la biblioteca foo sin tablas de depuración, lo que generará código independiente de la posición.

--host_copt=cc-option

Esta opción toma un argumento que se pasa al compilador para los archivos de origen que se compilan en la configuración de ejecución. Esto es análogo a la opción --copt, pero solo se aplica a la configuración exec.

--host_conlyopt=cc-option

Esta opción toma un argumento que se pasa al compilador para los archivos de origen C que se compilan en la configuración de ejecución. Es análogo a la opción --conlyopt, pero se aplica solo a la configuración de ejecución.

--host_cxxopt=cc-option

Esta opción toma un argumento que se pasará al compilador para los archivos de origen C++ que se compilan en la configuración de ejecución. Esto es análogo a la opción --cxxopt, pero solo se aplica a la configuración exec.

--host_linkopt=linker-option

Esta opción toma un argumento que se debe pasar al vinculador para archivos fuente compilados en la configuración de ejecución. Es análogo a la opción --linkopt, pero se aplica solo a la configuración de ejecución.

--conlyopt=cc-option

Esta opción toma un argumento que se pasa al compilador durante la compilación de archivos de origen C.

Es similar a --copt, pero solo se aplica a la compilación de C, no a la compilación ni la vinculación de C++. Por lo tanto, puedes pasar opciones específicas de C (como -Wno-pointer-sign) mediante --conlyopt.

--cxxopt=cc-option

Esta opción toma un argumento que se pasa al compilador cuando se compilan archivos fuente C++.

Es similar a --copt, pero solo se aplica a la compilación de C++, no a la compilación ni la vinculación de C. Por lo tanto, puedes pasar opciones específicas de C++ (como -fpermissive o -fno-implicit-templates) con --cxxopt.

Por ejemplo:

  % bazel build --cxxopt="-fpermissive" --cxxopt="-Wno-error" //foo/cruddy_code

--linkopt=linker-option

Esta opción toma un argumento que se pasa al compilador durante la vinculación.

Es similar a --copt, pero solo se aplica a la vinculación, no a la compilación. Por lo tanto, puedes pasar opciones del compilador que solo tengan sentido durante la vinculación (como -lssp o -Wl,--wrap,abort) mediante --linkopt. Por ejemplo:

  % bazel build --copt="-fmudflap" --linkopt="-lmudflap" //foo/buggy_code

Las reglas de compilación también pueden especificar opciones de vinculación en sus atributos. La configuración de esta opción siempre tiene prioridad. Consulta también cc_library.linkopts.

--strip (always|never|sometimes)

Esta opción determina si Bazel quitará la información de depuración de todos los objetos binarios y las bibliotecas compartidas mediante la invocación del vinculador con la opción -Wl,--strip-debug. --strip=always siempre significa quitar la información de depuración. --strip=never significa que nunca quitará información de depuración. El valor predeterminado de --strip=sometimes significa quitar si --compilation_mode es fastbuild.

  % bazel build --strip=always //foo:bar

compilará el destino y, al mismo tiempo, quitará la información de depuración de todos los objetos binarios generados.

La opción --strip de Bazel corresponde a la opción --strip-debug de ld: solo quita la información de depuración. Si, por algún motivo, deseas quitar todos los símbolos, no solo los símbolos de depuración, debes usar la opción --strip-all de ld, lo que puedes hacer si pasas --linkopt=-Wl,--strip-all a Bazel. Además, ten en cuenta que configurar la marca --strip de Bazel anulará --linkopt=-Wl,--strip-all, por lo que solo debes establecer una o la otra.

Si solo estás compilando un objeto binario único y quieres quitar todos los símbolos, también puedes pasar --stripopt=--strip-all y compilar de forma explícita la versión //foo:bar.stripped del destino. Como se describe en la sección sobre --stripopt, esto aplica una acción de eliminación después de vincular el objeto binario final, en lugar de incluir la eliminación en todas las acciones de vinculación de la compilación.

--stripopt=strip-option

Esta es una opción adicional para pasar al comando strip cuando se genera un objeto binario *.stripped. El valor predeterminado es -S -p. Esta opción se puede usar varias veces.

--fdo_instrument=profile-output-dir

La opción --fdo_instrument permite generar el resultado del perfil de FDO (optimización dirigida por comentarios) cuando se ejecuta el objeto binario de C/C++ compilado. En el caso de GCC, el argumento proporcionado se usa como prefijo de un directorio del archivo por objeto de archivos .gcda que contiene información de perfil para cada archivo .o.

Una vez que se haya generado el árbol de datos del perfil, este debe comprimirse y proporcionarse a la opción --fdo_optimize=profile-zip de Bazel para habilitar la compilación optimizada para FDO.

Para el compilador de LLVM, el argumento también es el directorio en el que se vuelcan los archivos de datos de perfil de LLVM sin procesar. Por ejemplo: --fdo_instrument=/path/to/rawprof/dir/

No se pueden usar las opciones --fdo_instrument y --fdo_optimize al mismo tiempo.

--fdo_optimize=profile-zip

La opción --fdo_optimize permite usar la información del perfil del archivo por objeto para realizar optimizaciones del FDO (optimización dirigida por comentarios) durante la compilación. En el caso de GCC, el argumento proporcionado es el archivo ZIP que contiene el árbol de archivos generado anteriormente de archivos .gcda que contiene información de perfil de cada archivo .o.

Como alternativa, el argumento proporcionado puede apuntar a un perfil automático identificado por la extensión .afdo.

Para el compilador de LLVM, el argumento proporcionado debe apuntar al archivo de salida del perfil de LLVM indexado que prepara la herramienta llvm-profdata y debe tener una extensión .profdata.

No se pueden usar las opciones --fdo_instrument y --fdo_optimize al mismo tiempo.

--java_language_version=version

Esta opción especifica la versión de las fuentes de Java. Por ejemplo:

  % bazel build --java_language_version=8 java/com/example/common/foo:all

se compila y permite solo construcciones compatibles con la especificación de Java 8. El valor predeterminado es 11. --> Los valores posibles son 8, 9, 10, 11, 14 y 15, y se pueden extender mediante el registro de cadenas de herramientas personalizadas de Java con default_java_toolchain.

--tool_java_language_version=version

Es la versión del lenguaje Java que se usa para compilar herramientas que se ejecutan durante una compilación. El valor predeterminado es 11.

--java_runtime_version=version

Esta opción especifica la versión de JVM que se usará para ejecutar el código y las pruebas. Por ejemplo:

  % bazel run --java_runtime_version=remotejdk_11 java/com/example/common/foo:java_application

descarga JDK 11 desde un repositorio remoto y ejecuta la aplicación de Java con él.

El valor predeterminado es local_jdk. Los valores posibles son local_jdk, local_jdk_version, remotejdk_11 y remotejdk_17. Puedes extender los valores si registras la JVM personalizada con las reglas de repositorio local_java_repository o remote_java_repository.

--tool_java_runtime_version=version

Es la versión de JVM que se usa para ejecutar las herramientas necesarias durante una compilación. El valor predeterminado es remotejdk_11.

--jvmopt=jvm-option

Esta opción permite pasar argumentos a la VM de Java. Se puede usar con un argumento grande o varias veces con argumentos individuales. Por ejemplo:

  % bazel build --jvmopt="-server -Xms256m" java/com/example/common/foo:all

usará la VM del servidor para iniciar todos los objetos binarios de Java y establecerá el tamaño del montón de inicio de la VM en 256 MB.

--javacopt=javac-option

Esta opción permite pasar argumentos correspondientes a javac. Se puede usar con un argumento grande o varias veces con argumentos individuales. Por ejemplo:

  % bazel build --javacopt="-g:source,lines" //myprojects:prog

se volverá a compilar un objeto java_binary con la información de depuración predeterminada de javac (en lugar de hacerlo por el valor predeterminado de Bazel).

La opción se pasa a javac después de las opciones predeterminadas integradas de Bazel para javac y antes de las opciones por regla. Gana la última especificación de cualquier opción para javac. Las opciones predeterminadas para javac son las siguientes:

  -source 8 -target 8 -encoding UTF-8

--strict_java_deps (default|strict|off|warn|error)

Esta opción controla si javac busca dependencias directas faltantes. Los destinos de Java deben declarar de forma explícita todos los destinos utilizados directamente como dependencias. Esta marca le indica a javac que determine los archivos jar que se usan realmente para verificar los tipos de archivo Java y que envíen advertencias o errores si no son el resultado de una dependencia directa del destino actual.

• off significa que la verificación está inhabilitada.
• warn significa que javac generará advertencias de Java estándar del tipo [strict] para cada dependencia directa faltante.
• default, strict y error significan que javac generará errores en lugar de advertencias, lo que provocará que el destino actual no pueda compilar si se encuentran dependencias directas faltantes. Este también es el comportamiento predeterminado cuando no se especifica la marca.

Semántica de compilación

Estas opciones afectan a los comandos de compilación o al contenido del archivo de salida.

--compilation_mode (fastbuild|opt|dbg) (-c)

La opción --compilation_mode (a menudo acortada a -c, en especial -c opt) toma un argumento de fastbuild, dbg o opt, y afecta varias opciones de generación de código C/C++, como el nivel de optimización y la integridad de las tablas de depuración. Bazel usa un directorio de salida diferente para cada modo de compilación, por lo que puedes cambiar entre los modos sin hacer una recompilación completa cada tiempo.

• fastbuild significa que se debe realizar la compilación lo más rápido posible: generar información de depuración mínima (-gmlt -Wl,-S) y no optimizar. Es el valor predeterminado. Nota: -DNDEBUG no se establecerá.
• dbg significa que la compilación está habilitada (-g) para que puedas usar Dalvik (o algún otro depurador).
• opt significa que la compilación está habilitada y con las llamadas assert() inhabilitadas (-O2 -DNDEBUG). La información de depuración no se generará en el modo opt, a menos que también pases --copt -g.

--cpu=cpu

Esta opción especifica la arquitectura de CPU de destino que se usará para la compilación de objetos binarios durante la compilación.

--action_env=VAR=VALUE

Especifica el conjunto de variables de entorno disponibles durante la ejecución de todas las acciones. Las variables se pueden especificar por nombre, en cuyo caso el valor se tomará del entorno de invocación o por el par name=value que establece el valor independientemente del entorno de invocación.

Esta marca --action_env se puede especificar varias veces. Si se asigna un valor a la misma variable en varias marcas --action_env, ganará la última asignación.

--experimental_action_listener=label

La opción experimental_action_listener le indica a Bazel que use detalles de la regla action_listener especificada por label para insertar extra_actions en el gráfico de compilación.

--[no]experimental_extra_action_top_level_only

Si esta opción se configura como verdadera, las acciones adicionales especificadas por la opción de línea de comandos --experimental_action_listener solo se programarán para objetivos de nivel superior.

--experimental_extra_action_filter=regex

La opción experimental_extra_action_filter le indica a Bazel que filtre el conjunto de destinos para programar extra_actions.

Esta marca solo se aplica en combinación con la marca --experimental_action_listener.

De forma predeterminada, se programa la ejecución de todos los extra_actions en el cierre transitivo de los destinos de compilación solicitados. --experimental_extra_action_filter restringirá la programación a extra_actions, cuya etiqueta del propietario coincida con la expresión regular especificada.

En el siguiente ejemplo, se limitará la programación de extra_actions para que solo se aplique a las acciones de las que la etiqueta del propietario contenga “/bar/”:

% bazel build --experimental_action_listener=//test:al //foo/... \
  --experimental_extra_action_filter=.*/bar/.*

--host_cpu=cpu

Esta opción especifica el nombre de la arquitectura de CPU que se debe usar para compilar herramientas de host.

--fat_apk_cpu=cpu[,cpu]*

Las CPU para compilar bibliotecas C/C++ en el deps transitivo de las reglas android_binary. Las demás reglas de C/C++ no se ven afectadas. Por ejemplo, si aparece un cc_library en el deps transitivo de una regla de android_binary y una de cc_binary, se compilará cc_library al menos dos veces: una para cada CPU especificada con --fat_apk_cpu para la regla de android_binary y otra para la CPU especificada con --cpu para la regla de cc_binary.

El valor predeterminado es armeabi-v7a.

Se crea y empaqueta un archivo .so en el APK para cada CPU especificada con --fat_apk_cpu. El nombre del archivo .so agrega el prefijo "lib" al nombre de la regla android_binary. Por ejemplo, si el nombre de la android_binary es "foo", el archivo es libfoo.so.

--per_file_copt=[+-]regex[,[+-]regex]...@option[,option]...

Cuando está presente, cualquier archivo de C++ con una etiqueta o ruta de ejecución que coincida con una de las expresiones regex de inclusión y que no coincida con ninguna de las expresiones de exclusión se compilará con las opciones determinadas. La coincidencia de etiquetas usa el formato canónico de la etiqueta (es decir, //package:label_name).

La ruta de ejecución es la ruta relativa a tu directorio de lugar de trabajo, que incluye el nombre base (incluida la extensión) del archivo C++. También incluye los prefijos que dependen de la plataforma.

Para que coincida con los archivos generados (como los resultados de genrule), Bazel solo puede usar la ruta de ejecución. En este caso, la regexp no debe comenzar con “//”, ya que no coincide con ninguna ruta de ejecución. Los nombres de paquetes se pueden usar de la siguiente manera: --per_file_copt=base/.*\.pb\.cc@-g0. Esto coincidirá con cada archivo .pb.cc de un directorio llamado base.

Esta opción se puede usar varias veces.

La opción se aplica independientemente del modo de compilación que se utilice. Por ejemplo, es posible compilar con --compilation_mode=opt y compilar de manera selectiva algunos archivos con la optimización más segura activada o con la optimización inhabilitada.

Advertencia: Si algunos archivos se compilan de forma selectiva con símbolos de depuración, es posible que los símbolos se quiten durante la vinculación. Para evitarlo, se debe configurar --strip=never.

Sintaxis: [+-]regex[,[+-]regex]...@option[,option].... En este caso, regex significa una expresión regular que puede tener el prefijo + para identificar patrones de inclusión, y - para identificar patrones de exclusión. option significa una opción arbitraria que se pasa al compilador de C++. Si una opción contiene un ,, se debe citar de este modo: \,. Las opciones también pueden contener @, ya que solo se usa el primer @ para separar las expresiones regulares de las opciones.

Ejemplo: --per_file_copt=//foo:.*\.cc,-//foo:file\.cc@-O0,-fprofile-arcs agrega las opciones -O0 y -fprofile-arcs a la línea de comandos del compilador de C++ para todos los archivos .cc en //foo/, excepto file.cc.

--dynamic_mode=mode

Determina si los objetos binarios de C++ se vincularán de manera dinámica y se interactuará con el atributo linkstatic en las reglas de compilación.

Modos:

• auto: Se traduce a un modo que depende de la plataforma, default para Linux y off para cygwin.
• default: Permite que Bazel elija si desea vincular de forma dinámica. Consulta linkstatic para obtener más información.
• fully: Vincula de forma dinámica todos los destinos. Esto acelerará el tiempo de vinculación y reducirá el tamaño de los objetos binarios resultantes.
• off: Vincula todos los destinos en modo mayormente estático. Si -static está configurado en adopts de vinculación, los objetivos cambiarán a totalmente estáticos.

--fission (yes|no|[dbg][,opt][,fastbuild])

Habilita Fission, que escribe la información de depuración de C++ en archivos .dwo dedicados, en lugar de archivos .o, donde, de lo contrario, se reduciría. Esto reduce de manera sustancial el tamaño de la entrada a los vínculos y puede reducir los tiempos de los vínculos.

Cuando se establece en [dbg][,opt][,fastbuild] (ejemplo: --fission=dbg,fastbuild), Fission se habilita solo para el conjunto especificado de modos de compilación. Esto es útil para la configuración de Bazelrc. Cuando se establece en yes, Fission se habilita de forma universal. Cuando se configura en no, Fission se inhabilita de forma universal. La cantidad predeterminada es no.

--force_ignore_dash_static

Si se establece esta marca, se ignoran todas las opciones -static en adopts de reglas cc_* de BUILD. Esto solo está pensado como una solución alternativa para las compilaciones de endurecimiento de C++.

--[no]force_pic

Si se habilita, todas las compilaciones de C++ producen código independiente de posición ("-fPIC"), los vínculos prefieren bibliotecas compiladas previamente de PIC por sobre las bibliotecas que no son de PIC, y los vínculos producen ejecutables independientes de la posición ("-pie"). La opción predeterminada está inhabilitada.

--android_resource_shrinking

Selecciona si se debe reducir los recursos para las reglas de android_binary. Establece el valor predeterminado del atributo shrink_resources en las reglas android_binary. Consulta la documentación de esa regla para obtener más detalles. La configuración predeterminada es desactivada.

--custom_malloc=malloc-library-target

Cuando se especifique, siempre usa la implementación de malloc determinada y anula todos los atributos malloc="target", incluidos los que usan el valor predeterminado (sin especificar malloc).

--crosstool_top=label

Esta opción especifica la ubicación del conjunto de compiladores de Crosstool que se usará en toda la compilación de C++ durante una compilación. En esa ubicación, Bazel buscará un archivo CROSSTOOL y lo usará para determinar automáticamente la configuración de --compiler.

--host_crosstool_top=label

Si no se especifica, Bazel usa el valor de --crosstool_top para compilar código en la configuración de ejecución, como las herramientas que se ejecutan durante la compilación. El propósito principal de esta marca es habilitar la compilación cruzada.

--apple_crosstool_top=label

La herramienta cruzada que se usará para compilar reglas C/C++ en el deps transitivo de las reglas objc*, ios* y apple*. Para esos destinos, esta marca reemplaza --crosstool_top.

--android_crosstool_top=label

La herramienta cruzada que se usará para compilar reglas C/C++ en el deps transitivo de las reglas android_binary. Esto es útil si otros destinos de la compilación requieren una herramienta cruzada diferente. La configuración predeterminada es usar la herramienta cruzada generada por la regla android_ndk_repository en el archivo WORKSPACE. Consulta también --fat_apk_cpu.

--compiler=version

Esta opción especifica la versión del compilador C/C++ (como gcc-4.1.0) que se usará para la compilación de objetos binarios durante la compilación. Si deseas compilar con una herramienta cruzada personalizada, debes usar un archivo CROSSTOOL en lugar de especificar esta marca.

--android_sdk=label

Esta opción especifica la cadena de herramientas del SDK o la plataforma de Android y la biblioteca del entorno de ejecución de Android que se usará para compilar cualquier regla relacionada con Android.

El SDK de Android se seleccionará automáticamente si se define una regla android_sdk_repository en el archivo WORKSPACE.

--java_toolchain=label

Esta opción especifica la etiqueta de java_toolchain que se usa para compilar archivos fuente de Java.

--host_java_toolchain=label

Si no se especifica, Bazel usa el valor de --java_toolchain para compilar código en la configuración de ejecución, como en el caso de las herramientas que se ejecutan durante la compilación. El propósito principal de esta marca es habilitar la compilación cruzada.

--javabase=(label)

Esta opción establece la etiqueta de la instalación de Java base que se usará para la ejecución de bazel, la prueba de Bazel y los objetos binarios de Java compilados por las reglas java_binary y java_test. Las variables “Make” de JAVABASE y JAVA derivan de esta opción.

--host_javabase=label

Esta opción establece la etiqueta de la instalación de Java base que se usará en la configuración de ejecución, por ejemplo, para las herramientas de compilación de host, incluidas JavaBuilder y Singlejar.

No se selecciona el compilador de Java que se usa para compilar los archivos fuente de Java. Puedes seleccionar el compilador configurando la opción --java_toolchain.

Estrategia de ejecución

Estas opciones afectan la forma en que Bazel ejecutará la compilación. No deberían tener ningún efecto significativo en los archivos de salida que genera la compilación. Por lo general, su efecto principal es la velocidad de la compilación.

--spawn_strategy=strategy

Esta opción controla dónde y cómo se ejecutan los comandos.

• standalone hace que los comandos se ejecuten como subprocesos locales. Este valor es obsoleto. Utilice local en su lugar.
• sandboxed hace que los comandos se ejecuten dentro de una zona de pruebas en la máquina local. Esto requiere que todos los archivos de entrada, las dependencias de datos y las herramientas se muestren como dependencias directas en los atributos srcs, data y tools. Bazel habilita la zona de pruebas local de forma predeterminada en sistemas que admiten la ejecución de la zona de pruebas.
• local hace que los comandos se ejecuten como subprocesos locales.
• worker hace que los comandos se ejecuten con un trabajador persistente, si está disponible.
• docker hace que los comandos se ejecuten dentro de una zona de pruebas de Docker en la máquina local. Esto requiere que Docker esté instalado.
• remote hace que los comandos se ejecuten de forma remota. Esto solo está disponible si un ejecutor remoto se configuró por separado.

--strategy mnemonic=strategy

Esta opción controla dónde y cómo se ejecutan los comandos, y anula --spawn_strategy (y --genrule_strategy con mnemonic Genrule) por nemotécnica. Consulta --spawn_Strategy para conocer las estrategias admitidas y sus efectos.

--strategy_regexp=<filter,filter,...>=<strategy>

Esta opción especifica qué estrategia debe usarse para ejecutar comandos que tienen descripciones que coinciden con un regex_filter determinado. Consulta --per_file_copt para obtener detalles sobre la coincidencia de regex_filter. Consulta --spawn_Strategy para conocer las estrategias admitidas y sus efectos.

Se utiliza el último elemento regex_filter que coincide con la descripción. Esta opción anula otras marcas para especificar la estrategia.

• Ejemplo: --strategy_regexp=//foo.*\\.cc,-//foo/bar=local significa ejecutar acciones con la estrategia local si sus descripciones coinciden con //foo.*.cc, pero no con //foo/bar.
• Ejemplo: --strategy_regexp='Compiling.*/bar=local' --strategy_regexp=Compiling=sandboxed ejecuta "Compile //foo/bar/baz" con la estrategia sandboxed, pero se revierte el orden con ejecución con local.
• Ejemplo: --strategy_regexp='Compiling.*/bar=local,sandboxed' ejecuta “Compilación de //foo/bar/baz” con la estrategia local y recurre a sandboxed si falla.

--genrule_strategy=strategy

Esta es una abreviatura obsoleta para --strategy=Genrule=strategy.

--jobs=n (-j)

Esta opción, que toma un argumento de número entero, especifica un límite para la cantidad de trabajos que se deben ejecutar de forma simultánea durante la fase de ejecución de la compilación.

--progress_report_interval=n

Bazel imprime de forma periódica un informe de progreso sobre los trabajos que aún no han terminado (como las pruebas de larga duración). Esta opción establece la frecuencia de los informes, y el progreso se imprimirá cada n segundos.

El valor predeterminado es 0, lo que significa un algoritmo incremental: el primer informe se imprimirá después de 10 segundos, luego, 30 segundos y, luego, ese progreso se informará una vez por minuto.

Cuando Bazel usa el control del cursor, como se especifica en --curses, el progreso se informa cada segundo.

--local_{ram,cpu}_resources resources or resource expression

Estas opciones especifican la cantidad de recursos locales (RAM en MB y cantidad de núcleos lógicos de CPU) que Bazel puede tener en cuenta cuando programa actividades de compilación y de prueba para que se ejecuten de forma local. Toman un número entero o una palabra clave (HOST_RAM o HOST_CPUS) seguidas de forma opcional por [-|*float] (por ejemplo, --local_cpu_resources=2, --local_ram_resources=HOST_RAM*.5, --local_cpu_resources=HOST_CPUS-1). Las marcas son independientes; se pueden establecer una o ambas. De forma predeterminada, Bazel estima la cantidad de RAM y la cantidad de núcleos de CPU directamente desde la configuración del sistema local.

--[no]build_runfile_links

Esta opción, que está habilitada de forma predeterminada, especifica si los symlinks de runfiles para pruebas y objetos binarios se deben compilar en el directorio de salida. El uso de --nobuild_runfile_links puede ser útil para validar si todos los destinos se compilan sin incurrir en la sobrecarga de compilar los árboles de archivos de ejecución.

Cuando se ejecutan pruebas (o aplicaciones), sus dependencias de datos de tiempo de ejecución se juntan en un solo lugar. Dentro del árbol de salida de Bazel, este árbol de “runfiles” suele tener permisos de administrador en el mismo nivel que el objeto binario o la prueba correspondiente. Durante la ejecución de prueba, se puede acceder a los runfiles mediante rutas con el formato $TEST_SRCDIR/workspace/packagename/filename. El árbol de runfiles garantiza que las pruebas tengan acceso a todos los archivos de los que tienen una dependencia declarada, y nada más. De forma predeterminada, el árbol de runfiles se implementa mediante la construcción de un conjunto de vínculos simbólicos a los archivos requeridos. A medida que crece el conjunto de vínculos, también lo hace el costo de esta operación. En el caso de algunas compilaciones grandes, puede contribuir considerablemente al tiempo de compilación general, en particular porque cada prueba (o aplicación) requiere su propio árbol de runfiles.

--[no]build_runfile_manifests

Esta opción, que está habilitada de forma predeterminada, especifica si los manifiestos de archivos de ejecución deben escribirse en el árbol de resultados. Si la inhabilitas, esto implica --nobuild_runfile_links.

Se puede inhabilitar cuando se ejecutan pruebas de forma remota, ya que los árboles de runfiles se crearán de forma remota desde los manifiestos en la memoria.

--[no]discard_analysis_cache

Cuando se habilite esta opción, Bazel descartará la caché de análisis justo antes de que comience la ejecución, lo que liberará memoria adicional (alrededor del 10%) para la fase de ejecución. La desventaja es que las compilaciones incrementales adicionales serán más lentas. Consulta también el modo de ahorro de memoria.

--[no]keep_going (-k)

Al igual que en GNU Make, la fase de ejecución de una compilación se detiene cuando se encuentra el primer error. A veces, es útil intentar compilar tanto como sea posible, incluso frente a errores. Esta opción habilita ese comportamiento. Cuando se especifique, la compilación intentará compilar cada destino cuyos requisitos previos se hayan compilado correctamente, pero ignorará los errores.

Si bien esta opción suele asociarse con la fase de ejecución de una compilación, también afecta la fase de análisis: si se especifican varios destinos en un comando de compilación, pero solo algunos de ellos se pueden analizar de forma correcta, la compilación se detendrá con un error, a menos que se especifique --keep_going, en cuyo caso la compilación continuará en la fase de ejecución, pero solo para los destinos que se analizaron con éxito.

--[no]use_ijars

Esta opción cambia la forma en que Bazel compila los destinos java_library. En lugar de usar la salida de un java_library para compilar destinos java_library dependientes, Bazel creará archivos jar de interfaz que contienen solo las firmas de miembros y campos de acceso (públicos, protegidos y predeterminados (paquete)) y usará los jar de interfaz para compilar los destinos dependientes. Esto permite evitar la recompilación cuando los cambios solo se realizan en los métodos o los miembros privados de una clase.

--[no]interface_shared_objects

Esta opción habilita la interfaz de objetos compartidos, lo que hace que los objetos binarios y otras bibliotecas compartidas dependan de la interfaz de un objeto compartido, en lugar de su implementación. Cuando solo cambia la implementación, Bazel puede evitar volver a compilar destinos que dependan innecesariamente de la biblioteca compartida cambiada.

Selección de salida

Estas opciones determinan qué compilar o probar.

--[no]build

Esta opción hace que ocurra la fase de ejecución de la compilación; esta opción está activada de forma predeterminada. Cuando está desactivada, se omite la fase de ejecución y solo ocurren las dos primeras fases, carga y análisis.

Esta opción puede ser útil para validar archivos BUILD y detectar errores en las entradas, sin compilar nada.

--[no]build_tests_only

Si se especifica, Bazel compilará solo lo necesario para ejecutar las reglas *_test y test_suite que no se filtraron debido a su tamaño, tiempo de espera, etiqueta o idioma. Si se especifica, Bazel ignorará los demás destinos especificados en la línea de comandos. De forma predeterminada, esta opción está inhabilitada y Bazel compilará todo lo solicitado, incluidas las reglas *_test y test_suite que se filtran de las pruebas. Esto es útil porque es posible que la ejecución de bazel test --build_tests_only foo/... no detecte todas las fallas de compilación en el árbol foo.

--[no]check_up_to_date

Esta opción hace que Bazel no realice una compilación, sino que verifique si todos los destinos especificados están actualizados. Si es así, la compilación se completa correctamente, como de costumbre. Sin embargo, si algún archivo está desactualizado, en lugar de compilarse, se informará un error y la compilación fallará. Esta opción puede ser útil para determinar si una compilación se realizó más recientemente que una edición de origen (por ejemplo, para verificaciones de envío previo) sin incurrir en el costo de una compilación.

Consulta también --check_tests_up_to_date.

--[no]compile_one_dependency

Compila una sola dependencia de los archivos de argumento. Esto es útil para verificar la fuente de los archivos de sintaxis en IDE, por ejemplo, mediante la compilación de un solo destino que depende del archivo de origen a fin de detectar errores lo antes posible en el ciclo de edición, compilación y prueba. Este argumento afecta la forma en la que se interpretan todos los argumentos que no son de marcas: cada argumento debe ser una etiqueta de destino del archivo o un nombre de archivo sin formato en relación con el directorio de trabajo actual, y una regla que depende de cada nombre de archivo de origen está compilado. Para las fuentes de C++ y Java, se prefieren las reglas en el mismo espacio de lenguaje. Para varias reglas con la misma preferencia, se elige la que aparezca primero en el archivo BUILD. Un patrón de destino explícitamente nombrado que no hace referencia a un archivo de origen genera un error.

--save_temps

La opción --save_temps hace que se guarden resultados temporales del compilador. Estos incluyen archivos .s (código ensamblador), archivos .i (C preprocesados) y .ii (C++ procesados previamente). Estos resultados suelen ser útiles para la depuración. Las temperaturas solo se generarán para el conjunto de destinos especificado en la línea de comandos.

Actualmente, la marca --save_temps solo funciona para reglas de cc_*.

Para asegurarte de que Bazel imprima la ubicación de los archivos de salida adicionales, comprueba que tu configuración de --show_result n sea lo suficientemente alta.

--build_tag_filters=tag[,tag]*

Si se especifica, Bazel solo compilará destinos que tengan al menos una etiqueta obligatoria (si se especifica alguna) y no tiene etiquetas excluidas. El filtro de etiqueta de compilación se especifica como una lista de palabras clave de la etiqueta delimitada por comas, opcionalmente precedida por el signo “-” que se usa para denotar las etiquetas excluidas. Las etiquetas obligatorias también pueden tener un signo "+" precedente.

Cuando se ejecutan pruebas, Bazel ignora --build_tag_filters para los destinos de prueba, que se compilan y se ejecutan incluso si no coinciden con este filtro. Para evitar compilarlas, filtra los destinos de prueba con --test_tag_filters o exclúyelos de forma explícita.

--test_size_filters=size[,size]*

Si se especifica, Bazel probará (o compilará si también se especifica --build_tests_only) destinos de prueba con el tamaño determinado. El filtro de tamaño de la prueba se especifica como una lista delimitada por comas de valores de tamaño de prueba permitidos (pequeño, mediano, grande o enorme), opcionalmente precedidos por el signo “-” que se usa para denotar los tamaños de prueba excluidos. Por ejemplo,

  % bazel test --test_size_filters=small,medium //foo:all

y

  % bazel test --test_size_filters=-large,-enormous //foo:all

solo probará pruebas pequeñas y medianas dentro de //foo.

De forma predeterminada, no se aplica el filtro de tamaño de prueba.

--test_timeout_filters=timeout[,timeout]*

Si se especifica, Bazel probará (o compilará si también se especifica --build_tests_only) solo los destinos de prueba con el tiempo de espera determinado. El filtro de tiempo de espera de prueba se especifica como una lista delimitada por comas de valores de tiempo de espera de prueba permitidos (corto, moderado, largo o eterno), opcionalmente precedido por el signo "-" que se usa para denotar los tiempos de espera de prueba excluidos. Consulta --test_size_filters para ver la sintaxis de ejemplo.

De forma predeterminada, no se aplica el filtro de tiempo de espera de la prueba.

--test_tag_filters=tag[,tag]*

Si se especifica, Bazel probará (o compilará si también se especifica --build_tests_only) solo los destinos de prueba que tengan al menos una etiqueta obligatoria (si se especifica alguna) y no tenga etiquetas excluidas. El filtro de etiqueta de prueba se especifica como una lista de palabras clave de la etiqueta delimitada por comas, opcionalmente precedida por el signo “-” que se usa para denotar las etiquetas excluidas. Las etiquetas obligatorias también pueden tener un signo "+" precedente.

Por ejemplo,

  % bazel test --test_tag_filters=performance,stress,-flaky //myproject:all

Se probarán los destinos etiquetados con las etiquetas performance o stress, pero no con la etiqueta flaky.

De forma predeterminada, no se aplica el filtro de etiquetas de prueba. Ten en cuenta que también puedes filtrar según las etiquetas size y local de la prueba.

--test_lang_filters=string[,string]*

Especifica una lista de strings separadas por comas que hacen referencia a nombres de clases de reglas de prueba. Para hacer referencia a la clase de regla foo_test, usa la string "foo". Bazel probará (o compilará si también se especifica --build_tests_only) solo destinos de las clases de reglas a las que se hace referencia. Para excluir esos destinos, usa la string "-foo". Por ejemplo,

  % bazel test --test_lang_filters=foo,bar //baz/...

solo probará los destinos que sean instancias de foo_test o bar_test en //baz/..., mientras que

  % bazel test --test_lang_filters=-foo,-bar //baz/...

probará todos los destinos en //baz/..., excepto las instancias foo_test y bar_test.

--test_filter=filter-expression

Especifica un filtro que el ejecutor de pruebas puede usar con el fin de elegir un subconjunto de pruebas para ejecutar. Se compilan todos los destinos especificados en la invocación, pero, según la expresión, solo se pueden ejecutar algunos de ellos; en algunos casos, solo se ejecutan ciertos métodos de prueba.

La interpretación particular de filter-expression depende del framework de prueba responsable de ejecutar la prueba. Puede ser glob, substring o regexp. --test_filter es conveniente cuando se pasan diferentes argumentos de filtro --test_arg, pero no todos los frameworks lo admiten.

Verbosidad

Estas opciones controlan la verbosidad de los resultados de Bazel, ya sea en la terminal o en archivos de registro adicionales.

--explain=logfile

Esta opción, que requiere un argumento de nombre de archivo, hace que el verificador de dependencias en la fase de ejecución de bazel build explique por cada paso de compilación, por qué se está ejecutando o por que esté actualizado. La explicación se escribe en logfile.

Si te encuentras con recompilaciones inesperadas, esta opción puede ayudarte a comprender el motivo. Agrégalo a tu .bazelrc para que el registro ocurra en todas las compilaciones posteriores y, luego, inspecciona el registro cuando veas un paso de ejecución ejecutado de forma inesperada. Esta opción puede conllevar una pequeña penalización de rendimiento, por lo que te recomendamos quitarla cuando ya no sea necesaria.

--verbose_explanations

Esta opción aumenta la verbosidad de las explicaciones generadas cuando se habilita la opción --explain.

En particular, si están habilitadas las explicaciones detalladas y se vuelve a compilar un archivo de salida porque cambió el comando que se usó para compilarlo, el resultado del archivo de explicación incluirá los detalles completos del comando nuevo (al menos para la mayoría de los comandos).

El uso de esta opción puede aumentar significativamente la longitud del archivo de explicación generado y la penalización de rendimiento de usar --explain.

Si --explain no está habilitado, --verbose_explanations no tiene efecto.

--profile=file

Esta opción, que toma un argumento de nombre de archivo, hace que Bazel escriba datos de generación de perfiles en un archivo. Luego, los datos se pueden analizar o analizar con el comando bazel analyze-profile. El perfil de compilación puede ser útil para comprender la instancia del comando build de Bazel.

--[no]show_loading_progress

Esta opción hace que Bazel muestre mensajes de progreso de carga de paquetes. Si la inhabilitas, no se mostrarán los mensajes.

--[no]show_progress

Esta opción hace que se muestren los mensajes de progreso; está activada de forma predeterminada. Cuando se inhabilita, se suprimen los mensajes de progreso.

--show_progress_rate_limit=n

Esta opción hace que Bazel muestre como máximo un mensaje de progreso por n segundos, en el que n es un número real. El valor predeterminado de esta opción es 0.02, lo que significa que Bazel limitará los mensajes de progreso a uno por cada 0.02 segundos.

--show_result=n

Esta opción controla la impresión de la información del resultado al final de un comando bazel build. De forma predeterminada, si se especificó un solo destino de compilación, Bazel imprime un mensaje que indica si se actualizó correctamente el destino y, de ser así, la lista de archivos de salida que creó el destino. Si se especificaron varios objetivos, no se muestra la información del resultado.

Si bien la información del resultado puede ser útil para las compilaciones de un solo objetivo o de unos pocos, en el caso de compilaciones grandes (como un árbol de proyecto de nivel superior completo), esta información puede ser abrumadora y distractor; esta opción permite controlarla. --show_result toma un argumento de número entero, que es la cantidad máxima de destinos para los que se debe imprimir la información de resultado completo. De forma predeterminada, el valor es 1. Por encima de este umbral, no se muestra información de resultados para destinos individuales. Por lo tanto, cero hace que la información del resultado siempre se suprima, y un valor muy grande hace que el resultado se imprima siempre.

Es posible que los usuarios deseen elegir un valor intermedio si alternan de forma regular entre un grupo pequeño de destinos (por ejemplo, durante el ciclo de compilación, edición y prueba) y un grupo grande de destinos (por ejemplo, cuando establecen un lugar de trabajo nuevo o ejecutan pruebas de regresión). En el primer caso, la información del resultado es muy útil, mientras que, en el segundo, es menos. Al igual que con todas las opciones, esto se puede especificar de forma implícita mediante el archivo .bazelrc.

Los archivos se imprimen para que sea más fácil copiar y pegar el nombre del archivo en la shell, y ejecutar los ejecutables compilados. Los mensajes “actualizados” o “con errores” de cada destino se pueden analizar fácilmente mediante secuencias de comandos que generan una compilación.

--sandbox_debug

Esta opción hace que Bazel imprima información de depuración adicional cuando use la zona de pruebas para la ejecución de acciones. Esta opción también conserva los directorios de zona de pruebas, de manera que se puedan examinar los archivos visibles para las acciones durante la ejecución.

--subcommands (-s)

Esta opción hace que la fase de ejecución de Bazel imprima la línea de comandos completa para cada comando antes de ejecutarla.

  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
  (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
    exec env - \
    /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)

Siempre que sea posible, los comandos se imprimen en una sintaxis de shell compatible con Bourne, de modo que se puedan copiar y pegar con facilidad en un símbolo del sistema de shell. (Los paréntesis circundantes se proporcionan para proteger tu shell de las llamadas cd y exec; asegúrate de copiarlos). Sin embargo, algunos comandos se implementan de forma interna en Bazel, como la creación de árboles de symlink. En esos casos, no hay una línea de comandos para mostrar.

Se puede pasar --subcommands=pretty_print para imprimir los argumentos del comando como una lista en lugar de como una sola línea. Esto puede ayudar a que las líneas de comandos largas sean más legibles.

Consulta también --verbose_failures a continuación.

Si deseas registrar subcomandos en un archivo en un formato compatible con herramientas, consulta --execution_log_json_file y --execution_log_binary_file.

--verbose_failures

Esta opción hace que la fase de ejecución de Bazel imprima la línea de comandos completa para los comandos que fallaron. Esto puede ser muy valioso para depurar una compilación que falla.

Los comandos con errores se imprimen en una sintaxis compatible con la shell Bourne, adecuada para copiar y pegar en un símbolo del sistema de shell.

Estado del lugar de trabajo

Usa estas opciones para "sellar" los objetos binarios compilados en Bazel: a fin de incorporar información adicional en los objetos binarios, como la revisión del control de origen o alguna otra información relacionada con el lugar de trabajo. Puedes usar este mecanismo con reglas que admitan el atributo stamp, como genrule, cc_binary y muchas más.

--workspace_status_command=program

Esta marca te permite especificar un objeto binario que Bazel ejecuta antes de cada compilación. El programa puede informar información sobre el estado del lugar de trabajo, como la revisión del control de fuente actual.

El valor de la marca debe ser una ruta a un programa nativo. En Linux o macOS, puede ser cualquier archivo ejecutable. En Windows, debe ser un objeto binario nativo, generalmente un archivo ".exe", ".bat" o ".cmd".

El programa debe imprimir cero o más pares clave-valor en la salida estándar, una entrada en cada línea y, luego, salir con cero (de lo contrario, la compilación falla). Los nombres de las claves pueden ser de cualquier tipo, pero solo pueden usar letras mayúsculas y guiones bajos. El primer espacio después del nombre de la clave lo separa del valor. El valor es el resto de la línea (incluidos los espacios en blanco adicionales). Ni la clave ni el valor pueden abarcar varias líneas. Las claves no deben estar duplicadas.

Bazel divide las claves en dos buckets: “stable” y “volatile”. (Los nombres "estable" y "volátil" son un poco contradictorios, así que no los pienses demasiado).

Luego, Bazel escribe los pares clave-valor en dos archivos:

• bazel-out/stable-status.txt contiene todas las claves y los valores en los que el nombre de la clave comienza con STABLE_.
• bazel-out/volatile-status.txt contiene el resto de las claves y sus valores.

El contrato es el siguiente:

• Los valores de las claves "estables" deberían cambiar rara vez, si es posible. Si cambia el contenido de bazel-out/stable-status.txt, Bazel invalida las acciones que dependen de ellos. En otras palabras, si cambia el valor de una clave estable, Bazel volverá a ejecutar acciones selladas. Por lo tanto, el estado estable no debe contener elementos como marcas de tiempo, ya que cambian todo el tiempo y hacen que Bazel vuelva a ejecutar acciones selladas con cada compilación.

  Bazel siempre genera las siguientes claves estables:

  • BUILD_EMBED_LABEL: valor de --embed_label
  • BUILD_HOST: Es el nombre de la máquina anfitrión en la que se ejecuta Bazel.
  • BUILD_USER: Es el nombre del usuario que ejecuta Bazel.

• Los valores de las claves "volátiles" pueden cambiar con frecuencia. Bazel espera que cambien todo el tiempo, como lo hacen las marcas de tiempo, y actualiza debidamente el archivo bazel-out/volatile-status.txt. Sin embargo, para evitar volver a ejecutar acciones selladas todo el tiempo, Bazel finge que el archivo volátil nunca cambia. En otras palabras, si el archivo de estado volátil es el único que cambia su contenido, Bazel no invalidará las acciones que dependan de él. Si cambiaron otras entradas de las acciones, Bazel vuelve a ejecutar esa acción, y la acción verá el estado volátil actualizado, pero el cambio de estado volátil solo no la invalidará.

  Bazel siempre genera las siguientes claves volátiles:

  • BUILD_TIMESTAMP: Es el tiempo de la compilación en segundos desde la época Unix (el valor de System.currentTimeMillis() dividido por mil).
  • FORMATTED_DATE: Es la hora de la compilación con formato yyyy MMM d HH mm ss EEE(por ejemplo, 2023 de junio de 2001, 44, 29 vie) en UTC.

En Linux o macOS, puedes pasar --workspace_status_command=/bin/true para inhabilitar la recuperación del estado del lugar de trabajo, porque true no hace nada, se realiza de forma correcta (sale con cero) y no imprime resultados. En Windows, puedes pasar la ruta de acceso de true.exe de MSYS para el mismo efecto.

Si el comando de estado del lugar de trabajo falla (se cierra fuera de cero) por cualquier motivo, la compilación fallará.

Programa de ejemplo en Linux con Git:

#!/bin/bash
echo "CURRENT_TIME $(date +%s)"
echo "RANDOM_HASH $(cat /proc/sys/kernel/random/uuid)"
echo "STABLE_GIT_COMMIT $(git rev-parse HEAD)"
echo "STABLE_USER_NAME $USER"

Pasa la ruta de este programa con --workspace_status_command, y el archivo de estado estable incluirá las líneas STABLE y el archivo de estado volátil incluirá el resto de las líneas.

--[no]stamp

Esta opción, junto con el atributo de regla stamp, controla si se debe incorporar información de compilación en objetos binarios.

Se puede habilitar o inhabilitar el sello de manera explícita por regla mediante el atributo stamp. Consulta la Enciclopedia de compilación para obtener más información. Cuando una regla establece stamp = -1 (el valor predeterminado para las reglas de *_binary), esta opción determina si los sellos están habilitados.

Bazel nunca sella objetos binarios compilados para la configuración de ejecución, independientemente de esta opción o el atributo stamp. En las reglas que establecen stamp = 0 (el valor predeterminado para las reglas de *_test), el sello está inhabilitado independientemente de la --[no]stamp. Especificar --stamp no obliga a volver a compilar los destinos si sus dependencias no cambiaron.

Por lo general, se recomienda configurar --nostamp para el rendimiento de la compilación, ya que reduce la volatilidad de entrada y maximiza el almacenamiento en caché de la compilación.

Plataforma

Usa estas opciones a fin de controlar las plataformas de host y de destino que configuran el funcionamiento de las compilaciones, y para controlar qué plataformas de ejecución y cadenas de herramientas están disponibles para las reglas de Bazel.

Consulta la información general sobre plataformas y cadenas de herramientas.

--platforms=labels

Las etiquetas de las reglas de la plataforma que describen las plataformas de destino para el comando actual.

--host_platform=label

La etiqueta de una regla de plataforma que describe el sistema host.

--extra_execution_platforms=labels

Son las plataformas que están disponibles como plataformas de ejecución para ejecutar acciones. Las plataformas se pueden especificar por objetivo exacto o como patrón de destino. register_execution_platforms() considerará las plataformas antes de declararlas en el archivo WORKSPACE. Esta opción acepta una lista de plataformas separadas por comas en orden de prioridad. Si la marca se pasa varias veces, las anulaciones más recientes

--extra_toolchains=labels

Son las reglas que se deben considerar durante la resolución de la cadena de herramientas. Las cadenas de herramientas se pueden especificar por objetivo exacto o como patrón de destino. Las cadenas de herramientas se considerarán antes que las declaradas en el archivo WORKSPACE con register_toolchains().

--toolchain_resolution_debug=regex

Imprime información de depuración mientras se encuentran cadenas de herramientas si el tipo de cadena de herramientas coincide con la regex. Si hay varias regex, se pueden separar con comas. La regex se puede negar mediante un - al principio. Esto podría ayudar a los desarrolladores de reglas de Bazel o Starlark con fallas de depuración debido a la falta de cadenas de herramientas.

Varios

--flag_alias=alias_name=target_path

Marca de conveniencia usada para vincular la configuración de compilación de Starlark más larga con un nombre más corto. Para obtener más información, consulta la configuración de Starlark.

--symlink_prefix=string

Cambia el prefijo de los symlinks generados y convenientes. El valor predeterminado del prefijo del symlink es bazel-, lo que creará los symlinks bazel-bin, bazel-testlogs y bazel-genfiles.

Si, por algún motivo, no se pueden crear vínculos simbólicos, se emite una advertencia, pero la compilación se considera exitosa. En particular, esto te permite compilar en un directorio de solo lectura o en uno en el que no tienes permiso para escribir. Las rutas de acceso impresas en mensajes informativos al finalizar una compilación solo usarán el formato corto relativo de symlinks si los symlinks apuntan a la ubicación esperada; en otras palabras, puedes confiar en la precisión de esas rutas, incluso si no puedes confiar en que se creen los symlinks.

Estos son algunos valores comunes de esta opción:

• Suprime la creación de symlinks: --symlink_prefix=/ hará que Bazel no cree ni actualice ningún symlink, incluidos los symlinks bazel-out y bazel-<workspace>. Usa esta opción para suprimir por completo la creación de symlinks.

• Reduce el desorden: --symlink_prefix=.bazel/ hará que Bazel cree symlinks llamados bin (etc.) dentro de un directorio oculto .bazel.

--platform_suffix=string

Agrega un sufijo al nombre corto de configuración, que se usa para determinar el directorio de salida. Configurar esta opción en valores diferentes coloca los archivos en diferentes directorios, por ejemplo, a fin de mejorar las tasas de aciertos de caché para compilaciones que, de lo contrario, se producen archivos de salida entre sí o con el fin de mantener los archivos de salida alrededor para las comparaciones.

--default_visibility=(private|public)

Marca temporal para probar los cambios de visibilidad predeterminados de Bazel. No está diseñado para uso general, pero está documentado con fines de integridad.

--starlark_cpu_profile=_file_

Esta marca, cuyo valor es el nombre de un archivo, hace que Bazel recopile estadísticas sobre el uso de CPU de todos los subprocesos de Starlark y escriba el perfil en formato pprof en el archivo con nombre.

Usa esta opción para identificar las funciones de Starlark que ralentizan la carga y el análisis debido al cálculo excesivo. Por ejemplo:

$ bazel build --nobuild --starlark_cpu_profile=/tmp/pprof.gz my/project/...
$ pprof /tmp/pprof.gz
(pprof) top
Type: CPU
Time: Feb 6, 2020 at 12:06pm (PST)
Duration: 5.26s, Total samples = 3.34s (63.55%)
Showing nodes accounting for 3.34s, 100% of 3.34s total
      flat  flat%   sum%        cum   cum%
     1.86s 55.69% 55.69%      1.86s 55.69%  sort_source_files
     1.02s 30.54% 86.23%      1.02s 30.54%  expand_all_combinations
     0.44s 13.17% 99.40%      0.44s 13.17%  range
     0.02s   0.6%   100%      3.34s   100%  sorted
         0     0%   100%      1.38s 41.32%  my/project/main/BUILD
         0     0%   100%      1.96s 58.68%  my/project/library.bzl
         0     0%   100%      3.34s   100%  main

Para diferentes vistas de los mismos datos, prueba los comandos pprof svg, web y list.

Usa Bazel para lanzamientos

Los ingenieros de software usan Bazel durante el ciclo de desarrollo y los ingenieros de lanzamiento cuando preparan los objetos binarios para su implementación en producción. En esta sección, se proporciona una lista de sugerencias para ingenieros de versiones que usan Bazel.

Opciones significativas

Cuando se usa Bazel para compilaciones de lanzamiento, surgen los mismos problemas que para otras secuencias de comandos que realizan una compilación. Para obtener más detalles, consulta Llama a Bazel desde las secuencias de comandos. En particular, se recomiendan las siguientes opciones:

• --bazelrc=/dev/null
• --nokeep_state_after_build

Estas opciones también son importantes:

• --package_path
• --symlink_prefix: a fin de administrar compilaciones para varias configuraciones, puede ser conveniente distinguir cada compilación con un identificador distinto, como "64bit" frente a "32bit". Esta opción diferencia los symlinks bazel-bin (etc.).

Cómo ejecutar pruebas

Para compilar y ejecutar pruebas con Bazel, escribe bazel test seguido del nombre de los destinos de prueba.

De forma predeterminada, este comando realiza actividades de compilación y prueba de forma simultánea, compilando todos los destinos especificados (incluidos los que no sean de prueba especificados en la línea de comandos) y prueba los objetivos *_test y test_suite en cuanto se compilan sus requisitos previos, lo que significa que la ejecución de pruebas se superpone con la compilación. Por lo general, esto genera un aumento significativo de la velocidad.

Opciones para bazel test

--cache_test_results=(yes|no|auto) (-t)

Si esta opción se configura como “automática” (predeterminada), Bazel solo volverá a ejecutar una prueba si se cumple alguna de las siguientes condiciones:

• Bazel detecta cambios en la prueba o sus dependencias
• la prueba se marcó como external
• se solicitaron varias ejecuciones de prueba con --runs_per_test
• la prueba falló.

Si la respuesta es “no”, todas las pruebas se ejecutarán de forma incondicional.

Si es "sí", el comportamiento del almacenamiento en caché será el mismo que el automático, excepto que puede almacenar en caché las fallas de prueba y las ejecuciones de prueba con --runs_per_test.

Es posible que los usuarios que habilitaron esta opción de forma predeterminada en su archivo .bazelrc encuentren las abreviaturas -t (activada) o -t- (desactivada) para anular la configuración predeterminada en una ejecución en particular.

--check_tests_up_to_date

Esta opción indica a Bazel que no ejecute las pruebas, sino que solo verifique e informe los resultados almacenados en caché. Si hay pruebas que no se compilaron ni se ejecutaron anteriormente, o cuyos resultados están desactualizados (por ejemplo, porque cambió el código fuente o las opciones de compilación), Bazel informará un mensaje de error ("el resultado de la prueba no está actualizado"), registrará el estado de la prueba como "SIN ESTADO" (en rojo, si el resultado del color está habilitado) y mostrará un código de salida distinto de cero.

Esta opción también implica el comportamiento [--check_up_to_date](#check-up-to-date).

Esta opción puede ser útil para las verificaciones previas al envío.

--test_verbose_timeout_warnings

Esta opción le indica a Bazel que le advierta de manera explícita al usuario si el tiempo de espera de una prueba es significativamente mayor que el tiempo de ejecución real de la prueba. Si bien el tiempo de espera de una prueba debe establecerse de manera que no sea inestable, una prueba que tiene un tiempo de espera demasiado generoso puede ocultar problemas reales que surgen de forma inesperada.

Por ejemplo, una prueba que normalmente se ejecuta en uno o dos minutos no debería tener un tiempo de espera ETERNAL o LONG, ya que son demasiado generosos.

Esta opción es útil para ayudar a los usuarios a decidir sobre un buen valor de tiempo de espera o verificar el estado de los valores de tiempo de espera existentes.

--[no]test_keep_going

De forma predeterminada, todas las pruebas se ejecutan hasta completarse. Sin embargo, si esta marca está inhabilitada, se anula la compilación en cualquier prueba no aprobada. Los pasos de compilación posteriores y las invocaciones de prueba no se ejecutan, y las invocaciones en tránsito se cancelan. No especifiques --notest_keep_going y --keep_going.

--flaky_test_attempts=attempts

Esta opción especifica la cantidad máxima de veces que se debe intentar una prueba si falla por algún motivo. Una prueba que falla en un principio, pero que tiene éxito finalmente, se informa como FLAKY en el resumen de la prueba. Sin embargo, se considera que se pasa cuando se trata de identificar el código de salida de Bazel o la cantidad total de pruebas aprobadas. Las pruebas que fallan todos los intentos permitidos se consideran fallidas.

De forma predeterminada (cuando no se especifica esta opción o cuando se establece como predeterminada), solo se permite un único intento para las pruebas normales, y 3 para las reglas de prueba con el atributo flaky establecido. Puedes especificar un número entero para anular el límite máximo de intentos de prueba. Bazel permite un máximo de 10 intentos de prueba para evitar el abuso del sistema.

--runs_per_test=[regex@]number

Esta opción especifica la cantidad de veces que se debe ejecutar cada prueba. Todas las ejecuciones de prueba se tratan como pruebas independientes (la funcionalidad de resguardo se aplicará a cada una de forma independiente).

El estado de un destino con ejecuciones con errores depende del valor de la marca --runs_per_test_detects_flakes:

• Si está ausente, cualquier ejecución con errores provoca que falle toda la prueba.
• Si hay dos ejecuciones del mismo fragmento, y estas muestran PASS y FAIL, la prueba tendrá un estado inestable (a menos que otras ejecuciones fallidas provoquen el error).

Si se especifica un solo número, se ejecutarán todas las pruebas esa cantidad de veces. Como alternativa, se puede especificar una expresión regular con la sintaxis regex@number. Esto restringe el efecto de --runs_per_test a los objetivos que coinciden con la regex (--runs_per_test=^//pizza:.*@4 ejecuta todas las pruebas por debajo de //pizza/ 4 veces). Este formato de --runs_per_test se puede especificar más de una vez.

--[no]runs_per_test_detects_flakes

Si se especifica esta opción (de forma predeterminada, no lo es), Bazel detectará fragmentos de prueba inestables a través de --runs_per_test. Si una o más ejecuciones para un solo fragmento fallan y una o más ejecuciones para el mismo pase de fragmentos, el objetivo se considerará inestable con la marca. Si no se especifica, el destino informará un estado de falla.

--test_summary=output_style

Especifica cómo se debe mostrar el resumen del resultado de la prueba.

• short imprime los resultados de cada prueba junto con el nombre del archivo que contiene la salida de la prueba si esta falló. Este es el valor predeterminado.
• terse como short, pero aún más corto: Solo imprime información sobre las pruebas que no fueron aprobadas.
• detailed imprime cada caso de prueba individual que falló, no solo cada prueba. Se omiten los nombres de los archivos de salida de prueba.
• none no imprime un resumen de la prueba.

--test_output=output_style

Especifica cómo se debe mostrar el resultado de la prueba:

• summary muestra un resumen de si se aprobó o falló cada prueba. También muestra el nombre del archivo de registro de salida para las pruebas con errores. El resumen se imprimirá al final de la compilación (durante la compilación, se mostrarán mensajes de progreso simples cuando las pruebas comiencen, pasen o fallen). Este es el comportamiento predeterminado.
• errors envía el resultado combinado de stdout/stderr de pruebas fallidas solo al stdout inmediatamente después de que se completa la prueba, lo que garantiza que el resultado de prueba de pruebas simultáneas no se intercalan entre sí. Imprime un resumen en la compilación según el resultado del resumen anterior.
• all es similar a errors, pero imprime los resultados de todas las pruebas, incluidas las que pasaron.
• streamed transmite los resultados de stdout/stderr desde cada prueba en tiempo real.

--java_debug

Esta opción hace que la máquina virtual Java de una prueba de Java espere una conexión de un depurador compatible con JDWP antes de iniciar la prueba. Esta opción implica --test_output=streamed.

--[no]verbose_test_summary

De forma predeterminada, esta opción está habilitada, lo que hace que los tiempos de prueba y otra información adicional (como los intentos de prueba) se impriman en el resumen de la prueba. Si se especifica --noverbose_test_summary, el resumen de la prueba solo incluirá el nombre de la prueba, el estado de la prueba y el indicador de prueba almacenada en caché. Además, tendrá un formato de 80 caracteres cuando sea posible.

--test_tmpdir=path

Especifica el directorio temporal para las pruebas ejecutadas de manera local. Cada prueba se ejecutará en un subdirectorio independiente dentro de este directorio. El directorio se limpiará al comienzo de cada comando bazel test. De forma predeterminada, Bazel ubicará este directorio en el directorio base de salida de Bazel.

--test_timeout=seconds O --test_timeout=seconds,seconds,seconds,seconds

Anula el valor de tiempo de espera para todas las pruebas mediante el uso de una cantidad de segundos especificada como un valor de tiempo de espera nuevo. Si solo se proporciona un valor, se usará para todas las categorías de tiempo de espera de la prueba.

Como alternativa, se pueden proporcionar cuatro valores separados por comas, que especifican tiempos de espera individuales para pruebas cortas, moderadas, largas y eternas (en ese orden). En cualquier forma, cero o un valor negativo para cualquiera de los tamaños de prueba se sustituirán por el tiempo de espera predeterminado para las categorías de tiempo de espera determinadas, como se define en la página Cómo escribir pruebas. De forma predeterminada, Bazel usará estos tiempos de espera para todas las pruebas deduciendo el límite de tiempo de espera a partir del tamaño de la prueba, sin importar si el tamaño se estableció de forma implícita o explícita.

Las pruebas que indiquen de forma explícita que su categoría de tiempo de espera es diferente de su tamaño recibirán el mismo valor que si la etiqueta de tamaño hubiera configurado implícitamente ese tiempo de espera. Por lo tanto, una prueba de tamaño "pequeño" que declare un tiempo de espera "largo" tendrá el mismo tiempo de espera efectivo que una prueba "grande" sin tiempo de espera explícito.

--test_arg=arg

Pasa opciones, marcas o argumentos de la línea de comandos a cada proceso de prueba. Esta opción se puede usar varias veces para pasar varios argumentos. Por ejemplo, --test_arg=--logtostderr --test_arg=--v=3.

--test_env=variable=_value_ O --test_env=variable

Especifica variables adicionales que se deben insertar en el entorno de prueba para cada prueba. Si no se especifica value, se heredará del entorno de shell que se usó para iniciar el comando bazel test.

Se puede acceder al entorno desde una prueba mediante System.getenv("var") (Java), getenv("var") (C o C++),

--run_under=command-prefix

Especifica un prefijo que el ejecutor de pruebas insertará delante del comando de prueba antes de ejecutarlo. command-prefix se divide en palabras mediante reglas de asignación de token de shell Bourne y, luego, la lista de palabras se agrega al comando que se ejecutará.

Si la primera palabra es una etiqueta completamente calificada (comienza con //), se compila. Luego, la etiqueta se sustituye por la ubicación ejecutable correspondiente que está precedida al comando que se ejecutará junto con las otras palabras.

Se aplican algunas advertencias:

• Es posible que PATH para ejecutar pruebas sea diferente del PATH en tu entorno, por lo que es posible que debas usar una ruta de acceso absoluta para el comando --run_under (la primera palabra en command-prefix).
• stdin no está conectado, por lo que no se puede usar --run_under para comandos interactivos.

Ejemplos:

        --run_under=/usr/bin/strace
        --run_under='/usr/bin/strace -c'
        --run_under=/usr/bin/valgrind
        --run_under='/usr/bin/valgrind --quiet --num-callers=20'

Selección de prueba

Como se documenta en Opciones de selección de salida, puedes filtrar pruebas por tamaño, tiempo de espera, etiqueta o idioma. Un filtro de nombre general conveniente puede reenviar argumentos de filtro particulares al ejecutor de pruebas.

Otras opciones para bazel test

La sintaxis y las opciones restantes son exactamente como bazel build.

Ejecuta ejecutables

El comando bazel run es similar a bazel build, excepto que se usa para compilar y ejecutar un solo destino. Esta es una sesión típica:

  % bazel run java/myapp:myapp -- --arg1 --arg2
  Welcome to Bazel
  INFO: Loading package: java/myapp
  INFO: Loading package: foo/bar
  INFO: Loading complete.  Analyzing...
  INFO: Found 1 target...
  ...
  Target //java/myapp:myapp up-to-date:
    bazel-bin/java/myapp:myapp
  INFO: Elapsed time: 0.638s, Critical Path: 0.34s

  INFO: Running command line: bazel-bin/java/myapp:myapp --arg1 --arg2
  Hello there
  $EXEC_ROOT/java/myapp/myapp
  --arg1
  --arg2

bazel run es similar, pero no idéntico, a invocar de forma directa el objeto binario compilado por Bazel y su comportamiento es diferente según si el objeto binario que se invoca es una prueba o no.

Cuando el objeto binario no es una prueba, el directorio de trabajo actual será el árbol de runfiles del objeto binario.

Cuando el objeto binario es una prueba, el directorio de trabajo actual será la raíz de ejecución y se realizará un intento de buena fe para replicar las pruebas de entorno que se suelen ejecutar. Sin embargo, la emulación no es perfecta y las pruebas que tienen varios fragmentos no se pueden ejecutar de esta manera (se puede usar la opción de línea de comandos --test_sharding_strategy=disabled para solucionar este problema).

Las siguientes variables de entorno adicionales también están disponibles para el objeto binario:

• BUILD_WORKSPACE_DIRECTORY: Es la raíz del lugar de trabajo en el que se ejecutó la compilación.
• BUILD_WORKING_DIRECTORY: Es el directorio de trabajo actual desde el que se ejecutó Bazel.

Estos se pueden usar, por ejemplo, para interpretar nombres de archivos en la línea de comandos de una manera sencilla.

Opciones para bazel run

--run_under=command-prefix

Esto tiene el mismo efecto que la opción --run_under para bazel test (consulta la sección anterior), excepto que se aplica al comando que ejecuta bazel run, en lugar de a las pruebas que ejecuta bazel test y no puede ejecutarse bajo una etiqueta.

Filtra resultados de registro desde Bazel

Cuando se invoca un objeto binario con bazel run, Bazel imprime el resultado del registro de Bazel y del objeto binario en invocación. Para que los registros sean menos ruidosos, puedes suprimir las salidas de Bazel con las marcas --ui_event_filters y --noshow_progress.

Por ejemplo:bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp

Cómo ejecutar pruebas

bazel run también puede ejecutar objetos binarios de prueba, que tiene el efecto de ejecutar la prueba en una aproximación cercana al entorno descrito en Cómo escribir pruebas. Ten en cuenta que ninguno de los argumentos --test_* tiene efecto cuando se ejecuta una prueba de esta manera, excepto --test_arg .

Limpieza de resultados de compilación

El comando clean

Bazel tiene un comando clean, análogo a Make. Borra los directorios de salida para todas las configuraciones de compilación que realiza esta instancia de Bazel o todo el árbol de trabajo que creó esta instancia de Bazel, y restablece las memorias caché internas. Si se ejecuta sin ninguna opción de línea de comandos, se limpiará el directorio de salida para todas las configuraciones.

Recuerda que cada instancia de Bazel está asociada con un solo lugar de trabajo, por lo que el comando clean borrará todos los resultados de todas las compilaciones que hayas realizado con esa instancia de Bazel en ese lugar de trabajo.

Para quitar por completo todo el árbol de trabajo que creó una instancia de Bazel, puedes especificar la opción --expunge. Cuando se ejecuta con --expunge, el comando limpio solo quita todo el árbol base de salida que, además del resultado de compilación, contiene todos los archivos temporales creados por Bazel. También detiene el servidor de Bazel después de la limpieza, lo que equivale al comando shutdown. Por ejemplo, para borrar todos los registros de disco y memoria de una instancia de Bazel, puedes especificar lo siguiente:

  % bazel clean --expunge

Como alternativa, puedes eliminar definitivamente en segundo plano mediante --expunge_async. Es seguro invocar un comando de Bazel en el mismo cliente mientras la eliminación asíncrona sigue ejecutándose.

El comando clean se proporciona principalmente como un medio para reclamar espacio en disco para los lugares de trabajo que ya no son necesarios. Es posible que las recompilaciones incrementales de Bazel no sean perfectas, por lo que se puede usar clean para recuperar un estado coherente cuando surgen problemas.

El diseño de Bazel es tal que estos problemas se pueden solucionar y es una prioridad alta solucionar estos errores. Si en algún momento encuentras una compilación incremental incorrecta, envía un informe de errores y, luego, informa los errores en las herramientas, en lugar de usar clean.

Consulta el grafo de dependencia

Bazel incluye un lenguaje de consulta para hacer preguntas sobre el gráfico de dependencia que se usa durante la compilación. El lenguaje de consulta lo usan dos comandos: query y cquery. La diferencia principal entre los dos comandos es que la consulta se ejecuta después de la fase de carga y la consulta se ejecuta después de la fase de análisis. Estas herramientas son de gran ayuda para muchas tareas de ingeniería de software.

El lenguaje de consulta se basa en la idea de operaciones algebraicas en grafos y se documenta en detalle en

Referencia de consultas de Bazel Consulta ese documento como referencia, ejemplos y opciones de línea de comandos específicas de consultas.

La Herramienta de consultas acepta varias opciones de línea de comandos. --output selecciona el formato de salida. --[no]keep_going (inhabilitado de forma predeterminada) hace que la herramienta de consulta continúe progresando ante errores. Este comportamiento puede inhabilitarse si un resultado incompleto no es aceptable en caso de errores.

La opción --[no]tool_deps, habilitada de forma predeterminada, hace que las dependencias en configuraciones sin destino se incluyan en el gráfico de dependencias sobre el que opera la consulta.

La opción --[no]implicit_deps, habilitada de forma predeterminada, hace que las dependencias implícitas se incluyan en el gráfico de dependencias sobre el que opera la consulta. Una dependencia implícita no se especifica de forma explícita en el archivo BUILD, pero se agrega mediante Bazel.

Ejemplo: "Muestra las ubicaciones de las definiciones (en archivos BUILD) de todas las genrules necesarias para compilar todas las pruebas en el árbol PEBL".

  bazel query --output location 'kind(genrule, deps(kind(".*_test rule", foo/bar/pebl/...)))'

Cómo consultar el grafo de acción

El comando aquery te permite consultar las acciones en tu gráfico de compilación. Funciona en el grafo de destino configurado después del análisis y expone información sobre las acciones, los artefactos y sus relaciones.

La herramienta acepta varias opciones de la línea de comandos. --output selecciona el formato de salida. El formato de salida predeterminado (text) es legible; usa proto o textproto para un formato legible por máquina. En particular, el comando de consulta se ejecuta sobre una compilación normal de Bazel y hereda el conjunto de opciones disponibles durante una compilación.

Es compatible con el mismo conjunto de funciones que también está disponible para query tradicional, pero siblings, buildfiles y tests.

Si deseas obtener más información, consulta Consulta del gráfico de acciones.

Comandos y opciones varios

help

El comando help proporciona ayuda en línea. De forma predeterminada, se muestra un resumen de los comandos y temas de ayuda disponibles, como se indica en Compila con Bazel. Cuando se especifica un argumento, se muestra la ayuda detallada de un tema en particular. La mayoría de los temas son comandos de Bazel, como build o query, pero hay algunos temas de ayuda adicionales que no corresponden a comandos.

--[no]long (-l)

De forma predeterminada, bazel help [topic] solo imprime un resumen de las opciones relevantes de un tema. Si se especifica la opción --long, también se imprimen el tipo, el valor predeterminado y la descripción completa de cada una.

shutdown

Los procesos del servidor de Bazel se pueden detener mediante el comando shutdown. Este comando hace que el servidor de Bazel salga en cuanto se vuelva inactivo (por ejemplo, después de completar cualquier compilación u otros comandos que estén en curso). Para obtener más detalles, consulta Implementación de cliente/servidor.

Los servidores de Bazel se detienen a sí mismos después de un tiempo de espera inactivo, por lo que este comando se necesita poco. Sin embargo, puede ser útil en las secuencias de comandos cuando se sabe que no se realizarán más compilaciones en un lugar de trabajo determinado.

shutdown acepta una opción, --iff_heap_size_greater_than _n_, que requiere un argumento de número entero (en MB). Si se especifica, esto hace que el cierre sea condicional a la cantidad de memoria que ya se consumió. Esto es útil para las secuencias de comandos que inician muchas compilaciones, ya que cualquier fuga de memoria en el servidor de Bazel podría provocar que falle de forma esporádica ocasional; realizar un reinicio condicional interrumpe esta condición.

info

El comando info imprime varios valores asociados con la instancia del servidor de Bazel o con una configuración de compilación específica. (Pueden usarse en las secuencias de comandos que generan una compilación).

El comando info también permite un argumento único (opcional), que es el nombre de una de las claves de la lista a continuación. En este caso, bazel info key imprimirá solo el valor de esa clave. Esto es muy conveniente cuando se ejecuta la secuencia de comandos de Bazel, ya que evita la necesidad de canalizar el resultado a través de sed -ne /key:/s/key://p:

Datos independientes de la configuración

• release: Es la etiqueta de lanzamiento de esta instancia de Bazel o “versión de desarrollo” si no es un objeto binario lanzamiento.
• workspace es la ruta absoluta al directorio del lugar de trabajo base.

• install_base: Es la ruta de acceso absoluta del directorio de instalación que usa esta instancia de Bazel para el usuario actual. Bazel instala los ejecutables necesarios internamente debajo de este directorio.

• output_base: Es la ruta de acceso absoluta del directorio de salida base que usa esta instancia de Bazel para la combinación actual de usuario y lugar de trabajo. Bazel coloca todos sus elementos agregados y resultados de compilación debajo de este directorio.

• execution_root: Es la ruta de acceso absoluta del directorio raíz de la ejecución en output_base. Este directorio es la raíz de todos los archivos a los que pueden acceder los comandos ejecutados durante la compilación, y es el directorio de trabajo de esos comandos. Si se puede escribir en el directorio del lugar de trabajo, se colocará un symlink llamado bazel-<workspace> que apunta a este directorio.

• output_path: Es la ruta absoluta al directorio de salida debajo de la raíz de ejecución que se usa para todos los archivos que se generaron como resultado de los comandos de compilación. Si se puede escribir en el directorio del lugar de trabajo, se coloca un symlink llamado bazel-out que apunta a este directorio.

• server_pid: Es el ID del proceso del servidor de Bazel.

• server_log: Es la ruta de acceso absoluta al archivo de registro de depuración del servidor de Bazel. Este archivo contiene información de depuración para todos los comandos durante la vida útil del servidor de Bazel, y está destinado al consumo humano por parte de desarrolladores y usuarios avanzados de Bazel.

• command_log: Es la ruta de acceso absoluta al archivo de registro de comandos; que contiene las transmisiones stdout y stderr intercaladas del comando de Bazel más reciente. Ten en cuenta que ejecutar bazel info reemplazará el contenido de este archivo, ya que se convierte en el comando de Bazel más reciente. Sin embargo, la ubicación del archivo de registro de comandos no cambiará, a menos que cambies la configuración de las opciones --output_base o --output_user_root.

• used-heap-size, committed-heap-size, max-heap-size: informa varios parámetros de tamaño de montón de JVM. Respetuosamente: memoria usada actualmente, memoria garantizada actualmente para estar disponible para la JVM desde el sistema, máxima asignación posible.

• gc-count, gc-time: El recuento acumulativo de recolecciones de elementos no utilizados desde el inicio de este servidor de Bazel y el tiempo dedicado a realizarlas. Ten en cuenta que estos valores no se restablecen al comienzo de cada compilación.

• package_path: Una lista de rutas de acceso separadas por dos puntos que se buscarían en paquetes por Bazel. Tiene el mismo formato que el argumento de línea de comandos de compilación --package_path.

Ejemplo: El ID del proceso del servidor de Bazel.

% bazel info server_pid
1285

Datos específicos de la configuración

Estos datos pueden verse afectados por las opciones de configuración que se pasan a bazel info, por ejemplo, --cpu, --compilation_mode, etc. El comando info acepta todas las opciones que controlan el análisis de dependencia, ya que algunas determinan la ubicación del directorio de salida de una compilación, la elección del compilador, etcétera.

• bazel-bin, bazel-testlogs y bazel-genfiles: informa la ruta de acceso absoluta a los directorios bazel-* en los que se encuentran los programas generados por la compilación. Por lo general, esto no es lo mismo que los symlinks bazel-* creados en el directorio del lugar de trabajo base después de una compilación correcta. Sin embargo, si el directorio del lugar de trabajo es de solo lectura, no se pueden crear symlinks bazel-*. Las secuencias de comandos que usan el valor que informa bazel info, en lugar de suponer la existencia del symlink, serán más sólidas.
• El entorno de “Make” completo Si se especifica la marca --show_make_env, también se muestran todas las variables en el entorno de "Make" de la configuración actual (como CC, GLIBC_VERSION, etc.). Estas son las variables a las que se accede mediante la sintaxis $(CC) o varref("CC") dentro de los archivos BUILD.

Ejemplo: El compilador de C++ para la configuración actual Esta es la variable $(CC) en el entorno "Make", por lo que se necesita la marca --show_make_env.

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

Ejemplo: El directorio de salida bazel-bin para la configuración actual. Se garantiza que esto sea correcto incluso cuando el symlink bazel-bin no se pueda crear por algún motivo (por ejemplo, si compilas desde un directorio de solo lectura).

% bazel info --cpu=piii bazel-bin
/var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/piii-opt/bin
% bazel info --cpu=k8 bazel-bin
/var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/k8-opt/bin

version y --version

El comando de versión imprime los detalles de la versión sobre el objeto binario de Bazel compilado, incluida la lista de cambios en la que se compiló y la fecha. Estos son muy útiles para determinar si tienes la versión de Bazel más reciente o si informas errores. Estos son algunos de los valores interesantes:

• changelist: Es la lista de cambios en la que se lanzó esta versión de Bazel.
• label: Es la etiqueta de lanzamiento de esta instancia de Bazel o “versión de desarrollo” si no es un objeto binario lanzamiento. Es muy útil para informar errores.

bazel --version, sin otros argumentos, emitirá el mismo resultado que bazel version --gnu_format, excepto sin el efecto secundario de iniciar potencialmente un servidor de Bazel o descomprimir el archivo del servidor. bazel --version se puede ejecutar desde cualquier lugar; no requiere un directorio de lugar de trabajo.

mobile-install

El comando mobile-install instala apps en dispositivos móviles. Actualmente, solo se admiten dispositivos Android que ejecuten ART.

Consulta bazel mobile-install para obtener más información.

Se admiten las siguientes opciones:

--incremental

Si se configura, Bazel intenta instalar la app de forma incremental, es decir, solo las partes que cambiaron desde la última compilación. No se pueden actualizar los recursos a los que se hace referencia en AndroidManifest.xml, el código nativo o los recursos de Java (como los que se mencionan en Class.getResource()). Si estos cambios cambian, se debe omitir esta opción. Contrario al espíritu de Bazel y debido a limitaciones de la plataforma de Android, es responsabilidad del usuario saber cuándo este comando es suficiente y cuando se necesita una instalación completa.

Si usas un dispositivo con Marshmallow o posterior, considera la marca --split_apks.

--split_apks

Indica si se deben usar APK divididos para instalar y actualizar la aplicación en el dispositivo. Solo funciona con dispositivos con Marshmallow o posterior. Ten en cuenta que la marca --incremental no es necesaria cuando se usa --split_apks.

--start_app

Inicia la app en un estado limpio después de la instalación. Equivale a --start=COLD.

--debug_app

Espera a que se adjunte el depurador antes de iniciar la app en un estado limpio después de la instalación. Equivale a --start=DEBUG.

--start=_start_type_

Cómo se debe iniciar la app después de instalarla Los _start_type_s admitidos son los siguientes:

• NO no inicia la app, que es la predeterminada.
• COLD: Inicia la app desde un estado limpio después de la instalación.
• WARM Conserva y restablece el estado de la aplicación en instalaciones incrementales.
• DEBUG Espera a que el depurador se inicie antes de iniciar la app en un estado limpio después de la instalación.

--adb=path

Indica el objeto binario adb que se usará.

De forma predeterminada, se usa adb en el SDK de Android que especifica --android_sdk.

--adb_arg=serial

Argumentos adicionales a adb. Estos aparecen antes del subcomando en la línea de comandos y, por lo general, se usan para especificar en qué dispositivo se debe instalar. Por ejemplo, para seleccionar el dispositivo o emulador de Android que quieres usar, haz lo siguiente:

% bazel mobile-install --adb_arg=-s --adb_arg=deadbeef

invoca a adb como

adb -s deadbeef install ...

--incremental_install_verbosity=number

La verbosidad para una instalación incremental. Configúralo en 1 para que el registro de depuración se imprima en la consola.

dump

El comando dump imprime en stdout un volcado del estado interno del servidor de Bazel. Este comando está dirigido principalmente a desarrolladores de Bazel, por lo que el resultado de este comando no se especifica y está sujeto a cambios.

De forma predeterminada, el comando solo imprimirá un mensaje de ayuda en el que se describen las posibles opciones para volcar áreas específicas del estado de Bazel. Para volcar el estado interno, se debe especificar al menos una de las opciones.

Se admiten las siguientes opciones:

• --action_cache vuelca contenido de la caché de acciones.
• --packages vuelca contenido de la caché del paquete.
• --skyframe vuelca el estado del gráfico de dependencias de Bazel interno.
• --rules muestra el resumen de reglas para cada regla y clase de aspecto, incluidos los recuentos y los recuentos de acciones. Esto incluye las reglas nativas y de Starlark. Si el seguimiento de memoria está habilitado, también se imprime el consumo de memoria de las reglas.
• --skylark_memory vuelca un archivo .gz compatible con pprof en la ruta de acceso especificada. Para que esto funcione, debes habilitar el seguimiento de memoria.

Seguimiento de la memoria

Algunos comandos de dump requieren seguimiento de memoria. Para activar esto, debes pasar las marcas de inicio a Bazel:

• --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar
• --host_jvm_args=-DRULE_MEMORY_TRACKER=1

java-agent se registra en Bazel en third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar, así que asegúrate de ajustar $BAZEL para mantener tu repositorio de Bazel.

No olvides seguir pasando estas opciones a Bazel para cada comando o el servidor se reiniciará.

Ejemplo:

    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    build --nobuild <targets>

    # Dump rules
    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    dump --rules

    # Dump Starlark heap and analyze it with pprof
    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    dump --skylark_memory=$HOME/prof.gz
    % pprof -flame $HOME/prof.gz

analyze-profile

El comando analyze-profile analiza un perfil de seguimiento JSON que se recopiló durante una invocación de Bazel.

canonicalize-flags

El comando canonicalize-flags, que toma una lista de opciones para un comando de Bazel y muestra una lista de opciones que tienen el mismo efecto. La nueva lista de opciones es canónica. Por ejemplo, dos listas de opciones con el mismo efecto se canonicalizan para la misma lista nueva.

La opción --for_command se puede usar para seleccionar entre diferentes comandos. En este momento, solo se admiten build y test. Las opciones que el comando determinado no admite generan un error.

Observa el siguiente ejemplo:

  % bazel canonicalize-flags -- --config=any_name --test_tag_filters="-lint"
  --config=any_name
  --test_tag_filters=-lint

Opciones de inicio

Las opciones que se describen en esta sección afectan el inicio de la máquina virtual de Java que usa el proceso del servidor de Bazel y se aplican a todos los comandos posteriores que administra ese servidor. Si ya hay un servidor de Bazel en ejecución y las opciones de inicio no coinciden, se reiniciará.

Todas las opciones descritas en esta sección deben especificarse con la sintaxis --key=value o --key value. Además, estas opciones deben aparecer antes del nombre del comando de Bazel. Usa startup --key=value para enumerarlas en un archivo .bazelrc.

--output_base=dir

Esta opción requiere un argumento de ruta, que debe especificar un directorio que admita escritura. Bazel usará esta ubicación para escribir todos los resultados. La base de salida también es la clave mediante la cual el cliente ubica el servidor de Bazel. Si cambias la base de resultados, cambiarás el servidor que manejará el comando.

De forma predeterminada, la base de resultados se deriva del nombre de acceso del usuario y del nombre del directorio del lugar de trabajo (en realidad, su resumen de MD5), por lo que un valor típico es el siguiente: /var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e.

Por ejemplo:

 OUTPUT_BASE=/var/tmp/google/_bazel_johndoe/custom_output_base
% bazel --output_base ${OUTPUT_BASE}1 build //foo  &  bazel --output_base ${OUTPUT_BASE}2 build //bar

En este comando, los dos comandos de Bazel se ejecutan en simultáneo (debido al operador de shell &), cada uno usa una instancia de servidor de Bazel diferente (debido a las diferentes bases de salida). Por el contrario, si la base de salida predeterminada se usa en ambos comandos, ambas solicitudes se enviarán al mismo servidor, lo que las controlará de forma secuencial: compilando //foo primero y, luego, una compilación incremental de //bar.

--output_user_root=dir

Hace referencia al directorio raíz en el que se crean las bases de instalación y salida. El directorio no debe existir o ser propiedad del usuario que realiza la llamada. Anteriormente, este permiso permitía apuntar a un directorio compartido entre varios usuarios, pero ya no está permitido. Esto se puede permitir una vez que se solucione el error #11100.

Si se especifica la opción --output_base, se anula mediante --output_user_root a fin de calcular la base de resultados.

La ubicación de la base de instalaciones se calcula en función de --output_user_root, más la identidad MD5 de los objetos binarios incorporados de Bazel.

Puedes usar la opción --output_user_root a fin de elegir una ubicación base alternativa para todos los resultados de Bazel (base de instalaciones y base de salida) si hay una mejor ubicación en el diseño del sistema de archivos.

--server_javabase=dir

Especifica la máquina virtual Java en la que se ejecuta Bazel. El valor debe ser una ruta al directorio que contiene un JDK o JRE. No debe ser una etiqueta. Esta opción debe aparecer antes de cualquier comando de Bazel, por ejemplo:

  % bazel --server_javabase=/usr/local/buildtools/java/jdk11 build //foo

Esta marca no afecta a las JVM que usan los subprocesos de Bazel, como aplicaciones, pruebas, herramientas, etcétera. En su lugar, usa las opciones de compilación --javabase o --host_javabase.

Esta marca antes se llamaba --host_javabase (a veces denominada --host_javabase) del "lado izquierdo", pero se le cambió el nombre para evitar confusiones con la marca de compilación --host_javabase (a veces conocida como --host_javabase del "lado derecho").

--host_jvm_args=string

Especifica una opción de inicio que se pasará a la máquina virtual Java en la que se ejecuta Bazel. Se puede usar para configurar el tamaño de la pila, por ejemplo:

  % bazel --host_jvm_args="-Xss256K" build //foo

Esta opción se puede usar varias veces con argumentos individuales. Ten en cuenta que no suele ser necesario establecer esta marca. También puedes pasar una lista de strings separadas por espacios, cada una de las cuales se interpretará como un argumento de JVM independiente, pero esta función pronto dejará de estar disponible.

Que esto no afecta a ninguna JVM que usan los subprocesos de Bazel: aplicaciones, pruebas, herramientas, etcétera. Para pasar opciones de JVM a programas ejecutables de Java, ya sea que los ejecute bazel run o en la línea de comandos, debes usar el argumento --jvm_flags que admiten todos los programas java_binary y java_test. Como alternativa, para las pruebas, usa bazel test --test_arg=--jvm_flags=foo ....

--host_jvm_debug

Esta opción hace que la máquina virtual de Java espere una conexión de un depurador compatible con JDWP antes de llamar al método principal de Bazel. Esto está destinado principalmente a los desarrolladores de Bazel.

--autodetect_server_javabase

Esta opción hace que Bazel busque automáticamente un JDK instalado en el inicio y recurra al JRE instalado si el JRE incorporado no está disponible. Se puede usar --explicit_server_javabase a fin de elegir un JRE explícito para ejecutar Bazel.

--batch

El modo por lotes hace que Bazel no use el modo estándar de cliente o servidor, sino que ejecuta un proceso de Bazel Java para un solo comando, que se usó con fines semánticos previsibles en relación con el control de la señal, el control de trabajos y la herencia de variables de entorno, y es necesario para ejecutar Bazel en una cárcel chroot.

El modo por lotes retiene la semántica de colas adecuada dentro de output_base. Es decir, las invocaciones simultáneas se procesarán en orden, sin superposición. Si se ejecuta un modo por lotes de Bazel en un cliente con un servidor en ejecución, primero se cierra el servidor antes de procesar el comando.

Bazel se ejecutará más lento en modo por lotes o con las alternativas descritas anteriormente. Esto se debe a que, entre otras cosas, la caché del archivo de compilación reside en la memoria, por lo que no se conserva entre invocaciones en lote. Por lo tanto, usar el modo por lotes suele ser más útil en los casos en que el rendimiento es menos crítico, como las compilaciones continuas.

--max_idle_secs=n

Esta opción especifica cuánto tiempo, en segundos, debe esperar el proceso del servidor de Bazel después de la última solicitud del cliente, antes de salir. El valor predeterminado es 10,800 (3 horas). --max_idle_secs=0 hará que el proceso del servidor de Bazel persista indefinidamente.

Es posible que las secuencias de comandos que invocan Bazel usen esta opción para garantizar que no abandonen los procesos del servidor de Bazel en la máquina de un usuario cuando no se ejecutarían de otra manera. Por ejemplo, una secuencia de comandos de envío previo podría querer invocar a bazel query para garantizar que el cambio pendiente de un usuario no introduzca dependencias no deseadas. Sin embargo, si el usuario no realizó una compilación reciente en ese lugar de trabajo, no se recomienda que la secuencia de comandos de envío previo inicie un servidor de Bazel solo para que permanezca inactivo durante el resto del día. Cuando se especifica un valor pequeño de --max_idle_secs en la solicitud de consulta, la secuencia de comandos puede garantizar que si se inició un servidor nuevo, este se cerrará de inmediato, pero si, en su lugar, ya hay un servidor en ejecución, este se seguirá ejecutando hasta que esté inactivo durante el tiempo habitual. Por supuesto, se restablecerá el temporizador de inactividad del servidor existente.

--[no]shutdown_on_low_sys_mem

Si se habilita y --max_idle_secs se establece en una duración positiva, después de que el servidor de compilación haya estado inactivo durante un tiempo, apaga el servidor cuando quede poca memoria en el sistema. Solo en Linux.

Además de ejecutar una verificación de inactividad correspondiente a max_idle_secs, el servidor de compilación comenzará a supervisar la memoria disponible del sistema después de que el servidor haya estado inactivo durante un tiempo. Si la memoria disponible del sistema disminuye considerablemente, se cerrará el servidor.

--[no]block_for_lock

Si se habilita, Bazel esperará a que se completen otros comandos de Bazel que mantienen el bloqueo del servidor antes de avanzar. Si se inhabilita, Bazel saldrá por error si no puede adquirir el bloqueo y continuar de inmediato.

Los desarrolladores pueden usar esto en las verificaciones previas al envío para evitar largas esperas causadas por otro comando de Bazel en el mismo cliente.

--io_nice_level=n

Establece un nivel de 0 a 7 para la programación de IO con el mejor esfuerzo. 0 es la prioridad más alta y 7 es la menor. El programador anticipado solo puede respetar la prioridad 4. Se ignoran los valores negativos.

--batch_cpu_scheduling

Usa la programación de CPU batch para Bazel. Esta política es útil para las cargas de trabajo que no son interactivas, pero no quieren disminuir su valor agradable. Consulta "man 2 sched_setscheduler". Esta política puede proporcionar una mejor interactividad del sistema a expensas de la capacidad de procesamiento de Bazel.

Otras opciones

--[no]announce_rc

Controla si Bazel anuncia las opciones de comando que se leen del archivo bazelrc cuando se inicia. (Las opciones de inicio se anuncian de forma incondicional).

--color (yes|no|auto)

Esta opción determina si Bazel usará colores para destacar su resultado en la pantalla.

Si esta opción se configura como yes, se habilitará el resultado de color. Si esta opción se configura como auto, Bazel usará la salida de color solo si el resultado se envía a una terminal y la variable de entorno TERM se configura con un valor distinto de dumb, emacs o xterm-mono. Si esta opción se configura como no, el resultado de color se inhabilita, sin importar si el resultado se dirige a una terminal o si se establece la variable de entorno TERM.

--config=name

Selecciona una sección de configuración adicional en los archivos rc. Para el command actual, también extrae las opciones de command:name si esa sección existe. Se puede especificar varias veces para agregar marcas de varias secciones de configuración. Las expansiones pueden hacer referencia a otras definiciones (por ejemplo, expansiones que se pueden encadenar).

--curses (yes|no|auto)

Esta opción determina si Bazel usará los controles del cursor en el resultado de la pantalla. Esto da como resultado menos datos de desplazamiento y un flujo de salida más compacto y fácil de leer de Bazel. Esto funciona bien con --color.

Si esta opción se configura como yes, el uso de los controles del cursor estará habilitado. Si esta opción se configura como no, se inhabilita el uso de los controles del cursor. Si esta opción se configura como auto, el uso de los controles del cursor se habilitará en las mismas condiciones que para --color=auto.

--[no]show_timestamps

Si se especifica, se agrega una marca de tiempo a cada mensaje que genera Bazel, que indica la hora a la que se mostró el mensaje.