Comandos y opciones

Denuncia un problemaopen_in_new Ver fuenteopen_in_new Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

En esta página, se describen las opciones que están disponibles con varios comandos de Bazel. como bazel build, bazel run y bazel test. Esta página es complementaria a la lista de comandos de Bazel en Cómo compilar con Bazel.

Sintaxis de destino

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

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 de resumen sobre el significado, el tipo y el valor predeterminado de cada opción.

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

Ubicación del paquete

--package_path

ADVERTENCIA: La opción --package_path dejó de estar disponible. Bazel prefiere los paquetes del repositorio principal para que esté debajo de la raíz del espacio de trabajo.

Esta opción especifica el conjunto de directorios que se buscan para encontrar el archivo BUILD de un paquete determinado.

Bazel busca sus paquetes en la ruta de acceso del paquete. Esto es un signo de dos puntos lista ordenada y separada de directorios de bazel, cada uno de los cuales es la raíz de un árbol de fuentes 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 de acceso del paquete se pueden especificar en tres formatos:

1. Si el primer carácter es /, la ruta de acceso es absoluta.
2. Si la ruta de acceso comienza con %workspace%, se toma en relación con el directorio bazel más cercano. Por ejemplo, si tu directorio de trabajo es /home/bob/clients/bob_client/bazel/foo, luego el Se expande la cadena %workspace% en la ruta del paquete. 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, no es lo que quieres hacer, y es posible que se comporte de forma inesperada si usas Bazel desde directorios inferiores al espacio de trabajo de Bazel. Por ejemplo, si usas el elemento de ruta de paquete ., y, luego, usar el comando cd en el directorio /home/bob/clients/bob_client/bazel/foo, paquetes se resolverán a partir de la /home/bob/clients/bob_client/bazel/foo.

Si usas una ruta de acceso 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 espacio de trabajo de Bazel en blanco si todos los paquetes necesarios se pueden encontrar en otro lugar de la ruta de acceso del paquete.

Ejemplo: Compila a partir de un cliente vacío

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

--deleted_packages

Esta opción especifica una lista separada por comas de paquetes que Bazel debería considerar borrados y no intentar cargar desde ningún directorio en la ruta del paquete. Se puede usar para simular la eliminación de paquetes sin realmente borrarlos. Esta opción se puede pasar varias veces, en cuyo caso las listas individuales están concatenadas.

Verificación de errores

Estas opciones controlan las verificaciones de errores o las advertencias de Bazel.

--[no]check_visibility

Si se establece como falsa, las verificaciones de visibilidad se degradan a advertencias. El valor predeterminado de esta opción es true, de modo que de que se complete la verificación.

--output_filter=regex

La opción --output_filter solo mostrará la compilación y la compilación advertencias para objetivos que coinciden con la expresión regular. Si un objetivo no coincide con la expresión regular proporcionada y su ejecución se realiza correctamente, se descartan su salida estándar y su error estándar.

Estos son algunos valores típicos para 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 muestra resultados para los paquetes especificados.
`--output_filter=`	Muestra todo.
`--output_filter=DONT_MATCH_ANYTHING`	No mostrar nada.

Marcas de herramientas

Estas opciones controlan las opciones que Bazel pasará 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 el procesamiento previo, la compilación o el ensamblado de 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á independiente de la posición.

--host_copt=cc-option

Esta opción incluye un argumento que se pasará al compilador para los archivos fuente que se compilan en la configuración exec. Esto es similar a la opción --copt, pero se aplica solo a la exec de configuración.

--host_conlyopt=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 exec. Esto es similar a la opción --conlyopt, pero solo se aplica a la configuración de exec.

--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 similar a la opción --cxxopt, pero solo se aplica a la configuración de exec.

--host_linkopt=linker-option

Esta opción toma un argumento que se pasará al vinculador para los archivos fuente que se compilan en la configuración de ejecución. Esto es similar a la opción --linkopt, pero solo se aplica a la configuración de exec.

--conlyopt=cc-option

Esta opción toma un argumento que se pasará al compilador cuando se compilen archivos de origen C.

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

--cxxopt=cc-option

Esta opción toma un argumento que se pasará al compilador cuando se compilen archivos de origen C++.

Es similar a --copt, pero solo se aplica a la compilación de C++, no a la compilación o 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 pasará al compilador durante la vinculación.

Esto 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 tienen sentido en el tiempo de vinculación (como -lssp o -Wl,--wrap,abort) con --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 invocando el vinculador con la opción -Wl,--strip-debug --strip=always significa quitar siempre la información de depuración. --strip=never significa que nunca se quitará la 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 quitará la información de depuración de todos los datos binarios.

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 quieres quitar todos los símbolos, no solo los símbolos de depuración, deberás usar la opción --strip-all de ld, que puedes hacer pasando --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 configurar una de las dos.

Si solo compilas un objeto binario 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, se aplica una acción de eliminación después de que se procesa el objeto binario final. en lugar de incluir la eliminación en todas las acciones de vínculo 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 habilita la generación de resultados de perfiles de FDO (optimización dirigida por comentarios) cuando se ejecuta el binario C/C++ compilado. Para GCC, el argumento proporcionado se usa como Prefijo de directorio para un árbol de directorios de archivos por objeto de archivos .gcda que contiene información de perfil de cada archivo .o.

Una vez generado el árbol de datos de perfil, se debe comprimir y entregar al --fdo_optimize=profile-zip Opción de Bazel para habilitar la compilación optimizada para FDO.

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

Las opciones --fdo_instrument y --fdo_optimize no se pueden usar al mismo tiempo.

--fdo_optimize=profile-zip

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

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

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

Las opciones --fdo_instrument y --fdo_optimize no se pueden usar 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

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, 17 y 21, y se pueden extender registrando cadenas de herramientas de Java personalizadas con default_java_toolchain.

--tool_java_language_version=version

Es la versión de 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, remotejdk_17 y remotejdk_21. Para extender los valores, registra una JVM personalizada mediante Reglas del 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 que los argumentos de opción se pasen 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 configurará la tamaño del montón de inicio de la VM en 256 MB.

--javacopt=javac-option

Esta opción permite pasar argumentos de opción 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

Volverá a compilar un objeto java_binary con la información de depuración predeterminada de javac. (en lugar del 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. La última especificación de cualquier opción para javac gana. 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 verifica si faltan dependencias directas. Los destinos de Java deben declarar de forma explícita todos los destinos que se usan directamente como dependencias. Esta marca le indica a javac que determine los archivos JAR que se usan realmente para la verificación de tipos de cada archivo Java y que emita una advertencia o un error 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 todos significa que el javac generará errores en lugar de advertencias, lo que hará que el estado el destino no se compile 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 los comandos de compilación o el contenido del archivo de salida.

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

La opción --compilation_mode (a menudo abreviada como -c, en especial -c opt) toma un argumento de fastbuild, dbg. o opt, y afecta a varias generaciones de código C/C++ opciones, 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 de modo sin tener que volver a compilar cada vez.

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

--cpu=cpu

Esta opción especifica la arquitectura de la CPU de destino que se usará 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, la asignación más reciente prevalece.

--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 en inserta 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 el Comando --experimental_action_listener la opción de línea solo se programará para las orientaciones 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 es aplicable en combinación con el --experimental_action_listener.

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

En el siguiente ejemplo, se limitará la programación de extra_actions para aplicarse únicamente a acciones en 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 para crear las herramientas del host.

--android_platforms=platform[,platform]*

Son las plataformas para compilar el deps transitivo de las reglas android_binary (específicamente para dependencias nativas como C++). Por ejemplo, si aparece un cc_library en el deps transitivo de una regla android_binary, se compila una vez para cada plataforma especificada con --android_platforms para la regla android_binary y se incluye en el resultado final.

No hay un valor predeterminado para esta marca: se debe definir y usar una plataforma de Android personalizada.

Se crea un archivo .so y se empaqueta en el APK para cada plataforma especificada. con --android_platforms. El nombre del archivo .so prefija el nombre del Regla android_binary con "lib". Por ejemplo, si el nombre de android_binary es "foo", el archivo es libfoo.so.

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

Cuando esté presente, se compilará con las opciones proporcionadas cualquier archivo C++ con una etiqueta o una ruta de ejecución que coincida con una de las expresiones de regex de inclusión y que no coincida con ninguna de las expresiones de exclusión. 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 de acceso relativa al directorio de tu espacio de trabajo, incluido el nombre básico (incluida la extensión) del archivo C++. También incluye cualquier prefijo que dependa de la plataforma.

Para que coincidan con los archivos generados (como los resultados de genrule), Bazel solo puede usar la ruta de ejecución. En este caso, la expresión regular no debe comenzar con “//” ya que no coincide con ninguna ruta de ejecución. Los nombres de los paquetes se pueden usar de la siguiente manera: --per_file_copt=base/.*\.pb\.cc@-g0. Esto coincidirá con todos los archivos .pb.cc en 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 use. Por ejemplo, es posible compilar con --compilation_mode=opt y compilar de forma selectiva algunos archivos con la optimización más potente activada o inhabilitada.

Precaución: Si algunos archivos se compilan de forma selectiva con símbolos de depuración, es posible que se quiten durante la vinculación. Esto se puede evitar estableciendo --strip=never

Sintaxis: [+-]regex[,[+-]regex]...@option[,option]... Donde regex significa una expresión regular que puede contener el prefijo un + para identificar patrones de inclusión y con - para identificar excluir patrones. option significa una opción arbitraria que se pasa. al compilador C++. Si una opción contiene un ,, se deben incluir las comillas de esta forma. \, Las opciones también pueden contener @, ya que solo el primer @ se usa 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 forma dinámica, interactuando con el atributo linkstatic en las reglas de compilación.

Modos:

• default: Permite que Bazel elija si vincular de forma dinámica. Consulta linkstatic para obtener más información. información.
• fully: Vincula todos los destinos de forma dinámica. Esto acelerará el tiempo de vinculación y reducirá el tamaño de los objetos binarios resultantes.
• off: Vincula todos los destinos en modo principalmente estático. Si se establece -static en linkopts, los destinos cambiarán a completamente estáticos.

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

Habilita Fission, que escribe información de depuración de C++ en archivos .dwo dedicados en lugar de archivos .o, donde de lo contrario, sí. Esto reduce en gran medida el tamaño de entrada de los vínculos y puede reducir su duración.

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

--force_ignore_dash_static

Si se establece esta marca, se ignoran las opciones -static en linkopts de los archivos BUILD de reglas cc_*. Esto solo se diseñó como una solución alternativa para las compilaciones de endurecimiento de C++.

--[no]force_pic

Si está habilitado, todas las compilaciones de C++ producen código independiente de la posición ("-fPIC"), las vinculaciones prefieren las bibliotecas compiladas previamente de PIC en lugar de las bibliotecas que no son de PIC, y las vinculaciones producen ejecutables independientes de la posición ("-pie"). La opción predeterminada está inhabilitada.

--android_resource_shrinking

Selecciona si se debe realizar la reducción de recursos para las reglas android_binary. Establece la configuración predeterminada shrink_resources activado reglas de 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, usa siempre la implementación de malloc determinada, anula todos los atributos malloc="target", incluidos aquellos objetivos que usan el valor predeterminado (sin especificar ningún malloc).

--crosstool_top=label

Esta opción especifica la ubicación del paquete de compiladores de herramientas cruzadas que se usará para toda la compilación de C++ durante una compilación. Bazel buscará en esa ubicación 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 objetivo principal de esta marca es habilitar la compilación cruzada.

--apple_crosstool_top=label

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

--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 quieres compilar con un crosstool personalizado, debes usar un archivo CROSSTOOL en lugar de que especifica esta marca.

--android_sdk=label

Obsoleta. Esto no se debe especificar directamente.

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 un elemento android_sdk_repository se define en el archivo WORKSPACE.

--java_toolchain=label

No realiza ninguna acción. Se conserva solo para la retrocompatibilidad.

--host_java_toolchain=label

No-ops. Se mantiene solo para brindar retrocompatibilidad.

--javabase=(label)

No-ops. Se mantiene solo para brindar retrocompatibilidad.

--host_javabase=label

No-ops. Se mantiene solo para brindar retrocompatibilidad.

Estrategia de ejecución

Estas opciones afectan la forma en que Bazel ejecutará la compilación. No deberían tener un efecto significativo en los archivos de salida que genera la compilación. Por lo general, su efecto principal se produce en 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 dejó de estar disponible. En su lugar, utiliza local.
• 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 enumeren como directos dependencias en los atributos srcs, data y tools. Bazel habilita la zona de pruebas local de forma predeterminada en los sistemas que admiten la ejecución en 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. Esta opción solo está disponible si se configuró un ejecutor remoto por separado.

--strategy mnemonic=strategy

Esta opción controla dónde y cómo se ejecutan los comandos, lo que anula --spawn_strategy (y --genrule_strategy con mnemotécnico Genrule) por mnemotecnia. Consulta --spawn_strategy para los atributos admitidos estrategias 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 más información regex_filter. Consulta --spawn_strategy para conocer las estrategias compatibles y sus efectos.

Se usa el último 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 usando 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 “Compiling //foo/bar/baz” con la estrategia sandboxed, pero revertir el pedido lo ejecuta con local.
• Ejemplo: Ejecuciones de --strategy_regexp='Compiling.*/bar=local,sandboxed' "Cómo compilar //foo/bar/baz" con la estrategia local y recurre a sandboxed si falla

--genrule_strategy=strategy

Esta es una abreviatura obsoleta de --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 al mismo tiempo durante en la fase de ejecución de la compilación.

--progress_report_interval=n

Bazel imprime periódicamente un informe de progreso en los trabajos que no están aún no haya finalizado (como las pruebas de larga duración). Esta opción establece frecuencia de los informes, el progreso se imprimirá cada n segundos.

El valor predeterminado es 0, lo que significa un algoritmo incremental: el primer el informe se imprimirá después de 10 segundos, luego, a los 30 segundos el progreso se informa 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 prueba para que se ejecuten de forma local. Toman un número entero o una palabra clave (HOST_RAM o HOST_CPUS), opcionalmente seguida de [-|*flotante] (por ejemplo, --local_cpu_resources=2, --local_ram_resources=HOST_RAM*.5 o --local_cpu_resources=HOST_CPUS-1). Las marcas son independientes; se puede 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 Los symlinks para pruebas y objetos binarios deben compilarse 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 para compilar los árboles de runfiles.

Cuando se ejecutan pruebas (o aplicaciones), sus datos del entorno de ejecución las dependencias se reúnen en un solo lugar. En la arquitectura de Bazel de salida, los archivos “runfiles” árbol suele tener sus raíces como hermano de el objeto binario o la prueba correspondiente. Durante la ejecución de prueba, se puede acceder a los archivos de ejecución con rutas de acceso del formato $TEST_SRCDIR/canonical_repo_name/packagename/filename El árbol de runfiles garantiza que las pruebas tengan acceso a todos los archivos sobre 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 necesarios. A medida que crece el conjunto de vínculos, tiene el costo de esta operación y, en el caso de algunas compilaciones grandes, contribuyen significativamente al tiempo general de compilación, en particular, porque Cada prueba individual (o aplicación) requiere su propio árbol de archivos de ejecución.

--[no]build_runfile_manifests

Esta opción, habilitada de forma predeterminada, especifica si los manifiestos de runfiles se debe escribir en el árbol de resultados. Inhabilitarlo 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 a partir de manifiestos en memoria.

--[no]discard_analysis_cache

Cuando esta opción esté habilitada, Bazel descartará la caché de análisis. justo antes de que comience la ejecución, para liberar memoria adicional (alrededor del 10%) para la fase de ejecución. La desventaja es que las compilaciones incrementales posteriores serán más lentas. Consulta también 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 tratar de desarrollar lo más posible, incluso en caso de errores. Esta opción permite ese comportamiento y, cuando se especifica, la compilación intentará compilar cada destino cuyos requisitos previos se hayan compilado correctamente, pero ignorará los errores.

Aunque esta opción generalmente se asocia con la fase de ejecución del en una compilación, también afecta la fase de análisis: si hay varios objetivos especificadas en un comando de compilación, pero solo algunas de ellas se analiza con éxito, la compilación se detendrá con un error a menos que se especifique --keep_going, en cuyo caso el la compilación pasará a 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 de java_library. En lugar de usar la salida de un java_library para compilar dependientes java_library destinos, Bazel creará archivos jar de interfaz. que contengan solo las firmas de miembros no privados (públicos, protegidos, y predeterminados (paquetes) y campos) y usar los archivos jar de la interfaz para compilar los objetivos dependientes. Esto hace que posible y evitar la recompilación cuando los cambios solo se realizan en cuerpos de métodos o miembros privados de una clase.

--[no]interface_shared_objects

Esta opción habilita los objetos compartidos de interfaz, 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 objetivos que dependen de la biblioteca compartida modificada de forma innecesaria.

Selección de salida

Estas opciones determinan qué se compilará o probará.

--[no]build

Esta opción hace que se produzca la fase de ejecución de la compilación. Está activada de forma predeterminada. Cuando se desactiva, seomite la fase de ejecución y solo se producen 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 lenguaje. Si se especifica, Bazel ignorará otros 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 ejecutar Es posible que bazel test --build_tests_only foo/... no detecte todas las compilaciones. en el árbol foo.

--[no]check_up_to_date

Esta opción hace que Bazel no realice una compilación, sino que solo verifique. si todos los objetivos especificados están actualizados. Si es así, la compilación se completa correctamente, como de costumbre. Sin embargo, si alguno de los archivos está desactualizado, en lugar de compilarse, se informa un error y la compilación falla. Esta opción puede ser útil para determinar si se realizó una compilación más recientemente que una edición de fuente (por ejemplo, para verificaciones previas al envío) 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 sintaxis de los archivos fuente en IDEs, por ejemplo, volviendo a compilar un solo destino que depende del archivo fuente para detectar errores lo antes posible en el ciclo de edición, compilación y prueba. Este argumento afecta la forma en que se interpretan todos los argumentos que no son de marca: cada argumento debe ser una etiqueta de destino de archivo o un nombre de archivo simple en relación con el directorio de trabajo actual, y se compila una regla que depende de cada nombre de archivo de origen. Para C++ y Java fuentes, las reglas en el mismo espacio de idioma se eligen preferentemente. Para varias reglas con la misma preferencia, se elige la que aparece primero en el archivo BUILD. Un patrón de destino con un nombre explícito que no hace referencia a un archivo fuente genera un error.

--save_temps

La opción --save_temps hace que las salidas temporales del compilador se guardado. Estos incluyen archivos .s (código del ensamblador), .i (C preprocesado) y .ii (C++ preprocesado). Estos resultados suelen ser útiles para la depuración. Los archivos temporales solo se generarán para el conjunto de destinos especificados en la línea de comandos.

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

Para asegurarte de que Bazel imprima la ubicación de los archivos de salida adicionales, verifica lo siguiente: tu --show_result n es lo suficientemente alto.

--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 ninguna etiqueta excluida. El filtro de etiquetas de compilación se especifica como una lista de palabras clave de etiquetas separadas por comas, opcionalmente, precedida del signo "-" que se usa para indicar las etiquetas excluidas. Las etiquetas obligatorias también pueden tener un signo "+" anterior.

Cuando se ejecutan pruebas, Bazel ignora --build_tag_filters para los destinos de prueba. que se crean y ejecutan incluso si no coinciden con este filtro. Para evitar compilarlos, filtra los objetivos de prueba con --test_tag_filters o excluyéndolos de forma explícita.

--test_size_filters=size[,size]*

Si se especifica, Bazel hará pruebas (o compilará si es --build_tests_only). probar únicamente objetivos con el tamaño determinado. El filtro de tamaño de prueba se especifica como una lista delimitada por comas de valores de tamaño de prueba permitidos (pequeño, mediano, grande o enorme), opcionalmente precedido por el signo “-” que se usa para indicar 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 filtrado de tamaño de las pruebas.

--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. Prueba el filtro de tiempo de espera 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 “-” signo que se usa para indicar tiempos de espera de prueba excluidos. Consulta --test_size_filters para ver un ejemplo de sintaxis.

De forma predeterminada, no se aplica el filtrado 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 de ellas) y no tengan etiquetas excluidas. El filtro de etiquetas de prueba se especifica como una lista de palabras clave de etiquetas separadas por comas, opcionalmente, precedida del signo "-" que se usa para indicar las etiquetas excluidas. Las etiquetas obligatorias también pueden tener un signo "+" antes del signo "+" .

Por ejemplo:

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

probará los objetivos etiquetados con performance o stress, pero no están etiquetadas con la etiqueta flaky.

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

--test_lang_filters=string[,string]*

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

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

solo probará los objetivos 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 de foo_test y bar_test.

--test_filter=filter-expression

Especifica un filtro que el ejecutor de pruebas puede usar para 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. En algunos casos, solo se ejecutan ciertos métodos de prueba.

La interpretación particular de filter-expression depende del framework de pruebas responsable de ejecutar la prueba. Puede ser un glob, una subcadena o una regex. --test_filter es una comodidad para pasar diferentes argumentos de filtro --test_arg, pero no todos los frameworks lo admiten.

Verbosidad

Estas opciones controlan la verbosidad del resultado 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 verificador de dependencias en la fase de ejecución de bazel build para explicar, para cada paso de compilación, ya sea por qué se está ejecutando o de que esté actualizado. La explicación está escrita a logfile.

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

--verbose_explanations

Esta opción aumenta la verbosidad de las explicaciones generadas. cuando la opción --explain está habilitada.

En particular, si se habilitan las explicaciones detalladas, y se vuelve a compilar un archivo de salida cambió, entonces el resultado en el archivo de explicación incluye todos los detalles del nuevo comando (al menos para la mayoría de 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, entonces --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 pueden analizarse con el Comando bazel analyze-profile. El perfil de compilación puede ser útil en Comprender en qué dedica tiempo el comando build de Bazel

--[no]show_loading_progress

Esta opción hace que Bazel muestre el progreso de carga de paquetes. mensajes nuevos. Si está inhabilitada, no se mostrarán los mensajes.

--[no]show_progress

Esta opción hace que se muestren los mensajes de progreso. se activa de forma predeterminada. Cuando se inhabilita, se suprimen los mensajes de progreso.

--show_progress_rate_limit=n

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

--show_result=n

Esta opción controla la impresión de la información de los resultados al final de un comando bazel build. De forma predeterminada, si un solo de compilación específica, Bazel imprime un mensaje que indica si el objetivo se actualizó con éxito y, de ser así, la lista de archivos de salida que creó el destino. Si se especificaron varios objetivos, no se mostrará la información de los resultados.

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

Es posible que los usuarios deseen elegir un valor intermedio si alternan con frecuencia entre la compilación de 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 espacio 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 caso es menos útil. Al igual que con todas las opciones, esto se puede especificar de forma implícita a través del archivo .bazelrc.

Los archivos se imprimen para que sea fácil copiar y pegar nombre de archivo al shell para ejecutar ejecutables compilados. Las secuencias de comandos que generan una compilación pueden analizar fácilmente los mensajes "actualizados" o "con errores" de cada destino.

--sandbox_debug

Esta opción hace que Bazel imprima información de depuración adicional cuando usa la zona de pruebas para acciones. ejecución. Esta opción también conserva los directorios de la zona de pruebas, de modo que los archivos sean 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 ejecutarlo.

  >>>>> # //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 compatible con la shell de Bourne para que se puedan copiar y pegar fácilmente en un símbolo del sistema de shell. (Los paréntesis que lo rodean 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. No hay una línea de comandos para mostrar estos elementos.

Es posible que se pase --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.

Para 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 útil para depurar una compilación que falla.

Los comandos que fallan se imprimen en una sintaxis compatible con la shell de Bourne, adecuada para copiar y pegar en un mensaje de shell.

Estado del lugar de trabajo

Usa estas opciones para “timbrar” los objetos binarios compilados con Bazel: para incorporar información adicional en los objetos binarios, como la revisión del control de código fuente o cualquier otra información relacionada con el lugar de trabajo. Puedes usar este mecanismo con reglas que admiten el atributo stamp, como genrule, cc_binary y otros

--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 actual del control del código fuente.

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

El programa debe imprimir cero o más pares clave-valor en el resultado estándar, una entrada en cada línea. y salir con cero (de lo contrario, la compilación fallará). Los nombres de las claves pueden ser cualquier cosa, 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 "volátil". (Los nombres "stable" y “volátil” son un poco contradictorias, así que no lo piensen mucho).

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:

• “estable” claves los valores deberían cambiar rara vez, si es posible. Si el contenido de bazel-out/stable-status.txt cambio, Bazel invalida las acciones que dependen de ellos. En en otras palabras, si cambia el valor de una clave estable, Bazel volverá a ejecutar las acciones con sellado. Por lo tanto, el estado estable no debería incluir marcas de tiempo, la hora y haría que Bazel vuelva a ejecutar las acciones marcadas con cada compilación.

  Bazel siempre genera las siguientes claves estables:

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

• “volátil” claves los valores pueden cambiar con frecuencia. Bazel espera que cambien todo el tiempo, como las marcas de tiempo y, debidamente, actualizan bazel-out/volatile-status.txt . Con el fin de evitar volver a ejecutar acciones selladas todo el tiempo, Bazel simula que el archivo volátil nunca de la configuración. En otras palabras, si el archivo de estado volátil es el único cuyo contenido cambió, Bazel no invalidará las acciones que dependen de él. Si otras entradas de las acciones cambiaron, Bazel vuelve a ejecutar esa acción y esta verá el estado de estado, pero solo el cambio de estado volátil no invalidará la acción.

  Bazel siempre genera las siguientes claves volátiles:

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

En Linux/macOS, puedes pasar --workspace_status_command=/bin/true a inhabilita la recuperación del estado del espacio de trabajo porque true no realiza ninguna acción correctamente (se cierra con cero) y no imprime ningún resultado. En Windows, puedes pasar la ruta de acceso de true.exe de MSYS para obtener el mismo efecto.

Si el comando de estado del espacio de trabajo falla (sale con un valor distinto de cero) por algún motivo, la compilación fallará.

Ejemplo de programa 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 acceso 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 incorpora información de compilación en objetos binarios.

El sellado se puede habilitar o inhabilitar de forma explícita por regla con el atributo stamp. Consulta la Enciclopedia de compilación para obtener más detalles. Cuándo una regla establece stamp = -1 (el valor predeterminado para reglas de *_binary); esta opción determina si los sellos se habilitan.

Bazel nunca marca los objetos binarios que se compilan para la configuración de ejecución, independientemente de esta opción o del atributo stamp. En las reglas que establecen stamp = 0 (la configuración predeterminada de las reglas *_test), el sello está inhabilitado, independientemente de la --[no]stamp Especificar --stamp no fuerza la recompilación de los objetivos en los siguientes casos: sus dependencias no han cambiado.

Por lo general, la configuración de --nostamp es conveniente para el rendimiento de la compilación, ya que reduce la volatilidad de entrada y maximiza el almacenamiento en caché de compilaciones.

Plataforma

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

Consulta la información de referencia sobre las plataformas y las 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

Es la etiqueta de una regla de la 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 un patrón de objetivo. Estas plataformas se considerarán antes de las declaradas en los archivos MODULE.bazel por register_execution_platforms(). Esta opción acepta una lista de plataformas separadas por comas en orden de prioridad. Si se pasa la marca varias veces, se anula la más reciente.

--extra_toolchains=labels

Las reglas de la cadena de herramientas que se deben considerar durante su resolución. Cadenas de herramientas puede especificarse por objetivo exacto o como un patrón de objetivo. Estas cadenas de herramientas serán considerados antes de los declarados en archivos MODULE.bazel por register_toolchains().

--toolchain_resolution_debug=regex

Imprime información de depuración mientras buscas cadenas de herramientas si el tipo de cadena de herramientas coincide la regex. Puedes separar varias regex con comas. Para negar la regex, usa un - al principio. Esto podría ayudar a los desarrolladores de reglas de Bazel o Starlark con fallas de depuración debido a cadenas de herramientas faltantes.

Varios

--flag_alias=alias_name=target_path

Una marca de conveniencia que se usa para vincular la configuración de compilación de Starlark más larga a un nombre más corto. Para ver más detalles, consulta la Configuración de Starlark.

--symlink_prefix=string

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

Si los vínculos simbólicos no se pueden crear por algún motivo, se mostrará una advertencia pero la compilación aún se considera un éxito. En particular, te permite compilar en un directorio de solo lectura o en uno que permiso para escribir. Cualquier ruta impresa en datos informativos mensajes al final de una compilación solo se usarán symlink-relativo de forma corta si estos apuntan a la respuesta ubicación, en otras palabras, puedes confiar en la precisión de esas de rutas de acceso, incluso si no puedes confiar en los symlinks que se crean.

Estos son algunos valores comunes de esta opción:

• Suprimir la creación de symlinks: --symlink_prefix=/ hará que Bazel no lo haga. crear o actualizar cualquier symlink, incluidos bazel-out y bazel-<workspace> symlinks. 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étera) dentro de un directorio oculto .bazel.

--platform_suffix=string

Agrega un sufijo al nombre corto de la configuración, que se usa para determinar el directorio de salida. Si configuras esta opción en diferentes valores, los archivos se colocan en directorios diferentes, por ejemplo, para mejorar las tasas de acierto de la caché de compilaciones que, de otro modo, se superponen entre sí, o para mantener los archivos de salida 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 se documenta para que sea más completo.

--starlark_cpu_profile=_file_

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

Usa esta opción para identificar las funciones de Starlark que hacen que la carga y el análisis sean lentos debido a un procesamiento 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 obtener diferentes vistas de los mismos datos, prueba los comandos pprof svg, web y list.

Usa Bazel para las versiones

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

Opciones significativas

Cuando se usa Bazel para compilaciones de lanzamiento, surgen los mismos problemas que con otras secuencias de comandos que realizan una compilación. Para obtener más detalles, consulta Cómo llamar a Bazel desde 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: para administrar compilaciones para múltiples configuraciones, puede ser conveniente distinguir cada compilación con un identificador distinto, como “64bit” en comparación con “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 de el nombre de los objetivos de prueba.

De forma predeterminada, este comando realiza actividades de compilación y prueba simultáneas, compila todos los destinos especificados (incluidos los destinos que no son de prueba especificados en la línea de comandos) y prueba los destinos *_test y test_suite apenas se compilan sus requisitos previos, lo que significa que la ejecución de pruebas se intercala con la compilación. Hacerlo generalmente da como resultado un significativo aumentos de velocidad.

Opciones para bazel test

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

Si esta opción se establece en "auto" (la opción predeterminada), Bazel solo volverá a ejecutar una prueba si se aplica alguna de las siguientes condiciones:

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

Si es "no", todas las pruebas se ejecutarán de forma incondicional.

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

Los usuarios que habilitaron esta opción de forma predeterminada en su archivo .bazelrc puede encontrar la Abreviaturas -t (activada) o -t- (desactivada) conveniente para anular el valor predeterminado en una ejecución determinada.

--check_tests_up_to_date

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

Esta opción también implica --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 avise explícitamente al usuario si el tiempo de espera de una prueba es considerablemente más largo que el tiempo de ejecución real de la prueba. Si bien el tiempo de espera de una prueba debe establecerse de modo que no sea inestable, una prueba que tiene un tiempo de espera muy 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 de ETERNAL o LONG, ya que son demasiado generosos.

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

--[no]test_keep_going

De forma predeterminada, todas las pruebas se ejecutan hasta completarse. Si esta marca está inhabilitada, Sin embargo, la compilación se anula en cualquier prueba que no se apruebe. Pasos de compilación posteriores no se ejecutan las invocaciones de prueba y se cancelan las que están en tránsito. 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 al principio, pero que eventualmente se informa como FLAKY en el resumen de la prueba. Sí, Sin embargo, se considera que se aprobó 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 que fracasó.

De forma predeterminada (cuando esta opción no se especifica o cuando está configurada en (opción predeterminada), se permite un solo intento para las pruebas regulares 3 para las reglas de prueba con el atributo flaky configurado Puedes especificar un valor de número entero para anular el límite máximo de intentos de prueba. Bazel permite realizar 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. Todo Las ejecuciones de prueba se tratan como pruebas independientes (funcionalidad de resguardo). se aplicará a cada uno de ellos de forma independiente).

El estado de un objetivo con ejecuciones fallidas depende del valor de la marca --runs_per_test_detects_flakes:

• Si está ausente, cualquier ejecución con errores hace que falle toda la prueba.
• Si está presente y dos ejecuciones del mismo fragmento muestran los resultados APROBADA y NO APROBADA, la prueba recibirá un estado de inestable (a menos que otras ejecuciones con errores la hagan fallar).

Si se especifica un solo número, todas las pruebas se ejecutarán esa cantidad de veces. Como alternativa, se puede especificar una expresión regular con la sintaxis expresión_regular@número. 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 en //pizza/ 4 veces). Este tipo de --runs_per_test se puede especificar más de una vez.

--[no]runs_per_test_detects_flakes

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

--test_summary=output_style

Especifica cómo se debe mostrar el resumen de los resultados de la prueba.

• short imprime los resultados de cada prueba junto con el nombre de el archivo que contiene el resultado de la prueba si esta falló. Este es el valor predeterminado.
• terse es como short, pero aún más breve: solo imprime información sobre las pruebas que no se aprobaron.
• detailed imprime cada caso de prueba individual que falló, no solo cada prueba. Se omiten los nombres de los archivos de salida de la prueba.
• none no imprime el 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 cada prueba se aprobó o no. También se muestra el nombre del archivo de registro de salida para las pruebas fallidas. Resumen se imprimirán al final de la construcción (durante la construcción, solo mensajes de progreso simples cuando las pruebas comienzan, se aprueban o fallan). Este es el comportamiento predeterminado.
• errors envía resultados stdout/stderr combinados de pruebas fallidas. solo en stdout inmediatamente después de que se complete la prueba, lo que garantiza que la salida 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 el resultado de todas las pruebas, incluidas las que se aprobaron.
• streamed transmite el resultado de stdout/stderr de cada prueba en tiempo real.

--java_debug

Esta opción hace que la máquina virtual de 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, el estado y el indicador de prueba almacenado en caché, y tendrá el formato para mantenerse dentro de 80 caracteres cuando sea posible.

--test_tmpdir=path

Especifica el directorio temporal para las pruebas que se ejecutan de forma local. Cada prueba se ejecuta en un subdirectorio separado dentro de este directorio. El directorio al principio de cada comando bazel test. De forma predeterminada, bazel colocará este directorio en el directorio base de salida de Bazel.

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

Anula el valor del tiempo de espera para todas las pruebas mediante el número especificado de segundos como un nuevo valor de tiempo de espera. 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 especifiquen tiempos de espera individuales para pruebas cortas, moderadas, largas y eternas (en ese orden). En cualquiera de los formatos, cero o un valor negativo para cualquiera de los tamaños de prueba se reemplazará por el tiempo de espera predeterminado para las categorías de tiempo de espera determinadas, como se define en la página Writing Tests. De forma predeterminada, Bazel usará estos tiempos de espera para todas las pruebas antes del inferir el límite de tiempo de espera a partir del tamaño de la prueba si el tamaño es establecida de forma implícita o explícita.

Las pruebas que indiquen explícitamente su categoría de tiempo de espera como distinta de su tamaño recibirán el mismo valor que si la etiqueta de tamaño hubiera establecido ese tiempo de espera de forma implícita. Por lo tanto, una prueba de tamaño "pequeño" que declara un tiempo de espera "largo" tendrá el mismo tiempo de espera efectivo que una prueba "grande" sin un 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.

Ten en cuenta que, a diferencia del comando bazel run, no puedes pasar argumentos de prueba directamente como en bazel test -- target --logtostderr --v=3. Esto se debe a que Los argumentos extraños que se pasan a bazel test se interpretan como una prueba adicional. objetivos. Es decir, --logtostderr y --v=3 se interpretarían como un objetivo de prueba. Esta ambigüedad no existe para un comando bazel run, que solo acepta un objetivo.

Se puede pasar --test_arg a un comando bazel run, pero se ignora, a menos que el objetivo que se ejecuta sea un objetivo de prueba. (Al igual que con cualquier otra marca, si se pasa en un comando bazel run después de un token --, Bazel no lo procesa, sino que lo reenvía de forma literal al destino ejecutado).

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

Especifica las variables adicionales que se deben insertar en la prueba para cada prueba. Si no se especifica value, se aplicará del entorno de shell que se usa para iniciar la bazel test kubectl.

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

--run_under=command-prefix

Esto especifica un prefijo que el ejecutor de pruebas insertará antes del comando de prueba antes de ejecutarlo. El command-prefix se divide en palabras con las reglas de tokenización de la shell de Bourne y, luego, la lista de palabras se agrega al principio del comando que se ejecutará.

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

Se deben tener en cuenta algunas advertencias:

• La ruta de acceso que se usa para ejecutar pruebas puede ser diferente a la de tu entorno. por lo que quizás debas usar una ruta de acceso absoluta para --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'

Probar la selección

Como se documenta en Opciones de selección de salida, puedes filtrar las 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.

Ejecución de ejecutables

El comando bazel run es similar a bazel build, excepto se usa para compilar y ejecutar un solo destino. Esta es una sesión típica (//java/myapp:myapp dice hola e imprime sus argumentos):

  % bazel run java/myapp:myapp -- --arg1 --arg2
  INFO: Analyzed target //java/myapp:myapp (13 packages loaded, 27 targets configured).
  INFO: Found 1 target...
  Target //java/myapp:myapp up-to-date:
    bazel-bin/java/myapp/myapp
  INFO: Elapsed time: 14.290s, Critical Path: 5.54s, ...
  INFO: Build completed successfully, 4 total actions
  INFO: Running command line: bazel-bin/java/myapp/myapp <args omitted>
  Hello there
  $EXEC_ROOT/java/myapp/myapp
  --arg1
  --arg2

bazel run es similar, pero no idéntico, a invocar directamente el objeto binario que compiló Bazel y su comportamiento es diferente dependiendo de si binario que se invocará es una prueba o no.

Cuando el objeto binario no sea una prueba, el directorio de trabajo actual será el árbol de archivos de ejecución del objeto binario.

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

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 la que el elemento se ejecutó la compilación.
• BUILD_WORKING_DIRECTORY: Es el directorio de trabajo actual en el que desde donde se ejecutó Bazel.

Estos se pueden usar, por ejemplo, para interpretar nombres de archivos en la línea de comandos en una forma fácil de usar.

Opciones para bazel run

--run_under=command-prefix

Esto tiene el mismo efecto que la opción --run_under para bazel test (consulta más arriba), excepto que se aplica al comando que ejecuta bazel run en lugar de a las pruebas que ejecuta bazel test y no se puede ejecutar con la etiqueta.

Cómo filtrar los resultados de registro de Bazel

Cuando se invoca un objeto binario con bazel run, Bazel imprime el resultado de registro de Bazel. y el objeto binario en invocación. Para que los registros sean menos ruidosos, puedes suprimir los resultados 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, lo que tiene el efecto de ejecutar la prueba en una aproximación cercana al entorno que se describe en Cómo escribir pruebas. Ten en cuenta que ninguno de los Los argumentos --test_* tienen un efecto cuando se ejecuta una prueba de esta manera, excepto --test_arg

Cómo limpiar los resultados de la compilación

El comando clean

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

Recuerda que cada instancia de Bazel está asociada a un único espacio de trabajo, por lo que El comando clean borrará todos los resultados de todas las compilaciones que hiciste con esa instancia de Bazel en ese espacio de trabajo.

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

  % bazel clean --expunge

Como alternativa, puedes eliminar definitivamente en segundo plano con --expunge_async Es seguro invocar un comando de Bazel en el mismo cliente mientras se ejecuta la eliminación definitiva asíncrona.

El comando clean se proporciona principalmente como un medio para realizar las siguientes acciones: o a recuperar espacio en disco para lugares de trabajo que ya no se necesitan. Es posible que las recompilaciones incrementales de Bazel no sean perfecto, de modo que se pueda usar clean para recuperar un cuando surgen problemas.

El diseño de Bazel es tal que estos problemas se pueden solucionar y estos errores son de alta prioridad. Si 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 gráfico de la dependencia

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

El lenguaje de consulta se basa en la idea de operaciones algebraicas sobre gráficos; se documenta en detalle en

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

La herramienta de consultas acepta varias de 12 a 1 con la nueva opción de compresión. --output selecciona el formato de salida. --[no]keep_going (inhabilitado de forma predeterminada) causa la consulta para seguir progresando en caso de errores; es posible que este comportamiento puede inhabilitarse si un resultado incompleto no es aceptable en caso de errores.

La opción --[no]tool_deps, que está habilitada de forma predeterminada, hace que las dependencias en configuraciones que no son de 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, causa las dependencias implícitas que se incluirán en el gráfico de dependencias en el que opera la consulta. Una dependencia implícita es aquella que no se especifica de forma explícita en el archivo BUILD, pero que agrega Bazel.

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

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

Consulta el gráfico de acciones

El comando aquery te permite consultar acciones en tu gráfico de compilación. Opera en el gráfico 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 línea de comandos. --output selecciona el formato de salida. El formato de salida predeterminado (text) es legible por humanos, usa proto o textproto para legible por máquina. En particular, el comando aquery se ejecuta sobre una compilación normal de Bazel y hereda el conjunto de opciones disponibles durante una compilación.

Admite el mismo conjunto de funciones que también está disponible para los query pero siblings, buildfiles y tests

Para obtener más detalles, consulta Consulta de gráfico de acciones.

Comandos y opciones varios

help

El comando help proporciona ayuda en línea. De forma predeterminada, muestra un resumen de los comandos y temas de ayuda disponibles, como se muestra en Cómo compilar con Bazel. Si especificas un argumento, se mostrará ayuda detallada sobre 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 para 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 opción.

shutdown

Los procesos del servidor de Bazel se pueden detener con el comando shutdown. Este comando hace que el servidor de Bazel se cierre en cuanto se vuelve inactivo (por ejemplo, después de que se completen las compilaciones o otros comandos que estén en curso). Para obtener más información, consulta la sección sobre implementación de cliente-servidor.

Los servidores de Bazel se detienen después de un tiempo de espera de inactividad, por lo que este comando rara vez es necesario; Sin embargo, puede ser útil en secuencias de comandos cuando sepa que no habrá más compilaciones en un espacio 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 apagado dependa de la cantidad de memoria que ya se consumió. Este es útil para secuencias de comandos que inician muchas compilaciones, como cualquier en el servidor de Bazel podría causar que falle de manera falsa en occasion; 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. (Las secuencias de comandos que impulsan una compilación pueden usarlas).

El comando info también permite un único (opcional) que es el nombre de una de las claves de la siguiente lista. En este caso, bazel info key solo imprimirá el valor de esa clave. (Esto es especialmente conveniente cuando se escribe una 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 este Bazel. o “versión de desarrollo” Si este no es un producto binario.
• workspace: Es la ruta de acceso absoluta al lugar de trabajo base. .

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

• output_base: Es la ruta de acceso absoluta al resultado base. que usa esta instancia de Bazel para el usuario actual y Workspace. Bazel pone a prueba sus recursos de salida debajo de este directorio.

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

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

• server_pid: Es el ID de proceso del servidor de Bazel. el proceso de administración de recursos.

• 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 el ciclo de vida del servidor Bazel y está diseñado para el consumo humano por parte de desarrolladores y power users de Bazel.

• command_log: Es la ruta de acceso absoluta al archivo de registro de comandos. Contiene los flujos intercalados de stdout y stderr del comando Bazel más reciente. Ten en cuenta que, si ejecutas bazel info, se reemplazará el 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 y max-heap-size: Informa varios parámetros de tamaño del montón de JVM. Respectivamente: memoria en uso y memoria actualmente garantiza que esté disponible para la JVM desde el sistema, se garantiza posible asignación.

• gc-count, gc-time: El recuento acumulativo de recogidas de elementos no utilizados desde el inicio de este servidor de Bazel y el tiempo empleado realizarlas. Ten en cuenta que estos valores no se restablecen al comienzo de cada compilar.

• package_path: Es una lista de rutas separadas por dos puntos en las que Bazel buscaría paquetes. Tenga el mismo formato que el Es el argumento de la 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 pasadas a bazel info, por por ejemplo, --cpu, --compilation_mode, etc. El comando info acepta todas las opciones que controlan las dependencias análisis, ya que algunos determinan la ubicación de la directorio de salida de una compilación, la elección del compilador, etcétera.

• bazel-bin, bazel-testlogs, bazel-genfiles: Informa la ruta absoluta a los directorios bazel-* en los que los programas generados por la compilación. Por lo general, aunque no siempre, es el 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 “Make” completo. Si la marca --show_make_env es especificada, todas las variables en el campo "Make" de la configuración actual medio ambiente (como CC, GLIBC_VERSION, etc.). Estas son las variables a las que se accede con el $(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 será correcto incluso en los casos Por algún motivo, no se puede crear el symlink bazel-bin (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 Bazel compilado. binario, incluida la lista de cambios en la que se compiló y la fecha. Son particularmente útiles para determinar si tienes la versión más reciente Bazel o si estás informando errores. Algunos de los valores interesantes son:

• 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 lanzado. Es muy útil cuando se informan errores.

bazel --version, sin otros argumentos, emitirá el mismo resultado que bazel version --gnu_format, excepto sin el efecto secundario de iniciar 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 ejecutan ART.

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

Se admiten las siguientes opciones:

--incremental

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

Si usas un dispositivo con Marshmallow o versiones posteriores, considera usar 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 en dispositivos con Marshmallow o versiones posteriores. Ten en cuenta que la marca --incremental no es necesaria cuando usas --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 estado limpio después de la instalación. Equivale a --start=DEBUG.

--start=_start_type_

Cómo debe iniciarse la app después de instalarla Los parámetros _start_type_s admitidos son los siguientes:

• NO No inicia la app. Esta es la configuración predeterminada.
• COLD Inicia la app en un estado limpio después de la instalación.
• WARM Conserva y restablece el estado de la aplicación en las instalaciones incrementales.
• DEBUG Espera al depurador 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á.

Lo predeterminado es usar adb en el SDK de Android que especifica el --android_sdk

--adb_arg=serial

Argumentos adicionales para adb. Estos se colocan 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 se usará, haz lo siguiente:

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

invoca adb como

adb -s deadbeef install ...

--incremental_install_verbosity=number

Es el nivel de detalle de la instalación incremental. Se establece en 1 para que el registro de depuración se imprima en la consola.

dump

El comando dump imprime en stdout un volcado de la estado interno del servidor de Bazel. Este comando está destinado principalmente a los 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 que describe 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 el contenido de la caché de acciones.
• --packages vuelca el contenido de la caché del paquete.
• --skyframe vuelca el estado del gráfico de dependencia interno de Bazel.
• --rules vuelca el resumen de la regla para cada regla y clase de aspecto, incluidos recuentos y 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 pprof compatible con la ruta de acceso especificada. Para que esto funcione, debes habilitar el seguimiento de memoria.

Seguimiento de la memoria

Algunos comandos dump requieren el seguimiento de la memoria. Para activar esta opción, debes pasar 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

El java-agent se registra en Bazel en third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar, así que asegúrate asegúrate de ajustar $BAZEL según la ubicación en la que guardas 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 recopilado anteriormente 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 tiene el mismo efecto. La nueva lista de opciones es canónica. Por ejemplo: dos listas de opciones con el mismo efecto se convierten en canónicas 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 dado no admite generan un error.

A continuación, se muestra un ejemplo:

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

Opciones de inicio

Las opciones descritas en esta sección afectan el inicio de Java virtual que usa el proceso del servidor de Bazel y se aplican a todas comandos posteriores manejados por ese servidor. Si ya hay un servidor Bazel en ejecución y las opciones de inicio no coinciden, se reiniciará.

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

--output_base=dir

Esta opción requiere un argumento de ruta de acceso, que debe especificar un que admite escritura. Bazel usará esta ubicación para escribir todos sus salida. La base de salida también es la clave por la que el cliente localiza el servidor de Bazel. Cuando cambias la base de salida, cambias el servidor que manejará el comando.

De forma predeterminada, la base de salida se deriva del nombre de acceso del usuario y del nombre del directorio del espacio de trabajo (en realidad, su resumen MD5), por lo que un valor típico se ve de la siguiente manera: /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 simultáneamente (debido a el operador & de shell), cada uno con un Bazel diferente de un servidor web (debido a las diferentes bases de salida). Por el contrario, si se usó la base de salida predeterminada en ambos comandos, ambas solicitudes se enviarían al mismo servidor, lo que controlarlos de forma secuencial: compilar //foo primero y, luego, seguir por una compilación incremental de //bar.

--output_user_root=dir

Apunta al directorio raíz en el que se crean las bases de salida e instalación. El directorio no debe existir o debe ser propiedad del usuario que realiza la llamada. En el pasado, esto podía apuntar a un directorio compartido entre varios usuarios, pero ya no se permite. Esto se podría permitir una vez que se resuelva el problema #11100.

Si se especifica la opción --output_base, se anula el uso de --output_user_root para calcular la base de salida.

La ubicación de la base de instalaciones se calcula en función de lo siguiente: --output_user_root, más la identidad MD5 de Bazel incorporado binarios.

Puedes usar la opción --output_user_root para elegir una ubicación de base alternativa para todo el resultado de Bazel (base de instalación y base de salida) si hay una ubicación mejor en el diseño de tu sistema de archivos.

--server_javabase=dir

Especifica la máquina virtual de Java en la que se ejecuta Bazel. El valor debe ser una ruta de acceso al directorio que contiene un JDK o JRE. No debe ser una etiqueta. Esta opción debería 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 las aplicaciones, las pruebas y herramientas, etcétera. Usa las opciones de compilación --javabase o --host_javabase en su lugar.

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

--host_jvm_args=string

Especifica una opción de inicio que se pasará a la máquina virtual Java en la que Bazel o en cualquier plataforma que ejecute Knative. Esto se puede usar para establecer 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 rara vez se necesitará configurar esta marca. También puedes pasar una lista separada por espacios de cadenas, cada uno de los cuales se interpretará como un argumento de JVM independiente, pero esta función pronto se obsoleto.

Que esto no afecta a ninguna JVM que use subprocesos de Bazel: aplicaciones, pruebas, herramientas, etcétera. Para pasar opciones de JVM a programas Java ejecutables, ya sea que se ejecuten con 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 desde un depurador compatible con JDWP antes de llamar al método principal de Bazel. Esto es principalmente para desarrolladores de Bazel.

--autodetect_server_javabase

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

--batch

El modo por lotes hace que Bazel no use el modo cliente-servidor estándar, sino que ejecute un proceso de Java de Bazel para un solo comando, que se usó para una semántica más predecible con respecto al manejo de indicadores, el control de trabajos y la herencia de variables de entorno, y es necesario para ejecutar Bazel en una cárcel de chroot.

El modo por lotes conserva la semántica de cola adecuada dentro de la misma base de salida. Es decir, las invocaciones simultáneas se procesarán en orden, sin superposición. Si se ejecuta un Bazel en modo por lotes en un cliente con un servidor en ejecución, primero se mata el servidor antes de procesar el comando.

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

--max_idle_secs=n

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

Las secuencias de comandos que invocan a Bazel pueden usar esta opción para garantizar que No dejan 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 Invoca bazel query para asegurarte de que el estado cambio no introduzca dependencias no deseadas. Sin embargo, si el usuario no realizó una compilación reciente en ese espacio de trabajo, no sería conveniente 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. Si especificas un valor pequeño de --max_idle_secs en el consulta, la secuencia de comandos puede garantizar que si provocó una nueva el servidor se inicie, ese servidor se cerrará de inmediato, pero si ya había un servidor en ejecución, ese servidor seguirá funcionando hasta que haya estado inactiva durante el tiempo habitual. Por supuesto, se restablecerá el temporizador de inactividad del servidor.

--[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 por un tiempo, apágalo cuando el sistema esté falta de memoria. Solo en Linux.

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

--[no]block_for_lock

Si está habilitado, Bazel esperará a que se completen otros comandos de Bazel que mantienen el bloqueo del servidor antes de continuar. Si está inhabilitada, Bazel se cerrará con un error si no puede adquirir el bloqueo de inmediato y continuar.

Los desarrolladores pueden usar esto en las comprobaciones 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 E/S de mejor esfuerzo. 0 es la prioridad más alta y 7 es la más baja. El programador anticipado solo puede respetar hasta 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 de trabajo no interactivas, pero que no desean reducir su valor. Ver '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 opciones de inicio y opciones de comandos de lectura. los archivos bazelrc durante el inicio.

--color (yes|no|auto)

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

Si esta opción se establece en yes, se habilita el resultado en color. Si esta opción se establece en auto, Bazel usará el resultado en color solo si el resultado se envía a una terminal y la variable de entorno TERM se establece en un valor que no sea dumb, emacs o xterm-mono. Si esta opción se establece en no, la salida de color estará inhabilitada, sin importar si el resultado se dirige a una terminal y sin importar de la configuración de la variable de entorno TERM.

--config=name

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

--curses (yes|no|auto)

Esta opción determina si Bazel usará los controles del cursor en el resultado de la pantalla. Como resultado, se generan menos datos de desplazamiento flujo de resultados compacto y fácil de leer de Bazel. Esto funciona bien con --color.

Si esta opción se establece en yes, se habilitará el uso de los controles del cursor. Si esta opción se establece en no, se inhabilita el uso de los controles del cursor. Si esta opción se establece en auto, se podrán usar los controles del cursor habilitado 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 especifica la hora en la que se mostró el mensaje.