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 del destino
Algunos comandos, como build
o test
, pueden operar en una lista de destinos. Ellas
usan una sintaxis más flexible que las etiquetas, que está documentada en
Cómo especificar destinos para compilar
Opciones
En las siguientes secciones, se describen las opciones disponibles durante un
compilar. Cuando se usa --long
en un comando de ayuda, la línea de comandos
de ayuda brindan información resumida 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 son identificado en la ayuda en línea con el texto "se puede utilizar 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 buscarán encontrar el archivo Build de un paquete determinado.
Para encontrar sus paquetes, Bazel busca en la ruta 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:
- Si el primer carácter es
/
, la ruta de acceso es absoluta. - Si la ruta comienza con
%workspace%
, se considera relativa al directorio de Bazel adjunto 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
. - Todo lo demás se toma en relación con el directorio de trabajo.
Esto no suele ser 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 se encuentre en directorio actual para que puedas compilar desde un Bazel vacío. workspace si todos los paquetes necesarios se pueden encontrar en otro lugar en la ruta del paquete.
Ejemplo: Compila a partir de un cliente vacío
% mkdir -p foo/bazel % cd foo/bazel % touch WORKSPACE % bazel build --package_path /some/other/path //foo
--deleted_packages
Esta opción especifica la lista de paquetes separados por comas que Bazel debería considerar borrarse 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.
Comprobación de errores
Estas opciones controlan la comprobación de errores o las advertencias de Bazel.
--[no]check_visibility
Si esta opción se establece como falsa, las verificaciones de visibilidad descienden a las 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 destino no
coinciden con la expresión regular dada y su ejecución se realiza correctamente, su código estándar
la salida y el error estándar se descartan.
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 lo invoque. para el procesamiento previo, la compilación o el ensamblaje de C, C++, 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 incluye un argumento que se pasará al compilador para los archivos fuente C
que se compilan en la configuración exec. Esto es similar a
la opción --conlyopt
, pero solo se aplica
a la configuración de ejecución.
--host_cxxopt=cc-option
Esta opción incluye un argumento que se pasará al compilador para los archivos de origen C++
que se compilan en la configuración exec. Esto es similar a
la opción --cxxopt
, pero se aplica solo a la
exec de configuración.
--host_linkopt=linker-option
Esta opción incluye un argumento que se pasará al vinculador para los archivos fuente
que se compilan en la configuración exec. Esto es similar a
la opción --linkopt
, pero solo se aplica a
la configuración de ejecución.
--conlyopt=cc-option
Esta opción incluye 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 en C.
y no a la compilación o vinculación de C++. Así, 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 compilar 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 en C. Para que puedas 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.
Es similar a --copt
, pero solo se aplica a las vinculaciones,
no a la compilación. Por lo tanto, puedes pasar opciones del compilador que solo tienen sentido.
en el momento de la vinculación (por ejemplo, -lssp
o -Wl,--wrap,abort
)
usando --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. Esta opción siempre prevalecerá la configuración. 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 que siempre se quitará 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 el valor de --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 se corresponde con la opción --strip-debug
de ld:
solo elimina la información de depuración. Si por alguna razón deseas quitar todos los símbolos, haz lo siguiente:
no solo símbolos de debug, debes usar la opción --strip-all
de ld,
lo que puedes hacer pasando --linkopt=-Wl,--strip-all
a Bazel. También debes
Ten en cuenta que configurar la marca --strip
de Bazel anulará
--linkopt=-Wl,--strip-all
, por lo que solo debes configurar uno de los dos.
Si solo estás compilando un objeto binario y quieres quitar todos los símbolos, también podrías
pasa --stripopt=--strip-all
y compila de forma explícita el
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
permite generar
Resultado del perfil de FDO (optimización dirigida por comentarios) cuando la
se ejecuta el objeto 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 de LLVM, el argumento también es el directorio en el que se encuentra el perfil de LLVM sin procesar.
archivos de datos se vuelcan. 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
información de perfil de archivo por objeto para realizar un FDO (comentarios
(optimización directa) 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 se identifican con la extensión .afdo.
Para el compilador de LLVM, el argumento proporcionado debe apuntar al LLVM indexado. archivo de salida del perfil preparado por la herramienta llvm-profdata, y debe tener una 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 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 8. -->
Los valores posibles son 8, 9, 10, 11, 14, 15 y 21, y se puede extender
registro de 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 8.
--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 de un repositorio remoto y ejecuta la aplicación de Java con él.
El valor predeterminado es local_jdk
.
Los valores posibles son local_jdk
, local_jdk_version
,
remotejdk_11
y remotejdk_17
.
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 una sola discusión 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 que los argumentos de opción se pasen a javac. Se puede usar con una sola discusión 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 gana cualquier opción de javac. Las opciones predeterminadas para javac son las siguientes:
-source 8 -target 8 -encoding UTF-8
--strict_java_deps (default|strict|off|warn|error)
Esta opción controla si javac busca dependencias directas faltantes. Los destinos de Java deben declarar explícitamente todos los destinos usados directamente como dependencias. Esta marca indica a javac que determine los archivos jar que realmente se usaron. para verificar el tipo de cada archivo Java y advertir o advertir si no son el resultado de una dependencia directa del objetivo actual.
off
significa que la verificación está inhabilitada.warn
significa que javac generará advertencias estándar de Java de escribe[strict]
para cada dependencia directa que falte.default
,strict
yerror
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 uno
un modo de compilación diferente, por lo que puedes alternar entre modos sin
necesitar hacer una recompilación completa cada vez.
fastbuild
significa compilar lo más rápido posible: generan información de depuración mínima (-gmlt -Wl,-S
) y no la optimizan. Es el valor predeterminado. Nota: No se establecerá-DNDEBUG
.dbg
significa compilar con la depuración habilitada (-g
). para que puedas usar gdb (o algún otro depurador).opt
significa compilar con la optimización habilitada y conassert()
llamadas inhabilitadas (-O2 -DNDEBUG
). No se generará la información de depuración en el modoopt
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 pueden especificarse por nombre, en cuyo caso el valor se tomará del
de invocación, o mediante el par name=value
, que establece el valor independientemente del
de invocación de código abierto.
Esta marca --action_env
se puede especificar varias veces. Si se asigna un valor al mismo
variable en varias marcas --action_env
, gana la última asignación.
--experimental_action_listener=label
La opción experimental_action_listener
le indica a Bazel que use
detalles de la regla action_listener
especificada por label 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 haga lo siguiente:
filtrar el conjunto de objetivos para los que se 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
; la etiqueta del propietario coincide con la especificada
expresión regular.
En el siguiente ejemplo, se limitará la programación de extra_actions
para que se aplique únicamente a las 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]*
Las plataformas para crear el deps
transitivo de
Reglas android_binary
(específicamente para dependencias nativas como C++) Para
ejemplo, si un cc_library
aparece en el deps
transitivo de una
android_binary
, se la compila una vez para cada plataforma especificada con
--android_platforms
para la regla android_binary
y se incluye en la
salida.
No hay un valor predeterminado para esta marca: se debe definidos y usados.
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 del
android_binary
es "foo", entonces el archivo es libfoo.so
.
--per_file_copt=[+-]regex[,[+-]regex]...@option[,option]...
Cuando está presente, cualquier archivo C++ con una etiqueta o una ruta de ejecución que coincida con una de las regex de inclusión
que no coincidan con ninguna de las expresiones de exclusión
con las opciones proporcionadas. La coincidencia de etiquetas usa la forma canónica de la etiqueta.
(es decir, //package
:label_name
).
La ruta de ejecución es la ruta de acceso relativa al directorio de tu lugar de trabajo, incluido el nombre base. (incluida la extensión) del archivo C++. También incluye cualquier prefijo que dependa de la plataforma.
Para hacer coincidir 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 cada
.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 usado. Por ejemplo, es posible
de compilar con --compilation_mode=opt
y compilar de forma selectiva algunos
archivos con una optimización más sólida activada o con la optimización inhabilitada.
Caveat: Si algunos archivos se compilan de forma selectiva con símbolos de depuración, los símbolos
pueden eliminarse 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
al comando.
Línea 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 dinámicamente, interactuando con el atributo linkstatic en las reglas de compilación.
Modos:
default
: Permite que Bazel elija si desea vincularse 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á 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 los tiempos de estos.
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 está habilitada.
universalmente. Cuando se establece en no
, Fission se inhabilita
universalmente. La cantidad predeterminada es no
.
--force_ignore_dash_static
Si se establece esta marca, cualquier opción de -static
en los linkopts de
Se ignorarán los archivos BUILD de reglas cc_*
. Esto solo está pensado para
una solución alternativa para las compilaciones de endurecimiento de C++.
--[no]force_pic
Si se habilitan, todas las compilaciones de C++ producen código independiente de la posición ("-fPIC"), los vínculos prefieren bibliotecas PIC preconstruidas antes que las que no son PIC ejecutables independientes de la posición ("-pie"). La opción predeterminada está inhabilitada.
--android_resource_shrinking
Selecciona si se deben reducir los 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 especifica, usa siempre la implementación de malloc determinada para anular todo
atributos malloc="target"
, incluidos los destinos que usan el elemento
predeterminado (sin especificar ningún malloc
)
--crosstool_top=label
Esta opción especifica la ubicación del paquete de compilación de crosstool.
para toda la compilación de C++ durante una compilación. Bazel buscará en eso
de un archivo CROSSTOOL y la usa para determinar automáticamente
Configuración de --compiler
.
--host_crosstool_top=label
Si no se especifica, Bazel usa el valor de --crosstool_top
para compilar.
código en la configuración de ejecución, como las herramientas que se ejecutan durante la compilación. El propósito principal de esta marca
es habilitar la compilación cruzada.
--apple_crosstool_top=label
El crosstool para compilar reglas de C/C++ en el deps
transitivo de
objc*, ios* y apple*. Para esos destinos, esta marca reemplaza
--crosstool_top
--compiler=version
Esta opción especifica la versión del compilador C/C++ (como gcc-4.1.0
).
que se usará para compilar objetos binarios durante la compilación. Si quieres
compilar con un crosstool personalizado, debes usar un archivo CROSSTOOL en lugar de
especificando esta marca.
--android_sdk=label
Obsoleta. Esto no debe especificarse directamente.
Esta opción especifica la cadena de herramientas del SDK de Android/plataforma. y la biblioteca de tiempo de ejecución de Android que se usará para compilar cualquier .
El SDK de Android se seleccionará automáticamente si un elemento android_sdk_repository
se define en el archivo WORKSPACE.
--java_toolchain=label
No-ops. Se mantiene solo para brindar 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, el efecto principal rápida de la compilación.
--spawn_strategy=strategy
Esta opción controla dónde y cómo se ejecutan los comandos.
standalone
hace que los comandos se ejecuten como subprocesos locales. Este valor es de obsoleto. En su lugar, utilizalocal
.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 atributossrcs
,data
ytools
. Bazel habilita la zona de pruebas local de forma predeterminada en los sistemas que admiten la ejecución de la zona de pruebas.local
hace que los comandos se ejecuten como subprocesos locales.worker
hace que los comandos se ejecuten con un trabajador persistente, si está disponible.docker
hace que los comandos se ejecuten dentro de la 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 el ejecutor remoto se configuró 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 los atributos admitidos
estrategias 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 Estrategialocal
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 estrategiasandboxed
, pero revertir el pedido lo ejecuta conlocal
. - Ejemplo: Ejecuciones de
--strategy_regexp='Compiling.*/bar=local,sandboxed'
"Cómo compilar //foo/bar/baz" con la estrategialocal
y recurre asandboxed
si falla
--genrule_strategy=strategy
Esta es una abreviatura obsoleta para --strategy=Genrule=strategy
.
--jobs=n
(-j)
Esta opción, que toma un argumento de número entero, especifica un límite para la cantidad de trabajos que se deben ejecutar 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 son
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 de cursor, como lo especifica
--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. Llevan
un número entero o una palabra clave (HOST_RAM o HOST_CPUS) opcionalmente seguida de [-|*
float]
(por ejemplo, --local_cpu_resources=2
, --local_ram_resources=HOST_RAM*.5
,
--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.
Puede ser útil usar --nobuild_runfile_links
para validar si todos los objetivos se compilan sin incurrir en sobrecarga
para construir los árboles de archivos de ejecución.
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/workspace/packagename/filename
El árbol de archivos de ejecución garantiza que las pruebas tengan acceso a todos los archivos
de los que tienen
dependencia declarada y nada más. De
de forma predeterminada, el árbol de archivos de ejecución se implementa construyendo un conjunto de
vínculos simbólicos a los archivos requeridos. 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 archivos de ejecución crearse de forma remota desde manifiestos en la 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, con lo que se libera memoria (alrededor del 10%) para la fase de ejecución. La desventaja es que las compilaciones incrementales adicionales serán más lentas. Consulta también 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 la primera si se detecta un error específico. 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 todos los destinos 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 la que java_library
objetivos
compilada por Bazel. 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 la interfaz, que crea objetos binarios y otras bibliotecas compartidas dependen de la interfaz de un objeto compartido en lugar de implementarlos. Cuando solo cambia la implementación, Bazel puede evitar la reconstrucción de objetivos que dependen de la biblioteca compartida modificada innecesariamente.
Selección de salida
Estas opciones determinan qué compilar o probar.
--[no]build
Esta opción hace que ocurra la fase de ejecución de la compilación. Está activado de forma predeterminada. Cuando está apagado, la fase de ejecución se se omiten y solo ocurren las dos primeras fases, la carga y el 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 *_test
.
y test_suite
reglas que no se filtraron debido a su
tamaño,
tiempo de espera,
etiqueta, o
idioma.
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.
solicitadas, incluidas las reglas *_test
y test_suite
que se filtraron de
y 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 algún archivo está fecha, en lugar de compilarse, se informa un error y la compilación falla. Esta opción puede ser útil para determinar si una compilación tiene se realizó de forma más reciente que una edición de origen (por ejemplo, para el envío previo sin incurrir en el costo de una compilación.
Consulta también --check_tests_up_to_date
.
--[no]compile_one_dependency
Compila una sola dependencia de los archivos de argumento. Esto es útil para sintácticamente revisa los archivos fuente en IDE, por ejemplo, a través de la recompilación de un solo destino que depende del archivo fuente para detectar errores lo antes posible posible en el ciclo de edición, compilación y prueba. Este argumento afecta la forma en que los argumentos que no son de marca se interpretan: cada argumento debe ser un una etiqueta de destino del archivo o un nombre de archivo sin formato en relación con la etiqueta 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, la que aparece primero en la Se eligió el archivo BUILD. Un patrón de destino con nombre explícito que no hacer 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 ensamblador), .i (preprocesado C) y .ii
(C++ previamente procesados). Estos resultados suelen ser útiles para la depuración. Las temperaturas solo serán
generados para el conjunto de objetivos 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. Etiqueta de compilación el filtro se especifica como una lista de palabras clave de etiqueta delimitada por comas, precedida por “-” que se usa para indicar las etiquetas excluidas. Las etiquetas obligatorias también pueden tener un signo "+" antes del signo "+" .
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 crearlos, filtra
probar destinos con --test_tag_filters
o excluirlos 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. Filtro de tamaño de la prueba
se especifica como una lista delimitada por comas de valores de tamaño de prueba permitidos (pequeño,
mediana, grande o enorme), opcionalmente precedida por “-” signo usado para denotar
los tamaños de prueba excluidos. Por ejemplo:
% bazel test --test_size_filters=small,medium //foo:all
y
% bazel test --test_size_filters=-large,-enormous //foo:all
solo probará pruebas pequeñas y medianas dentro de //foo.
De forma predeterminada, no se aplica el filtro de tamaño de las pruebas.
--test_timeout_filters=timeout[,timeout]*
Si se especifica, Bazel hará pruebas (o compilará si es --build_tests_only
).
solo debes probar los destinos con el tiempo de espera establecido. 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 usado para denotar
tiempos de espera de prueba excluidos. Consulta --test_size_filters
por ejemplo, la sintaxis.
De forma predeterminada, no se aplica el filtro de tiempo de espera de la prueba.
--test_tag_filters=tag[,tag]*
Si se especifica, Bazel hará pruebas (o compilará si es --build_tests_only
).
también se especifica) solo los destinos de prueba que tengan al menos una etiqueta obligatoria
(si se especifica alguna) y no tiene ninguna etiqueta excluida. Etiqueta de prueba
el filtro se especifica como una lista de palabras clave de etiqueta delimitada por comas,
precedida por “-” 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 string "foo". Bazel hará lo siguiente
Solo prueba (o compila si también se especifica --build_tests_only
)
objetivos de las clases de reglas a las que se hace referencia. Si, en cambio, deseas excluir esas orientaciones, usa
la cadena "-foo". Por ejemplo:
% bazel test --test_lang_filters=foo,bar //baz/...
solo probará los destinos que son instancias de foo_test
o bar_test
en
//baz/...
, mientras
% bazel test --test_lang_filters=-foo,-bar //baz/...
probará todos los destinos en //baz/...
, excepto foo_test
y
bar_test
instancias.
--test_filter=filter-expression
Especifica un filtro que el ejecutor de pruebas puede usar para seleccionar un subconjunto de pruebas en ejecución. Todos los destinos especificados en la invocación se compilan, pero según la expresión solo se pueden ejecutar algunos de ellos; en algunos casos, solo ciertos de prueba.
La interpretación particular de filter-expression depende de
el framework de prueba responsable de ejecutar la prueba. Puede ser un glob,
o regexp. --test_filter
es una conveniencia
pasar diferentes argumentos --test_arg
de filtro,
pero no todos los frameworks son compatibles con ella.
Verbosidad
Estas opciones controlan la verbosidad de la salida de Bazel, ya sea a la terminal o a 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 conllevar una pequeña penalización de rendimiento, por lo que le recomendamos que quite
cuando ya no se necesita.
--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).
Usar esta opción puede aumentar significativamente la duración de la
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
la creación de perfiles de datos 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, los mensajes no se mostrarán.
--[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 como máximo un mensaje de progreso cada 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 del resultado 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 hay varios
se especificaron los objetivos, no se muestra la información del resultado.
Si bien la información del resultado puede ser útil para compilaciones de una sola
o algunos objetivos, para compilaciones grandes (como un conjunto
árbol del proyecto), esta información puede ser abrumadora y distrae.
esta opción permite controlarlo. --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 muestra información
para objetivos individuales. Por lo tanto, cero genera el resultado
información se suprima siempre, y un valor muy grande causa
el resultado se debe imprimir siempre.
Es posible que los usuarios deseen elegir un valor intermedio si realizan
crear un pequeño grupo de objetivos (por ejemplo,
durante el ciclo de compilación, edición y prueba) y un gran grupo de objetivos
(por ejemplo, cuando estableces un nuevo lugar de trabajo o ejecutas
pruebas de regresión). En el primer caso, la información del resultado es
es muy útil mientras que, en el último caso, no lo es. Como con todos
esto se puede especificar implícitamente a través de
el archivo .bazelrc
.
Los archivos se imprimen para que sea fácil copiar y pegar nombre de archivo al shell para ejecutar ejecutables compilados. La herramienta "up-to-date" o “con errores” mensajes para cada destino se pueden analizar fácilmente con secuencias de comandos que impulsan una compilación.
--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 copiarlas y pegarlas fácilmente en el símbolo del sistema de la shell.
(Los paréntesis circundantes se proporcionan para proteger la shell del
Llamadas cd
y exec
. asegúrate de copiarlos).
Sin embargo, algunos comandos se implementan internamente en Bazel, como
crear árboles de symlinks. 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 comando largas sean más legibles.
Consulta también --verbose_failures a continuación.
Para registrar subcomandos en un archivo en un formato compatible con las herramientas, consulta --execution_log_json_file y --execution_log_binary_file.
--verbose_failures
Esta opción hace que la fase de ejecución de Bazel imprima la línea de comandos completa. para los comandos que fallaron. Esto puede ser muy valioso para depurar un o la compilación con errores.
Los comandos con errores se imprimen en una sintaxis compatible con la shell Bourne, para copiar y pegar en un prompt de shell.
Estado del lugar de trabajo
Usa estas opciones para "sellar" Objetos binarios compilados por Bazel: para incorporar información adicional en el
binarios, como la revisión del control de origen o alguna otra información relacionada con el espacio 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/macOS, esto puede ser cualquier ejecutable. En Windows, debe ser un objeto binario nativo, por lo general, un ".exe", ".bat" o un ".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 utiliza 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 puede 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 conSTABLE_
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
: valor de--embed_label
BUILD_HOST
: Es el nombre de la máquina anfitrión en la que se ejecuta BazelBUILD_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 archivo cuyo contenido tiene cambia, 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 el tiempo de compilación en segundos desde la época Unix (el valor deSystem.currentTimeMillis()
dividido por mil)FORMATTED_DATE
: La hora de la compilación con el formato deyyyy 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 lograr el mismo efecto.
Si el comando de estado del lugar de trabajo falla (salida de un valor distinto de cero) por cualquier motivo, la compilación fallará.
Programa de ejemplo en Linux con Git:
#!/bin/bash echo "CURRENT_TIME $(date +%s)" echo "RANDOM_HASH $(cat /proc/sys/kernel/random/uuid)" echo "STABLE_GIT_COMMIT $(git rev-parse HEAD)" echo "STABLE_USER_NAME $USER"
Pasa la ruta de 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 debe
Incorporar información de compilación en objetos binarios
El sello se puede habilitar o inhabilitar explícitamente por regla a través del
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 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
), se inhabilita el sello, 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
Usar estas opciones para controlar las plataformas host y de destino que configuran el funcionamiento de las compilaciones controlan qué plataformas de ejecución y cadenas de herramientas están disponibles para las reglas de Bazel.
Consulta la información general sobre Plataformas y Cadenas de herramientas.
--platforms=labels
Las etiquetas de las reglas de la plataforma que describen las plataformas de destino para el comando actual.
--host_platform=label
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. Estos plataformas se considerarán antes de las declaradas en el archivo WORKSPACE register_execution_platforms() Esta opción acepta una lista de plataformas separadas por comas en orden de prioridad. Si la marca se pasa varias veces, las anulaciones más recientes.
--extra_toolchains=labels
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 se considerarán antes de los declarados en el archivo WORKSPACE 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. Si hay varias regex, se pueden separar con comas. La regex puede ser
se nega mediante un -
al comienzo. Esto podría ayudar a los desarrolladores
de reglas de Bazel o Starlark con errores 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 de forma corta relativa de symlink si estos apuntan a la ruta esperada 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, incluidosbazel-out
ybazel-<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 llamadosbin
(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 la de salida. Configurar esta opción en diferentes valores coloca los archivos en directorios diferentes; por ejemplo, para mejorar las tasas de aciertos de caché de las compilaciones de lo contrario, cometan errores entre ellos o para mantener los archivos de salida para hacer comparaciones.
--default_visibility=(private|public)
Marca temporal para probar los cambios de visibilidad predeterminados de Bazel. No está diseñada para uso general pero documentados para completar el sake.
--starlark_cpu_profile=_file_
Esta marca, cuyo valor es el nombre de un archivo, hace que Bazel recopile estadísticas sobre el uso de CPU por parte de todos los subprocesos de Starlark y escribir el perfil en formato pprof al archivo nombrado.
Usa esta opción para ayudar a identificar las funciones de Starlark que ralentizan la carga y el análisis debido al 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 ver diferentes vistas de los mismos datos, prueba los comandos svg
de pprof
,
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 el lanzamiento ingenieros que usan Bazel.
Opciones importantes
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 Llama a Bazel desde secuencias de comandos. En particular, las siguientes opciones se recomienda lo siguiente:
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 symlinksbazel-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 compilaciones y pruebas simultáneas
y crea todos los objetivos especificados (incluso aquellos que no son de prueba
objetivos especificados en la línea de comandos) y probar
Objetivos *_test
y test_suite
en cuanto
se compilan sus requisitos previos, lo que significa que la ejecución de prueba
intercalado con la creación de código. 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 está configurada como "automática" (configuración predeterminada), Bazel solo volverá a ejecutar una prueba si se se aplican 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 la respuesta 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
salvo 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 simplemente verifique e informe los resultados de la prueba almacenados en caché. Si hay pruebas que no se realizaron compiladas y ejecutadas 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 como "SIN ESTADO" (en rojo, si la salida de color está habilitada), y devolverá 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 advierta explícitamente al usuario si el tiempo de espera de una prueba es significativamente más larga que el tiempo de ejecución real de la prueba. Mientras se prueba el tiempo de espera se debe establecer de manera tal que no sea inestable, una prueba que tiene un un tiempo de espera demasiado generoso puede ocultar problemas reales que surgen de forma inesperada.
Por ejemplo, una prueba que normalmente se ejecuta en uno o dos minutos no debería tener un tiempo de espera 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 valores de tiempo de espera existentes de la verificación de estado.
--[no]test_keep_going
De forma predeterminada, todas las pruebas se ejecutan hasta su finalización. 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 las que están en curso se cancelan.
No especifiques --notest_keep_going
y --keep_going
.
--flaky_test_attempts=attempts
Esta opción especifica la cantidad máxima de veces que se debe realizar una prueba.
si falla por cualquier 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 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 destino 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 devuelven PASS y FAIL, la prueba recibirá un estado de inestable (a menos que otras ejecuciones con errores provoquen falla).
Si se especifica un solo número, todas las pruebas se ejecutarán esa misma cantidad de veces.
Como alternativa, una expresión regular puede especificarse con la sintaxis
regex@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
por debajo de //pizza/
4 veces).
Este formato de --runs_per_test
se puede especificar más de una vez.
--[no]runs_per_test_detects_flakes
Si se especifica esta opción (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 para un solo fragmento
falla y una o más ejecuciones para el mismo pase de fragmento, el destino
se considera inestable con la bandera. 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 falla. Este es el valor predeterminado.terse
similares ashort
, pero aún más cortos: solo imprimir información sobre pruebas que no se aprobaron.detailed
imprime cada caso de prueba individual que falló, no solo para cada prueba. Se omiten los nombres de los archivos de salida de 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 que indica si se aprobó cada prueba o falló. También 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 aerrors
, pero imprime un resultado para todas las pruebas, incluidas las que fueron exitosas.streamed
transmite resultados stdout/stderr de cada prueba en en tiempo real.
--java_debug
Esta opción hace que la máquina virtual Java de una prueba de Java espere una conexión desde un
un depurador compatible con JDWP antes de comenzar la prueba; Esta opción implica --test_output=streamed
.
--[no]verbose_test_summary
De forma predeterminada, esta opción se encuentra habilitada, lo que genera tiempos de prueba y otras
información (como intentos de prueba) que se imprimirá en el resumen de la prueba. Si
si se especifica --noverbose_test_summary
, el resumen de la prueba
incluyen solo el nombre de la prueba, el estado de la prueba y el indicador de prueba almacenada en caché, y
Debe formatearse para que no supere los 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 se proporciona un solo valor, debe usarse para todas las categorías de tiempo de espera de pruebas.
Como alternativa, se pueden proporcionar cuatro valores separados por comas que especifican tiempos de espera individuales para pruebas cortas, moderadas, largas y eternas (en ese por orden). De cualquier forma, un valor cero o negativo para cualquiera de los tamaños de prueba por el tiempo de espera predeterminado para las categorías de tiempo de espera dadas, como según se define en la página Cómo escribir pruebas. 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.
Pruebas que establecen explícitamente su categoría de tiempo de espera como distinta de su recibirá el mismo valor que si ese tiempo de espera hubiera sido establecido implícitamente por la etiqueta de tamaño. Entonces, una prueba de tamaño "pequeño" que declara un “largo” el tiempo de espera tienen el mismo tiempo de espera efectivo que una de prueba sin tener en cuenta tiempo de espera.
--test_arg=arg
Pasa opciones, marcas o argumentos de la línea de comandos a cada proceso de prueba. Esta
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 una
objetivo de prueba. Esta ambigüedad no existe para un comando bazel run
, que solo
acepta un objetivo.
--test_arg
se puede pasar a un comando bazel run
, pero se ignora, a menos que el
el objetivo que se está ejecutando es un objetivo de prueba. (Al igual que con cualquier otra marca, si se pasa en un
El comando bazel run
después de un token --
no lo procesa Bazel, pero
reenviando palabra por palabra al objetivo 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
.
Se puede acceder al entorno desde una prueba con
System.getenv("var")
(Java), getenv("var")
(C o C++),
--run_under=command-prefix
Especifica un prefijo que el ejecutor de pruebas insertará al principio del comando de prueba antes de ejecutarlo. El command-prefix se divide en palabras con la shell de Bourne. de asignación de token y, luego, la lista de palabras se antepone al comando que se ejecutará.
Si la primera palabra es una etiqueta completamente calificada (comienza con
//
). 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, así que--run_under
no se puede usar para comandos interactivos.
Ejemplos:
--run_under=/usr/bin/strace --run_under='/usr/bin/strace -c' --run_under=/usr/bin/valgrind --run_under='/usr/bin/valgrind --quiet --num-callers=20'
Selección de prueba
Como se documenta en Opciones de selección de salida, puedes filtrar las pruebas por tamaño tiempo de espera, etiqueta, o idioma. Un beneficio filtro de nombre general puede reenviar mensajes filter args 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 es 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 el que se encuentra el se ejecutó la compilación.BUILD_WORKING_DIRECTORY
: Es el directorio de trabajo actual en el que desde donde se ejecutó Bazel.
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
(ver 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 una etiqueta.
Filtra 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 --ui_event_filters
y
--noshow_progress
.
Por ejemplo: bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp
Cómo ejecutar pruebas
bazel run
también puede ejecutar objetos binarios de prueba, que tienen el efecto de
ejecutar la prueba en una aproximación cercana del entorno descrito en
Escribe 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 resultados de 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 de
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 creado por Bazel
puedes especificar la opción --expunge
. Cuándo
ejecutado con --expunge
, el comando clean solo
quita todo el árbol base de salida que, además de la compilación,
output, contiene todos los archivos temporales creados por Bazel. También
detiene el servidor de Bazel después de la limpieza, equivalente 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 lo siguiente:
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 permite resolver estos problemas y
esos errores son una prioridad que se debe solucionar. Si
encontrar una compilación incremental incorrecta, presentar un informe de errores e informar 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 el gráfico de dependencias usado durante la compilación. Se usa el lenguaje de consulta con dos comandos: query y cquery. La principal diferencia entre 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 un 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 consulta 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
habilitado de forma predeterminada, hace que las dependencias en las configuraciones que no son de destino se incluyan en
el gráfico de dependencia en 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. Los
una dependencia implícita que no se especifica de forma explícita en el archivo BUILD
pero agregada por Bazel.
Ejemplo: "Muestra las ubicaciones de las definiciones (en archivos BUILD) de todas las genrules necesarias para compilar todas las pruebas en el árbol PEBL".
bazel query --output location 'kind(genrule, deps(kind(".*_test rule", foo/bar/pebl/...)))'
Consulta el gráfico de acciones
El comando aquery
te permite consultar acciones en el 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 disponibles y los temas de ayuda, como se muestra en
Cómo compilar con Bazel.
Cuando especificas un argumento, se muestra ayuda detallada para un
en este tema. 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]
imprime solo un
de las opciones relevantes de un tema. Si
se especifica la opción --long
, el tipo y el valor predeterminado
y también se imprimirá la descripción completa de cada opción.
shutdown
Los procesos del servidor de Bazel se pueden detener usando shutdown
.
. Este comando hace que el servidor de Bazel se cierre en cuanto
queda inactiva (por ejemplo, después de que se completan las compilaciones u otras
comandos que están en curso actualmente). Para obtener más detalles, consulta
Implementación 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 uno
la opción --iff_heap_size_greater_than _n_
, que
requiere un argumento de número entero (en MB). Si se especifica, esto hace que el cierre
condicional a la cantidad de memoria ya consumida. 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
ocasión; 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 resulta especialmente conveniente cuando
mediante la secuencia de comandos de Bazel, ya que evita la necesidad de canalizar el resultado
a través de sed -ne /key:/s/key://p
:
Datos independientes de la configuración
release
: Es la etiqueta de lanzamiento de 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 aporta su nada de cero y compilación 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. accesible a los comandos ejecutados durante la compilación, y ¿la fuente para esos comandos. Si el directorio del espacio de trabajo admite escritura, se symlink con el nombrebazel-<workspace>
se coloca allí y apunta a este directorio.output_path
: Es la ruta de acceso absoluta al resultado. ubicado debajo de la raíz de ejecución que se usa para todos los archivos como resultado de los comandos de compilación. Si el directorio del espacio de trabajo admite escritura, se coloca un symlink llamadobazel-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 del comando. contiene las transmisiones stdout y stderr intercaladas de las versiones más recientes. Comando de Bazel. Ten en cuenta que, si ejecutasbazel 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 del comando no cambiará, a menos que cambiar la configuración de--output_base
o Opciones de--output_user_root
.used-heap-size
,committed-heap-size
,max-heap-size
: Informa varios tamaños de montón de JVM. parámetros. 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
: una lista de rutas de acceso separadas por dos puntos que serán buscó paquetes de bazel. Tenga el mismo formato que el Es el argumento de la línea de comandos de compilación--package_path
.
Ejemplo: El ID de 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 directoriosbazel-*
en los que los programas generados por la compilación. Por lo general, aunque no siempre es lo mismo que los symlinksbazel-*
creados en el directorio base del espacio de trabajo después de una compilación exitosa. Sin embargo, si el directorio del espacio de trabajo es de solo lectura, no se pueden crear symlinksbazel-*
. Scripts que utilizan el valor que informabazel info
, en lugar de suponer que la existencia de este symlink, será más sólida.- La revisión completa
“Marca” entorno. Si la marca
--show_make_env
es especificada, todas las variables en el campo "Make" de la configuración actual medio ambiente (comoCC
,GLIBC_VERSION
, etc.). Estas son las variables a las que se accede con el$(CC)
. ovarref("CC")
dentro de los archivos BUILD.
Ejemplo: El compilador C++ para la configuración actual.
Esta es la variable $(CC)
del archivo “Make” entorno,
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
configuración. 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
: la lista de cambios en la que esta versión de Lanzamiento de Bazel.label
: Es la etiqueta de lanzamiento de este Bazel. o “versión de desarrollo” Si este no es un producto binario. Es muy útil cuando se informan errores.
bazel --version
, sin otros argumentos, emitirá el mismo resultado que
bazel version --gnu_format
, excepto que no tiene el efecto secundario de comenzar
un servidor de Bazel o descomprimir el archivo del servidor. Se puede ejecutar bazel --version
desde
en cualquier lugar. No requiere un directorio del espacio de trabajo.
mobile-install
El comando mobile-install
instala apps en dispositivos móviles.
Actualmente, solo se admiten dispositivos Android que ejecutan ART.
Consulta Instalación de bazel para dispositivos móviles para obtener más información.
Se admiten las siguientes opciones:
--incremental
Si están configuradas, Bazel intentará instalar la app de forma incremental; es decir, solo aquellos
que cambiaron desde la última compilación. No se pueden actualizar los recursos
a las que se hace referencia en AndroidManifest.xml
, código nativo o Java
(como los que hace referencia Class.getResource()
). Si estos
Si algo cambia, 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, ten en cuenta las
--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
Marca --incremental
no es necesario cuando se usa --split_apks
.
--start_app
Inicia la app en un estado limpio después de la instalación. Equivale a --start=COLD
.
--debug_app
Espera a que se adjunte el depurador antes de iniciar la app en 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 instalar.
--adb=path
Indica el objeto binario adb
que se usará.
De forma predeterminada, se usa el adb en el SDK de Android especificado por
--android_sdk
--adb_arg=serial
Argumentos adicionales para adb
. Estos anteceden al subcomando en la
línea de comandos y se usan, por lo general, para especificar en qué dispositivo instalar.
Por ejemplo, para seleccionar el dispositivo o emulador de Android que deseas usar, haz lo siguiente:
% bazel mobile-install --adb_arg=-s --adb_arg=deadbeef
invoca a adb
como
adb -s deadbeef install ...
--incremental_install_verbosity=number
La verbosidad para la instalación incremental. Se establece en 1 para que el registro de depuración sea en la consola.
dump
El comando dump
imprime en stdout un volcado de la
estado interno del servidor de Bazel. Este comando está diseñado
principalmente para desarrolladores de Bazel, por lo que el resultado de este comando
no se especifica y está sujeta a cambios.
De forma predeterminada, el comando solo mostrará un mensaje de ayuda con un esquema posible. Opciones para volcar áreas específicas del estado de Bazel. Para volcar estado interno, se debe especificar al menos una de las opciones.
Se admiten las siguientes opciones:
--action_cache
vuelca contenido de la caché de acciones.--packages
vuelca 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, las reglas el consumo de memoria.--skylark_memory
vuelca un pprof compatible con la ruta de acceso especificada. Debes habilitar el seguimiento de memoria para que esto funcione.
Seguimiento de la memoria
Algunos comandos dump
requieren seguimiento de memoria. Para activar esto, debes pasar
Marcas de inicio para 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 las 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 de JSON previamente
recopiladas durante una invocación de Bazel.
canonicalize-flags
El canonicalize-flags
que toma una lista de opciones para un comando de Bazel y muestra una lista de
que tengan 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
con comandos de SQL sencillos. En este momento, solo build
y test
son
no es compatible. 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 el servidor de Bazel y las opciones de inicio no coinciden, sí reiniciarse.
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.
. 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 el nombre del directorio del espacio de trabajo (en realidad, su resumen de MD5)
por lo que un valor típico se ve así:
/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 instalación y salida. El directorio No debe existir ni ser propiedad del usuario que realiza la llamada. En el pasado, se permitía apuntar a un directorio compartido entre varios usuarios pero ya no está permitido. Se puede permitir una vez problema #11100.
Si se especifica la opción --output_base
, esta anula
usando --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 base alternativa para todos los resultados de Bazel (base de instalación y salida
base) si hay una mejor ubicación en el diseño del 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 a el 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. 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 no debería ser necesario 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 aprobar
Opciones de JVM para programas ejecutables de Java, ya sea ejecutados por bazel
run
o en la línea de comandos, debes usar
el argumento --jvm_flags
, que
todos los programas java_binary
y java_test
y asistencia. 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 Java espere una conexión desde un depurador compatible con JDWP antes de llamando al método principal de Bazel mismo. Esto es principalmente para desarrolladores de Bazel.
--autodetect_server_javabase
Esta opción hace que Bazel busque automáticamente un JDK instalado al inicio.
y recurrir 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 estándar de cliente/servidor, pero ejecuta un comando de Java para un solo comando, que se usó para aplicaciones semántica con respecto al manejo de señales, el control de trabajos y el entorno la herencia variable y es necesaria para ejecutar Bazel en una cárcel chroot.
El modo por lotes conserva la semántica de cola adecuada dentro de la misma output_base. Es decir, las invocaciones simultáneas se procesarán en orden, sin superposición. Si Bazel en modo por lotes se ejecuta en un cliente con un servidor en ejecución, primero finaliza 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 a que, entre otras cosas, la caché del archivo de compilación es residente de 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 la duración (en segundos) del proceso del servidor de Bazel
debe esperar después de la última solicitud del cliente, antes de que se cierre. 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 abandonan 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
no introduzca dependencias no deseadas. Sin embargo, si el
usuario no hizo una compilación reciente en ese espacio de trabajo,
no es recomendable que la secuencia de comandos de envío previo inicie un servidor de Bazel
para que permanezca inactiva por 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 causó 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 disponible del sistema queda muy baja, se cerrará el servidor.
--[no]block_for_lock
Si se habilita esta opción, Bazel esperará a recibir otros comandos de Bazel que contengan el ícono el bloqueo del servidor se complete antes de continuar. Si se inhabilita, Bazel hará lo siguiente: salir por error si no puede adquirir inmediatamente el bloqueo y continuar.
Los desarrolladores pueden usar esto en las comprobaciones previas al envío para evitar largas esperas causadas con otro comando de Bazel en el mismo cliente.
--io_nice_level=n
Establece un nivel de 0 a 7 para la mejor programación de E/S. 0 es la prioridad más alta, 7 es el más bajo. 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.
Consulta 'man 2 sched_setscheduler'. Esta política puede proporcionar una mejor
la interactividad 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 habilitará la salida de color.
Si esta opción se establece en auto
, Bazel usará la salida de color solo si
el resultado se envía a una terminal y la variable de entorno TERM
esté configurado en un valor distinto de 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 la sección de configuración adicional de
los archivos rc para el command
actual
también extrae las opciones de command:name
, si existe tal sección. Puede ser
se especificó 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 generado por Bazel especificando la hora a la que se mostró el mensaje.