Comandos e opções

Informar um problema Ver a fonte Nightly · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Esta página aborda as opções disponíveis com vários comandos do Bazel, como bazel build, bazel run e bazel test. Esta página é um complemento à lista de comandos do Bazel em Build with Bazel.

Sintaxe de destino

Alguns comandos, como build ou test, podem operar em uma lista de destinos. Eles usam uma sintaxe mais flexível que rótulos, o que é documentado em Especificar destinos a serem compilados.

Opções

As seções a seguir descrevem as opções disponíveis durante um ser construído. Quando --long é usado em um comando de ajuda, as mensagens de ajuda on-line fornecem informações resumidas sobre o significado, o tipo e o valor padrão de cada opção.

A maioria das opções só pode ser especificada uma vez. Quando especificado várias vezes, o a última instância vença. As opções que podem ser especificadas várias vezes são identificadas na ajuda on-line com o texto "pode ser usado várias vezes".

Localização do pacote

--package_path

AVISO:a opção --package_path foi descontinuada. O Bazel prefere pacotes repositório principal como abaixo da raiz do espaço de trabalho.

Essa opção especifica o conjunto de diretórios que são pesquisados para encontrar o arquivo BUILD de um determinado pacote.

O Bazel encontra os pacotes pesquisando o caminho deles. Isso é um sinal de dois-pontos lista ordenada separada de diretórios do Bazel, sendo cada um a raiz de um árvore de origem parcial.

Para especificar um caminho de pacote personalizado usando a opção --package_path:

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

Os elementos do caminho do pacote podem ser especificados em três formatos:

1. Se o primeiro caractere for /, o caminho será absoluto.
2. Se o caminho começar com %workspace%, ele será considerado relativo para o diretório do Bazel mais próximo. Por exemplo, se o diretório de trabalho for /home/bob/clients/bob_client/bazel/foo, o valor A string %workspace% no caminho do pacote é expandida. para /home/bob/clients/bob_client/bazel.
3. Qualquer outra coisa é tomada em relação ao diretório de trabalho. Isso geralmente não é o que você quer fazer e pode se comportar de forma inesperada se você usar o Bazel em diretórios abaixo do espaço de trabalho do Bazel. Por exemplo, se você usar o elemento package-path .: e, em seguida, "cd" no diretório /home/bob/clients/bob_client/bazel/foo, pacotes serão resolvidas a partir da /home/bob/clients/bob_client/bazel/foo.

Se você usar um caminho de pacote não padrão, especifique-o no arquivo de configuração do Bazel para sua conveniência.

O Bazel não exige que nenhum pacote esteja no diretório atual. Portanto, é possível fazer um build em um espaço de trabalho do Bazel vazio se todos os pacotes necessários puderem ser encontrados em outro lugar no caminho do pacote.

Exemplo: como criar a partir de um cliente vazio

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

--deleted_packages

Essa opção especifica uma lista separada por vírgulas de pacotes que o Bazel considera que foram excluídos e não tenta carregar de nenhum diretório no caminho do pacote. Isso pode ser usado para simular a exclusão de pacotes sem e realmente excluí-las. Essa opção pode ser transmitida várias vezes. Nesse caso, as listas individuais são concatenadas.

Verificação de erros

Essas opções controlam a verificação de erros e/ou os avisos do Bazel.

--[no]check_visibility

Se essa opção for definida como falsa, as verificações de visibilidade serão rebaixadas para avisos. O valor padrão dessa opção é "true", para que a verificação de visibilidade seja feita por padrão.

--output_filter=regex

A opção --output_filter só vai mostrar avisos de build e compilação para segmentos que correspondem à expressão regular. Se um destino não corresponder à expressão regular fornecida e a execução for bem-sucedida, a saída padrão e o erro padrão serão descartados.

Confira alguns valores típicos para essa opção:

`--output_filter='^//(first/project|second/project):'`	Mostra a saída dos pacotes especificados.
`--output_filter='^//((?!(first/bad_project|second/bad_project):).)*$'`	Não mostra a saída dos pacotes especificados.
`--output_filter=`	Mostrar tudo.
`--output_filter=DONT_MATCH_ANYTHING`	Não mostrar nada.

Sinalizações de ferramentas

Elas controlam quais opções o Bazel transmite para outras ferramentas.

--copt=cc-option

Essa opção recebe um argumento que será transmitido ao compilador. O argumento será transmitido ao compilador sempre que for invocado para pré-processar, compilar e/ou montar código C, C++ ou de montador. Ele não será transmitido durante a vinculação.

Essa opção pode ser usada várias vezes. Exemplo:

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

vai compilar a biblioteca foo sem tabelas de depuração, gerando código independente de posição.

Observação: mudar as configurações de --copt forçará uma recompilação. de todos os arquivos de objeto afetados. Observe também que os valores dos copts listados em As regras de build cc_library ou cc_binary serão colocadas na linha de comando do compilador. depois dessas opções.

Aviso: opções específicas de C++ (como -fno-implicit-templates) deve ser especificado em --cxxopt, não em --copt. Da mesma forma, opções específicas para C (como -Wstrict-prototypes), deve ser especificado em --conlyopt, não em copt. Da mesma forma, as opções do compilador que têm efeito apenas no momento da vinculação (como -l) precisam ser especificadas em --linkopt, não em --copt.

--host_copt=cc-option

Essa opção recebe um argumento que será transmitido ao compilador para arquivos de origem compilados na configuração de execução. Isso é análogo à opção --copt, mas se aplica apenas à configuração de execução.

--host_conlyopt=cc-option

Essa opção recebe um argumento que será transmitido ao compilador para arquivos-fonte C compilados na configuração de execução. Isso é análogo à opção --conlyopt, mas se aplica apenas à configuração de execução.

--host_cxxopt=cc-option

Essa opção usa um argumento que deve ser passado ao compilador para arquivos de origem C++ que são compiladas na configuração "exec". Isso é análogo à opção --cxxopt, mas se aplica apenas à configuração de execução.

--host_linkopt=linker-option

Essa opção recebe um argumento que será transmitido ao vinculador para arquivos de origem que são compilados na configuração de execução. Isso é análogo ao a opção --linkopt, mas se aplica apenas a a configuração "exec".

--conlyopt=cc-option

Essa opção aceita um argumento que deve ser passado ao compilador na compilação de arquivos de origem em C.

Isso é semelhante ao --copt, mas só se aplica à compilação C. e não à compilação ou vinculação em C++. Então é possível passar opções específicas para C (como -Wno-pointer-sign) usando --conlyopt.

Observação: parâmetros copts listados nas regras de build cc_library ou cc_binary específicas são colocados na linha de comando do compilador depois dessas opções.

--cxxopt=cc-option

Essa opção usa um argumento que deve ser passado ao compilador quando compilar arquivos de origem em C++.

Isso é semelhante a --copt, mas só se aplica à compilação C++. e não à compilação ou vinculação em C. É possível transmitir opções específicas de C++ (como -fpermissive ou -fno-implicit-templates) usando --cxxopt.

Exemplo:

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

Observação: os parâmetros copts listados em regras de build específicas de cc_library ou cc_binary são colocados na linha de comando do compilador após essas opções.

--linkopt=linker-option

Essa opção usa um argumento que precisa ser passado ao compilador durante a vinculação.

Isso é semelhante a --copt, mas se aplica apenas à vinculação, não à compilação. Portanto, é possível passar opções de compilador que só fazem sentido no momento da vinculação (como -lssp ou -Wl,--wrap,abort) usando --linkopt. Exemplo:

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

As regras de criação também podem especificar opções de vinculação nos atributos. As configurações dessa opção sempre têm precedência. Consulte também cc_library.linkopts

--strip (always|never|sometimes)

Essa opção determina se o Bazel vai remover as informações de depuração todos os binários e bibliotecas compartilhadas invocando o vinculador com a opção -Wl,--strip-debug. --strip=always significa sempre remover as informações de depuração. --strip=never significa nunca remover informações de depuração. O valor padrão de --strip=sometimes significa remover se o --compilation_mode for fastbuild.

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

vai compilar o destino e remover as informações de depuração de todos os binários.

Observação: se você quiser informações de depuração, não basta desativar a remoção. você também precisa se certificar de que as informações de depuração foram geradas pelo compilador, o que pode ser feito usando -c dbg ou --copt -g.

A opção --strip do Bazel corresponde à opção --strip-debug do ld: somente as informações de depuração. Se, por algum motivo, você quiser remover todos os símbolos, e não apenas os símbolos de depuração, será necessário usar a opção --strip-all do ld, o que pode ser feito transmitindo --linkopt=-Wl,--strip-all para o Bazel. Além disso, tenha saber que a definição da flag --strip do Bazel vai substituir --linkopt=-Wl,--strip-all. Portanto, defina apenas um ou outro.

Se estiver criando apenas um binário e quiser que todos os símbolos sejam removidos, também é possível transmitir --stripopt=--strip-all e criar explicitamente o Versão //foo:bar.stripped do destino. Conforme descrito na seção sobre --stripopt, aplica uma ação de remoção após o binário final ser vinculado em vez de incluir a remoção em todas as ações de link da versão.

--stripopt=strip-option

Essa é uma opção extra para transmitir ao comando strip ao gerar um binário *.stripped. O padrão é -S -p. Essa opção pode ser usada várias vezes.

Observação: --stripopt não se aplica à remoção da principal binário com [--strip](#flag--strip)=(always|sometimes).

--fdo_instrument=profile-output-dir

A opção --fdo_instrument permite a geração de Saída do perfil de FDO (otimização direcionada por feedback) quando o binário C/C++ criado. Para o GCC, o argumento fornecido é usado como um prefixo de diretório para uma árvore de diretórios de arquivos por objeto de arquivos .gcda que contém informações de perfil para cada arquivo .o.

Assim que a árvore de dados de perfil tiver sido gerada, a árvore de perfil deve ser compactado e fornecido ao --fdo_optimize=profile-zip Opção do Bazel para ativar a compilação otimizada para FDO.

Para o compilador do LLVM, o argumento também é o diretório em que o perfil bruto do LLVM arquivo(s) de dados for despejado. Por exemplo: --fdo_instrument=/path/to/rawprof/dir/.

As opções --fdo_instrument e --fdo_optimize não podem ser usadas ao mesmo tempo.

--fdo_optimize=profile-zip

A opção --fdo_optimize permite o uso das informações de perfil de arquivo por objeto para realizar otimizações de FDO (otimização direcionada por feedback) durante a compilação. Para o GCC, o argumento fornecido é o arquivo zip que contém a árvore de arquivos gerada anteriormente de arquivos .gcda com informações de perfil para cada arquivo .o.

Como alternativa, o argumento fornecido pode apontar para um perfil automático identificados pela extensão .afdo.

Observação: essa opção também aceita rótulos que são resolvidos em arquivos de origem. Talvez seja necessário adicionar uma diretiva exports_files ao pacote correspondente para tornar o arquivo visível para o Bazel.

Para o compilador LLVM, o argumento fornecido precisa apontar para o arquivo de saída do perfil LLVM indexado preparado pela ferramenta llvm-profdata e ter uma extensão .profdata.

As opções --fdo_instrument e --fdo_optimize não podem ser usadas ao mesmo tempo.

--java_language_version=version

Essa opção especifica a versão das origens do Java. Exemplo:

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

compila e permite apenas construções compatíveis com a especificação Java 8. O valor padrão é 8. --> Os valores possíveis são: 8, 9, 10, 11, 14, 15 e 21 e podem ser estendidos registrando cadeias de ferramentas Java personalizadas usando default_java_toolchain.

--tool_java_language_version=version

A versão da linguagem Java usada para criar ferramentas que são executadas durante um build. O valor padrão é 8.

--java_runtime_version=version

Essa opção especifica a versão da JVM a ser usada para executar o código e os testes. Por exemplo:

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

faz o download do JDK 11 de um repositório remoto e executa o aplicativo Java usando-o.

O valor padrão é local_jdk. Os valores possíveis são local_jdk, local_jdk_version, remotejdk_11 e remotejdk_17. É possível estender os valores registrando uma JVM personalizada usando regras de repositório local_java_repository ou remote_java_repository.

--tool_java_runtime_version=version

A versão da JVM usada para executar ferramentas necessárias durante um build. O valor padrão é remotejdk_11.

--jvmopt=jvm-option

Essa opção permite que argumentos de opção sejam transmitidos para a VM Java. Ele pode ser usado com um argumento grande ou várias vezes com argumentos individuais. Exemplo:

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

vai usar a VM do servidor para iniciar todos os binários Java e definir o tamanho do heap de inicialização da VM como 256 MB.

--javacopt=javac-option

Essa opção permite que argumentos de opção sejam transmitidos para o javac. Pode ser usado com um argumento grande ou várias vezes com argumentos individuais. Exemplo:

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

vai recriar um java_binary com as informações de depuração padrão javac (em vez do padrão do Bazel).

A opção é transmitida para javac depois das opções padrão integradas do Bazel para javac e antes das opções por regra. A última especificação de qualquer opção para javac vence. As opções padrão do javac são:

  -source 8 -target 8 -encoding UTF-8

Observação: mudar as configurações de --javacopt força a recompilação. de todas as classes afetadas. Observe também que os parâmetros javacopts listados na Regras de compilação java_library ou java_binary específicas serão colocadas na linha de comando depois dessas opções.

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

Essa opção controla se javac verifica se há dependências diretas ausentes. Os destinos Java precisam declarar explicitamente todos os destinos usados diretamente como dependências. Essa flag instrui o javac a determinar os jars realmente usados. para a verificação de tipo de cada arquivo Java, e warning/error se eles não forem a saída de uma dependência direta do destino atual.

• off significa que a verificação está desativada.
• warn significa que javac gerará avisos Java padrão de digite [strict] para cada dependência direta ausente.
• default, strict e error todos significa que javac gerará erros em vez de avisos, fazendo com que o código falha na criação se alguma dependência direta ausente for encontrada. Esse também é o comportamento padrão quando a sinalização não é especificada.

Semântica do build

Essas opções afetam os comandos de build e/ou o conteúdo do arquivo de saída.

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

A opção --compilation_mode (muitas vezes abreviada para -c, especialmente -c opt) usa um argumento de fastbuild, dbg ou opt e afeta várias opções de geração de código C/C++, como o nível de otimização e a integridade das tabelas de depuração. O Bazel usa um diretório de saída diferente para cada um modo de compilação diferente, para que você possa alternar entre os modos sem precisar recriar todas as vezes.

• fastbuild significa criar o mais rápido possível: gerar informações mínimas de depuração (-gmlt -Wl,-S) e não otimizar. Esse é o padrão. Observação: -DNDEBUG não será definido.
• dbg significa build com depuração ativada (-g), para que você possa usar o gdb (ou outro depurador).
• opt significa criar com otimização ativada e com assert() chamadas desativadas (-O2 -DNDEBUG). As informações de depuração não serão geradas no modo opt. a menos que você também passe --copt -g.

--cpu=cpu

Essa opção especifica a arquitetura de CPU de destino a ser usada para a compilação de binários durante o build.

Observação: uma combinação específica de versão de crosstool, versão do compilador e CPU de destino só é permitida se tiver sido especificada no arquivo CROSSTOOL usado atualmente.

--action_env=VAR=VALUE

Especifica o conjunto de variáveis de ambiente disponíveis durante a execução de todas as ações. As variáveis podem ser especificadas por nome, caso em que o valor será retirado do ambiente de invocação, ou pelo par name=value, que define o valor independente do ambiente de invocação.

Essa sinalização --action_env pode ser especificada várias vezes. Se um valor for atribuído ao mesmo em várias flags --action_env, a última atribuição vence.

--experimental_action_listener=label

Aviso: as ações extras foram descontinuadas. Usar aspectos como alternativa.

A opção experimental_action_listener instrui o Bazel a usar detalhes da regra action_listener especificada por label para inserir extra_actions no gráfico de build.

--[no]experimental_extra_action_top_level_only

Aviso: as ações extras foram descontinuadas. Usar aspects.

Se esta opção for definida como verdadeira, as ações extras especificadas pelo Comando --experimental_action_listener a opção de linha só será programada para segmentações de nível superior.

--experimental_extra_action_filter=regex

Aviso: as ações extras foram descontinuadas. Use aspectos em vez disso.

A opção experimental_extra_action_filter instrui o Bazel a filtrar o conjunto de segmentações para programar extra_actions.

Essa sinalização só é aplicável em combinação com o flag --experimental_action_listener.

Por padrão, todos os extra_actions no fechamento transitivo dos alvos-a-criar solicitados são programados para execução. --experimental_extra_action_filter vai restringir a programação a extra_actions dos quais o rótulo do proprietário corresponda ao especificado expressão regular.

O exemplo a seguir limita a programação de extra_actions para que seja aplicada apenas a ações em que o rótulo do proprietário contém '/bar/':

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

--host_cpu=cpu

Essa opção especifica o nome da arquitetura de CPU que precisa ser usado para criar ferramentas de host.

--android_platforms=platform[,platform]*

As plataformas para criar a deps transitiva de Regras android_binary (especificamente para dependências nativas, como C++). Para exemplo, se um cc_library aparece na deps transitiva de uma android_binary, que é criada uma vez para cada plataforma especificada com --android_platforms para a regra android_binary e incluída no saída.

Não há um valor padrão para essa flag: uma plataforma Android personalizada precisa ser definida e usada.

Um arquivo .so é criado e empacotado no APK para cada plataforma especificada. com --android_platforms. O nome do arquivo .so tem o prefixo "lib" do nome da regra android_binary. Por exemplo, se o nome do android_binary for "foo", o arquivo será libfoo.so.

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

Quando presente, qualquer arquivo C++ com um rótulo ou um caminho de execução que corresponda a uma das expressões regulares de inclusão e não corresponda a nenhuma das expressões de exclusão será criado com as opções fornecidas. A correspondência de rótulo usa a forma canônica do rótulo (ou seja, //package:label_name).

O caminho de execução é o caminho relativo ao diretório do espaço de trabalho, incluindo o nome de base (incluindo a extensão) do arquivo C++. Ele também inclui todos os prefixos dependentes da plataforma.

Observação: se apenas um dos rótulos ou o caminho de execução corresponder às opções, elas serão usadas.

Para corresponder aos arquivos gerados (como saídas de genrule), o Bazel só pode usar o caminho de execução. Nesse caso, o regexp não pode começar com "//", porque ele não corresponde a nenhum caminho de execução. Os nomes de pacotes podem ser usados da seguinte forma: --per_file_copt=base/.*\.pb\.cc@-g0: Isso vai corresponder a todos os arquivos .pb.cc em um diretório chamado base.

Essa opção pode ser usada várias vezes.

A opção é aplicada independentemente do modo de compilação usado. Por exemplo, é possível para compilar com --compilation_mode=opt e compilar seletivamente arquivos com otimização mais forte ativada ou com otimização desativada.

Advertência: se alguns arquivos são compilados seletivamente com símbolos de depuração, os símbolos podem ser removidos durante a vinculação. Isso pode ser evitado definindo --strip=never.

Sintaxe: [+-]regex[,[+-]regex]...@option[,option]..., em que regex representa uma expressão regular que pode ser prefixada com uma + para identificar padrões de inclusão e com - para identificar excluir padrões. option significa uma opção arbitrária transmitida ao compilador C++. Se uma opção tiver um ,, ela precisará ser citada dessa forma. \,. As opções também podem conter @, já que apenas o primeiro @ é usada para separar expressões regulares das opções.

Exemplo: --per_file_copt=//foo:.*\.cc,-//foo:file\.cc@-O0,-fprofile-arcs adiciona as opções -O0 e -fprofile-arcs à linha de comando do compilador C++ para todos os arquivos .cc em //foo/, exceto file.cc.

--dynamic_mode=mode

Determina se os binários C++ serão vinculados de maneira dinâmica, interagindo com o atributo linkstatic nas regras de build.

Modos:

• default: permite que o Bazel escolha se quer vincular dinamicamente. Consulte linkstatic para saber mais informações imprecisas ou inadequadas.
• fully: vincula todos os destinos dinamicamente. Isso vai acelerar o tempo de vinculação e reduz o tamanho dos binários resultantes.
• off: vincula todos os destinos em modo principalmente estático. Se -static for definido em linkopts, os destinos vão mudar para totalmente estáticos.

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

Ativa a fissão, que grava informações de depuração C++ em arquivos .dwo dedicados em vez de arquivos .o, onde Caso contrário, vá. Isso reduz substancialmente o tamanho da entrada para os links e pode diminuir o tempo deles.

Quando definido como [dbg][,opt][,fastbuild] (exemplo: --fission=dbg,fastbuild), a fissão está ativada apenas para o conjunto especificado de modos de compilação. Isso é útil para o Bazel configurações. Quando definida como yes, a fissão é ativada universalmente. Quando definida como no, a fissão é desativada universalmente. O padrão é no.

--force_ignore_dash_static

Se esta sinalização for definida, todas as opções -static nos linkopts de Os arquivos BUILD de regras cc_* são ignorados. Isso é apenas um alternativa para builds de aumento da proteção do C++.

--[no]force_pic

Se ativado, todas as compilações C++ vão produzir código independente de posição ("-fPIC"), os links vão preferir bibliotecas pré-compiladas PIC em vez de bibliotecas não-PIC, e os links vão produzir executáveis independentes de posição ("-pie"). O padrão é desativado.

Observação: binários vinculados dinamicamente (por exemplo, --dynamic_mode fully) gerar código PIC independentemente da configuração deste sinalizador. Essa flag é usada em casos em que os usuários querem que o código PIC seja gerado explicitamente para links estáticos.

--android_resource_shrinking

Seleciona se o recurso de redução de recursos será realizado para regras android_binary. Define o padrão do atributo reduce_resources de regras de android_binary; consulte a documentação dessa regra para mais detalhes. O padrão é desativado.

--custom_malloc=malloc-library-target

Quando especificado, sempre use a implementação malloc especificada, substituindo todos os atributos malloc="target", incluindo aqueles destinos que usam o padrão (não especificando nenhum malloc).

--crosstool_top=label

Esta opção especifica o local do pacote do compilador crosstool para ser usada para toda a compilação em C++ durante um build. O Bazel vai procurar um arquivo CROSSTOOL nesse local e usá-lo para determinar automaticamente as configurações de --compiler.

--host_crosstool_top=label

Se não for especificado, o Bazel usa o valor de --crosstool_top para compilar na configuração do exec, como as ferramentas que são executadas durante o build. O principal objetivo dessa flag é ativar a compilação cruzada.

--apple_crosstool_top=label

A ferramenta cruzada a ser usada para compilar regras C/C++ no deps transitivo de objc*, ios* e apple*. Para esses destinos, esta sinalização substitui --crosstool_top:

--compiler=version

Essa opção especifica a versão do compilador C/C++ (como gcc-4.1.0). para ser usada na compilação de binários durante o build. Se você quiser com uma ferramenta cruzada personalizada, você deve usar um arquivo CROSSTOOL em vez de especificando essa sinalização.

Observação: somente algumas combinações de versão do crosstool, versão do compilador e CPU de destino são permitidas.

--android_sdk=label

Obsoleto. Isso não deve ser especificado diretamente.

Essa opção especifica o conjunto de ferramentas do SDK/plataforma do Android e a biblioteca de execução do Android que serão usadas para criar qualquer regra relacionada ao Android.

O SDK do Android será selecionado automaticamente se uma regra android_sdk_repository for definida no arquivo WORKSPACE.

--java_toolchain=label

Não faz nada. Mantida apenas para compatibilidade com versões anteriores.

--host_java_toolchain=label

Não faz nada. Mantida apenas para compatibilidade com versões anteriores.

--javabase=(label)

Não faz nada. Mantida apenas para compatibilidade com versões anteriores.

--host_javabase=label

Ambiente autônomo. Mantida apenas para compatibilidade com versões anteriores.

Estratégia de execução

Essas opções afetam a forma como o Bazel executa o build. Eles não devem ter nenhum efeito significativo nos arquivos de saída gerados pelo build. Normalmente, o principal efeito é na e a velocidade do build.

--spawn_strategy=strategy

Essa opção controla onde e como os comandos são executados.

• standalone faz com que os comandos sejam executados como subprocessos locais. Esse valor foi descontinuado. Em vez disso, use local
• sandboxed faz com que os comandos sejam executados dentro de um sandbox na máquina local. Isso exige que todos os arquivos de entrada, dependências de dados e ferramentas sejam listados como diretos dependências nos atributos srcs, data e tools. O Bazel ativa o sandbox local por padrão em sistemas compatíveis com a execução em sandbox.
• local faz com que os comandos sejam executados como subprocessos locais.
• worker faz com que os comandos sejam executados usando um worker persistente, se disponível.
• docker faz com que os comandos sejam executados dentro de um sandbox do Docker na máquina local. Isso exige que o Docker esteja instalado.
• remote faz com que os comandos sejam executados remotamente; só estará disponível se um O executor remoto foi configurado separadamente.

--strategy mnemonic=strategy

Essa opção controla onde e como os comandos são executados, substituindo a --spawn_strategy (e --genrule_strategy com comandos mnemônicos genrule), de acordo com a mnemônica. Consulte --spawn_strategy para conferir as estratégias com suporte e os efeitos delas.

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

Essa opção especifica qual estratégia deve ser usada para executar comandos com descrições que correspondem a um determinado regex_filter. Consulte --per_file_copt para detalhes sobre regex_filter correspondente. Consulte --spawn_strategy para os recursos estratégias e seus efeitos.

O último regex_filter que corresponde à descrição é usado. Essa opção substitui e outras flags para especificar a estratégia.

• Exemplo: --strategy_regexp=//foo.*\\.cc,-//foo/bar=local significa executar ações usando Estratégia local se as descrições corresponderem a //foo.*.cc, mas não a //foo/bar.
• Exemplo: --strategy_regexp='Compiling.*/bar=local' --strategy_regexp=Compiling=sandboxed executa "Compiling //foo/bar/baz" com a estratégia sandboxed, mas reverter a ordem a executa com local.
• Exemplo: execuções de --strategy_regexp='Compiling.*/bar=local,sandboxed' 'Compilando //foo/bar/baz' com a estratégia local e usa sandboxed em caso de falha.

--genrule_strategy=strategy

Essa é uma abreviação descontinuada de --strategy=Genrule=strategy.

--jobs=n (-j)

Essa opção, que recebe um argumento inteiro, especifica um limite no número de jobs que precisam ser executados simultaneamente durante a fase de execução do build.

Observação: o número de jobs simultâneos que o Bazel executará é determinado não só pela configuração --jobs, mas também pelo programador do Bazel, que tenta evitar a execução de jobs simultâneos. que vão usar mais recursos (RAM ou CPU) do que os disponíveis, com base em algumas estimativas (bastante brutas) do consumo dos recursos de cada trabalho. O comportamento do programador pode ser controlado a opção --local_ram_resources.

--progress_report_interval=n

O Bazel imprime periodicamente um relatório de progresso dos jobs que não estão concluído ainda (como testes de longa duração). Essa opção define a frequência de relatórios. O progresso será impresso a cada n segundos.

O padrão é 0, o que significa um algoritmo incremental: o primeiro relatório será impresso após 10 segundos, depois 30 segundos e depois esse progresso é relatado uma vez por minuto.

Quando o Bazel usa o controle do cursor, conforme especificado por --curses, o progresso é informado a cada segundo.

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

Essas opções especificam a quantidade de recursos locais (RAM em MB e número de núcleos lógicos da CPU). que o Bazel pode considerar ao programar atividades de compilação e teste para execução local. Elas levam um número inteiro ou uma palavra-chave (HOST_RAM ou HOST_CPUS) opcionalmente seguida por [-|*float] (por exemplo, --local_cpu_resources=2, --local_ram_resources=HOST_RAM*.5, --local_cpu_resources=HOST_CPUS-1). As sinalizações são independentes. uma ou ambas podem ser definidas. Por padrão, o Bazel estima a quantidade de RAM e o número de núcleos de CPU diretamente na configuração do sistema local.

--[no]build_runfile_links

Essa opção, que é ativada por padrão, especifica se os arquivos de execução No diretório de saída, crie links simbólicos para testes e binários. O uso de --nobuild_runfile_links pode ser útil para validar se todos os destinos são compilados sem gerar a sobrecarga para criar as árvores de runfiles.

Quando testes (ou aplicativos) são executados, os dados do ambiente de execução as dependências ficam reunidas em um só lugar. Na árvore de saída do Bazel, essa árvore de "arquivos de execução" normalmente é enraizada como um irmão do binário ou teste correspondente. Durante a execução do teste, os arquivos de execução podem ser acessados usando caminhos do formulário. $TEST_SRCDIR/canonical_repo_name/packagename/filename: A árvore de arquivos de execução garante que os testes tenham acesso a todos os arquivos do qual eles têm uma dependência declarada e nada mais. De padrão, a árvore de arquivos de execução é implementada construindo um conjunto de links simbólicos para os arquivos necessários. À medida que o conjunto de links aumenta, então o custo dessa operação e, para alguns builds grandes, ele pode contribuem significativamente para o tempo total de compilação, especialmente porque cada teste (ou aplicativo) individual exige uma árvore de arquivos de execução própria.

--[no]build_runfile_manifests

Essa opção, que é ativada por padrão, especifica se os manifestos de runfiles precisam ser gravados na árvore de saída. Desativá-la implica --nobuild_runfile_links.

Ele pode ser desativado ao executar testes remotamente, já que as árvores de arquivos de execução serão criadas remotamente a partir de manifestos na memória.

--[no]discard_analysis_cache

Quando essa opção está ativada, o Bazel descarta o cache de análise logo antes do início da execução, liberando mais memória (cerca de 10%) para a fase de execução. A desvantagem é que mais builds incrementais serão mais lentos. Consulte também modo de economia de memória.

--[no]keep_going (- mil)

Assim como no GNU Make, a fase de execução de um build é interrompida quando o primeiro erro é encontrado. Às vezes, é útil tentar construir como o máximo possível, mesmo com erros. Essa opção ativa esse comportamento e, quando especificado, o build tentará criar todos os destinos que tiveram pré-requisitos, mas ignora os erros.

Embora essa opção geralmente seja associada à fase de execução de um build, ela também afeta a fase de análise: se vários destinos forem especificados em um comando de build, mas apenas alguns deles puderem ser analisados, o build será interrompido com um erro, a menos que --keep_going seja especificado. Nesse caso, o build vai prosseguir para a fase de execução, mas apenas para os destinos que foram analisados.

--[no]use_ijars

Essa opção muda a maneira como os destinos java_library são compilados pelo Bazel. Em vez de usar a saída de um java_library para compilar destinos java_library dependentes, o Bazel vai criar jars de interface que contêm apenas as assinaturas de membros não particulares (métodos e campos de acesso públicos, protegidos e padrão (pacote)) e usar os jars de interface para compilar os destinos dependentes. Assim, possível de evitar a recompilação quando alterações são feitas apenas corpos de métodos ou membros privados de uma classe.

Observação: o uso de --use_ijars pode fornecer uma ao se referir acidentalmente a um URL membro de outra classe: em vez de receber um erro informando que o membro não estiver visível, você receberá um erro informando que o membro não existe. Alterar a configuração --use_ijars forçará uma recompilação de todas as contas afetadas .

--[no]interface_shared_objects

Essa opção ativa objetos compartilhados por interface, o que torna binários e Outras bibliotecas compartilhadas dependem da interface de um objeto compartilhado e não na implementação. Quando apenas a implementação muda, o Bazel pode evitar a reconstrução de destinos que dependem da biblioteca compartilhada alterada desnecessariamente.

Seleção de saída

Essas opções determinam o que compilar ou testar.

--[no]build

Essa opção faz com que a fase de execução do build ocorra. ele é são ativados por padrão. Quando ele é desativado, a fase de execução pulados, e apenas as duas primeiras fases, carregamento e análise, ocorrem.

Essa opção pode ser útil para validar arquivos BUILD e detectar erros nas entradas, sem realmente criar nada.

--[no]build_tests_only

Se especificado, o Bazel vai criar apenas o necessário para executar as regras *_test e test_suite que não foram filtradas devido ao tamanho, tempo limite, tag ou idioma. Se especificado, o Bazel vai ignorar outros destinos especificados na linha de comando. Por padrão, essa opção está desativada, e o Bazel vai criar tudo solicitado, incluindo *_test e test_suite regras que foram filtradas de testes. Isso é útil porque a execução de bazel test --build_tests_only foo/... pode não detectar todas as falhas de build na árvore foo.

--[no]check_up_to_date

Essa opção faz com que o Bazel não execute uma compilação, apenas verifique se todos os destinos especificados estão atualizados. Nesse caso, o build é concluída com sucesso, como de costume. No entanto, se algum arquivo estiver desatualizado, em vez de ser criado, um erro será relatado e o build vai falhar. Essa opção pode ser útil para determinar se um build tem foi realizada mais recentemente do que uma edição de origem (por exemplo, para pré-envio de testes) sem incorrer no custo de um build.

Consulte também --check_tests_up_to_date.

--[no]compile_one_dependency

Compila uma única dependência dos arquivos de argumento. Isso é útil para a sintaxe de arquivos de origem em ambientes de desenvolvimento integrado, por exemplo, reconstruindo uma de destino que depende do arquivo de origem para detectar erros possível no ciclo de edição/criação/teste. Esse argumento afeta a maneira como todos os argumentos sem sinalizações são interpretados: cada argumento precisa ser um rótulo de destino de arquivo ou um nome de arquivo simples relativo ao diretório de trabalho atual, e uma regra que depende de cada nome de arquivo de origem é criada. Para C++ e Java fontes, regras no mesmo espaço de linguagem são escolhidas preferencialmente. Para várias regras com a mesma preferência, a que aparece primeiro no arquivo BUILD é escolhida. Um padrão de destino nomeado explicitamente que não referenciar um arquivo de origem resulta em erro.

--save_temps

A opção --save_temps faz com que as saídas temporárias do compilador sejam salvas. Isso inclui arquivos .s (código assembler), .i (pré-processado em C) e .ii (C++ pré-processados). Essas saídas geralmente são úteis para depuração. As temperaturas programadas só serão gerado para o conjunto de destinos especificados na linha de comando.

Observação: a implementação de --save_temps não usa o -save-temps. Em vez disso, há dois cartões, um com -S e outra com -E. Uma consequência disso é que, se o build falhar, o Bazel pode não ter produzido os arquivos ".i" ou ".ii" e ".s". Se você estiver tentando usar --save_temps para depurar uma compilação com falha, talvez seja necessário usar --keep_going para que o Bazel ainda tente produzir os arquivos pré-processados após a falha na compilação.

No momento, a sinalização --save_temps funciona somente para regras cc_*.

Para garantir que o Bazel imprima o local dos arquivos de saída adicionais, verifique se a configuração --show_result n está alta o suficiente.

--build_tag_filters=tag[,tag]*

Se especificado, o Bazel cria apenas destinos que têm pelo menos uma tag obrigatória (se alguma delas for especificada) e não tem tags excluídas. Tag de build filtro é especificado como uma lista delimitada por vírgulas de palavras-chave de tag; opcionalmente, precedido por "-" usado para indicar tags excluídas. As tags obrigatórias também podem ter um sinal "+" antes.

Ao executar testes, o Bazel ignora --build_tag_filters para destinos de teste. que são criados e executados mesmo que não correspondam a esse filtro. Para não construí-los, filtre destinos de teste usando --test_tag_filters ou os excluindo explicitamente.

--test_size_filters=size[,size]*

Se especificado, o Bazel vai testar (ou compilar se --build_tests_only) também é especificado) somente testes com o tamanho determinado. O filtro de tamanho do teste é especificado como uma lista delimitada por vírgulas de valores de tamanho de teste permitidos (pequeno, médio, grande ou enorme), opcionalmente precedida pelo sinal "-" usado para indicar tamanhos de teste excluídos. Por exemplo,

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

e

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

testará somente testes pequenos e médios em //foo.

Por padrão, a filtragem de tamanho de teste não é aplicada.

--test_timeout_filters=timeout[,timeout]*

Se especificado, o Bazel vai testar (ou criar, se --build_tests_only também for especificado) apenas destinos de teste com o tempo limite fornecido. Testar filtro de tempo limite é especificado como uma lista delimitada por vírgulas de valores de tempo limite de teste permitidos (curtos, moderado, longo ou eterno), opcionalmente precedido por "-" usado para indicar tempos limite de teste excluídos. Consulte --test_size_filters para conferir um exemplo de sintaxe.

Por padrão, a filtragem de tempo limite do teste não é aplicada.

--test_tag_filters=tag[,tag]*

Se especificado, o Bazel vai testar (ou compilar se --build_tests_only) também é especificada) somente destinos de teste que tenham pelo menos uma tag obrigatória (se alguma delas for especificada) e não tem tags excluídas. Tag de teste filtro é especificado como uma lista delimitada por vírgulas de palavras-chave de tag; opcionalmente, precedido por "-" usado para indicar tags excluídas. As tags obrigatórias também podem têm um sinal "+" antes sinal

Por exemplo,

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

testa os destinos marcados com performance ou stress, mas não são marcadas com flaky.

Por padrão, a filtragem de tags de teste não é aplicada. Também é possível filtrar nas tags size e local do teste em dessa maneira.

--test_lang_filters=string[,string]*

Especifica uma lista separada por vírgulas de strings referentes aos nomes da regra de teste classes. Para se referir à classe de regra foo_test, use a string "foo". O Bazel vai testar (ou criar, se --build_tests_only também for especificado) apenas alvos das classes de regra referenciadas. Para excluir essas segmentações, use pela string "-foo". Por exemplo,

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

vai testar apenas os destinos que são instâncias de foo_test ou bar_test em //baz/..., enquanto

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

vai testar todos os destinos em //baz/..., exceto as instâncias foo_test e bar_test.

Dica: você pode usar bazel query --output=label_kind "//p:t" para descobrir o nome da classe de regra do destino //p:t. E você pode olhar o par de pilhas de instanciação na saída de bazel query --output=build "//p:t" para saber por que esse destino é uma instância dessa classe de regra.

Aviso: o nome da opção "--test_lang_filter" é vestigial e, portanto, é enganoso. Não faça suposições sobre a semântica com base no nome.

--test_filter=filter-expression

Especifica um filtro que o executor de testes pode usar para escolher um subconjunto de testes para em execução. Todos os destinos especificados na invocação são criados, mas dependendo a expressão. Apenas alguns deles podem ser executados; em alguns casos, apenas alguns métodos de teste são executados.

A interpretação específica de filter-expression depende de o framework responsável por executar o teste. Pode ser um glob, substring ou regexp. --test_filter é uma conveniência passando diferentes argumentos de filtro --test_arg, mas nem todos os frameworks aceitam.

Verbosidade

Essas opções controlam o nível de detalhamento da saída do Bazel, no terminal ou em outros arquivos de registro.

--explain=logfile

Essa opção, que exige um argumento de nome de arquivo, faz com que o verificador de dependências na fase de execução de bazel build explique, para cada etapa de build, por que ela está sendo executada ou que ela está atualizada. A explicação é gravada no arquivo de registro.

Se você encontrar reconstruções inesperadas, essa opção pode ajudar a entender o motivo. Adicione-o ao .bazelrc para que a geração de registros ocorre em todos os builds subsequentes e, em seguida, inspeciona o registro quando uma etapa de execução é executada inesperadamente. Esta opção pode ter uma pequena queda de desempenho, e convém remover quando não forem mais necessários.

--verbose_explanations

Essa opção aumenta a quantidade de detalhes das explicações geradas quando a opção --explain está ativada.

Se as explicações detalhadas estiverem ativadas, e um arquivo de saída é recriado porque o comando usado para o build tiver sido alterado, a saída no arquivo de explicação incluem os detalhes completos do novo comando (pelo menos para a maioria .

Usar essa opção pode aumentar significativamente a duração do de explicação gerado e a penalidade de desempenho ao usar --explain:

Se --explain não estiver ativado, --verbose_explanations não terá efeito.

--profile=file

Essa opção, que usa um argumento de nome de arquivo, faz com que o Bazel grave dados de perfil em um arquivo. Em seguida, os dados podem ser analisados ou analisados usando o comando bazel analyze-profile. O perfil de build pode ser útil para entender onde o comando build do Bazel está gastando tempo.

--[no]show_loading_progress

Essa opção faz com que o Bazel gere mensagens de progresso de carregamento de pacotes. Se estiver desativada, as mensagens não serão mostradas.

--[no]show_progress

Essa opção faz com que as mensagens de progresso sejam exibidas. Ela fica ativada por padrão. Quando desativado, as mensagens de progresso são suprimidas.

--show_progress_rate_limit=n

Essa opção faz com que o Bazel mostre no máximo uma mensagem de progresso por n segundos, em que n é um número real. O valor padrão desta opção é 0,02, o que significa que o Bazel vai limitar o progresso. uma mensagem a cada 0,02 segundo.

--show_result=n

Essa opção controla a impressão das informações de resultado no final de um comando bazel build. Por padrão, se um único destino de build for especificado, o Bazel imprimirá uma mensagem informando se ou não, o destino foi atualizado com sucesso e, em caso afirmativo, a lista de arquivos de saída criados pelo destino. Se várias destino forem especificados, as informações do resultado não serão exibidas.

Embora as informações do resultado possam ser úteis para builds de um único destino ou alguns destinos, para builds grandes (como um repositório árvore de projeto), essas informações podem ser esmagadoras e distrativas; essa opção permite que ele seja controlado. --show_result usa um argumento de número inteiro, que é o número máximo de alvos para o qual as informações completas do resultado devem ser impressas. Por padrão, o valor será 1. Acima desse limite, nenhuma informação de resultado é mostrada para metas individuais. Assim, o valor zero faz com que as informações do resultado sejam suprimidas sempre, e um valor muito grande faz com que o resultado seja impresso sempre.

Os usuários podem querer escolher um valor intermediário se alternarem regularmente entre a criação de um pequeno grupo de destinos (por exemplo, durante o ciclo de compilação-edição-teste) e um grande grupo de destinos (por exemplo, ao estabelecer um novo espaço de trabalho ou executar testes de regressão). No primeiro caso, as informações do resultado são muito útil, enquanto no último caso não é. Assim como em todos os essa opção pode ser especificada implicitamente por arquivo .bazelrc.

Os arquivos são impressos para facilitar a cópia e a colagem do nome do arquivo ao shell, para executar executáveis compilados. A fase "atualizado" ou "falha" as mensagens para cada destino podem ser facilmente analisadas por scripts que impulsionam o build.

--sandbox_debug

Essa opção faz com que o Bazel imprima informações de depuração extras ao usar o sandbox para execução de ações. Essa opção também preserva os diretórios de sandbox, para que os arquivos visíveis para as ações durante a execução podem ser examinadas.

--subcommands (-s)

Essa opção faz com que a fase de execução do Bazel mostre a linha de comando completa para cada comando antes de executá-lo.

  >>>>> # //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)

Sempre que possível, os comandos são impressos em uma sintaxe compatível com o shell Bourne, para que possam ser facilmente copiados e colados em um prompt de comando do shell. Os parênteses são fornecidos para proteger seu shell contra as chamadas cd e exec. Não se esqueça de copiá-los. No entanto, alguns comandos são implementados internamente no Bazel, como a criação de árvores de links simbólicos. Para esses casos, não há linha de comando para exibir.

--subcommands=pretty_print pode ser transmitido para impressão os argumentos do comando como uma lista, e não como uma única linha. Isso pode ajudar a tornar linhas de comando longas mais legíveis.

Consulte também --verbose_failures abaixo.

Para gerar registros de subcomandos em um arquivo em um formato compatível com ferramentas, consulte --execution_log_json_file e --execution_log_binary_file.

--verbose_failures

Essa opção faz com que a fase de execução do Bazel imprima a linha de comando completa para comandos que falharam. Isso pode ser inestimável para depurar build com falha.

Os comandos com falha são impressos em uma sintaxe compatível com o shell Bourne, adequada para copiar e colar em um prompt de shell.

Status do espaço de trabalho

Use essas opções para "carimbar" binários criados pelo Bazel: para incorporar outras informações nos binários, como a revisão de controle de origem ou outras informações relacionadas ao espaço de trabalho. É possível usar esse mecanismo com regras que oferecem suporte ao atributo stamp, como genrule, cc_binary e muito mais.

--workspace_status_command=program

Essa flag permite especificar um binário que o Bazel executa antes de cada build. O programa pode informar informações sobre o status do espaço de trabalho, como a revisão atual do controle de origem.

O valor da flag precisa ser um caminho para um programa nativo. No Linux/macOS, isso pode ser qualquer executável. No Windows, ele precisa ser um binário nativo, normalmente um arquivo ".exe", ".bat" ou ".cmd".

O programa precisa mostrar zero ou mais pares de chave-valor na saída padrão, uma entrada em cada linha. e sair com zero (caso contrário, o build falhará). Os nomes das chaves podem ser qualquer coisa, mas só podem usar letras maiúsculas e sublinhados. O primeiro espaço após o nome da chave a separa do . O valor é o restante da linha (incluindo espaços em branco adicionais). Nem a chave nem o valor podem abranger várias linhas. As chaves não podem ser duplicadas.

O Bazel particiona as chaves em dois buckets: "stable" e "volatile". Os nomes "estável" e "volátil" são um pouco contra-intuitivos, então não pense muito neles.

Em seguida, o Bazel grava os pares de chave-valor em dois arquivos:

• bazel-out/stable-status.txt contém todas as chaves e valores em que o nome da chave começa com STABLE_
• bazel-out/volatile-status.txt contém o restante das chaves e seus valores

O contrato é:

• "estável" chaves" valores devem mudar raramente, se possível. Se o conteúdo de bazel-out/stable-status.txt mudar, o Bazel invalida as ações que dependem dele. Em Em outras palavras, se o valor de uma chave estável mudar, o Bazel vai executar novamente as ações marcadas. Portanto, o status estável não deve conter elementos como carimbos de data/hora, porque eles mudam todos e faria com que o Bazel executasse novamente ações estampadas em cada build.

  O Bazel sempre gera as seguintes chaves estáveis:

  • BUILD_EMBED_LABEL: valor de --embed_label
  • BUILD_HOST: o nome da máquina host em que o Bazel está sendo executado.
  • BUILD_USER: o nome do usuário em que o Bazel está sendo executado

• "volátil" chaves" os valores podem mudar com frequência. O Bazel espera que elas mudem o tempo todo, como os carimbos de data/hora, e atualiza devidamente o arquivo bazel-out/volatile-status.txt. Para evitar sempre executando ações estampadas, o Bazel finge que o arquivo volátil nunca mudanças. Em outras palavras, se o arquivo de status volátil for o único arquivo cujo conteúdo mudou, o Bazel não invalidará as ações que dependem dele. Se outras entradas das ações forem alteradas, o Bazel vai executar a ação novamente, e a ação vai conferir o status, mas a alteração do status volátil por si só não invalida a ação.

  O Bazel sempre gera as seguintes chaves voláteis:

  • BUILD_TIMESTAMP: tempo do build em segundos desde a época Unix (o valor de System.currentTimeMillis() dividido por mil)
  • FORMATTED_DATE: horário do build. Formatado como yyyy MMM d HH mm ss EEE(por exemplo, 2 de junho de 2023, 1o de junho de 2023, 29h, 29h) em UTC.

No Linux/macOS, você pode transmitir --workspace_status_command=/bin/true para desativar a recuperação do status do espaço de trabalho, porque true não faz nada, com êxito (saia com zero) e não gera nenhum resultado. No Windows, é possível transmitir o caminho do true.exe do MSYS para ter o mesmo efeito.

Se o comando de status do espaço de trabalho falhar (sair em um número diferente de zero) por qualquer motivo, o build falhará.

Exemplo de programa no Linux usando o 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"

Transmita o caminho do programa com --workspace_status_command, e o arquivo de status estável vai incluir as linhas STABLE, e o arquivo de status volátil vai incluir o restante das linhas.

--[no]stamp

Esta opção, em conjunto com o atributo de regra stamp, controla se é preciso para incorporar informações do build em binários.

A marcação pode ser ativada ou desativada explicitamente de acordo com a regra usando o atributo stamp. Consulte a Enciclopédia de Criação para mais detalhes. Quando uma regra definir stamp = -1 (o padrão para *_binary regras), esta opção determina se a estampagem está ativada.

O Bazel nunca carimba binários criados para a configuração de execução, independente dessa opção ou do atributo stamp. Para regras que definem stamp = 0 (o padrão para regras *_test), a impressão é desativada, independentemente de --[no]stamp. Especificar --stamp não força os destinos a serem recriados se suas dependências não mudaram.

A configuração --nostamp geralmente é desejável para o desempenho do build, porque ela reduz a volatilidade de entrada e maximiza o armazenamento em cache do build.

Plataforma

Use essas opções para controlar as plataformas de host e de destino que configuram como os builds funcionam e quais plataformas de execução e conjuntos de ferramentas estão disponíveis para as regras do Bazel.

Consulte informações básicas sobre plataformas e conjuntos de ferramentas.

--platforms=labels

Os rótulos das regras da plataforma que descrevem as plataformas de destino do comando atual.

--host_platform=label

O rótulo de uma regra de plataforma que descreve o sistema host.

--extra_execution_platforms=labels

As plataformas que estão disponíveis como plataformas de execução para executar ações. As plataformas podem ser especificadas por destino exato ou como um padrão de destino. Essas plataformas serão consideradas antes das declaradas nos arquivos MODULE.bazel por register_execution_platforms(). Essa opção aceita uma lista de plataformas separadas por vírgulas em ordem de prioridade. Se a sinalização for transmitida várias vezes, as substituições mais recentes serão feitas.

--extra_toolchains=labels

As regras do conjunto de ferramentas a serem consideradas durante a resolução. Conjuntos de ferramentas pode ser especificado por destino exato ou como um padrão de destino. Esses conjuntos de ferramentas ser consideradas antes dos declarados nos arquivos MODULE.bazel pelo register_toolchains().

--toolchain_resolution_debug=regex

Imprime informações de depuração ao encontrar toolchains se o tipo de toolchain corresponder ao regex. Várias regex podem ser separadas por vírgulas. A regex pode ser negado usando um - no início. Isso pode ajudar os desenvolvedores de regras do Bazel ou do Starlark com falhas de depuração devido a toolchains ausentes.

Diversos

--flag_alias=alias_name=target_path

Uma sinalização de conveniência usada para vincular configurações de build mais longas do Starlark a um nome mais curto. Para mais mais detalhes, consulte a Configurações do Starlark.

--symlink_prefix=string

Altera o prefixo dos links simbólicos de conveniência gerados. O o valor padrão para o prefixo do link simbólico é bazel-, que vai criar os links simbólicos bazel-bin, bazel-testlogs e bazel-genfiles.

Se não for possível criar os links simbólicos por qualquer motivo, será exibido um aviso emitida, mas o build ainda é considerado um sucesso. Especificamente, você poderá criar em um diretório somente leitura ou em um que permissão de gravação. Todos os caminhos impressos em mensagens de informações no final de um build só vão usar a forma curta relativa ao link simbólico se os links apontarem para o local esperado. Em outras palavras, você pode confiar na correção desses caminhos, mesmo que não possa confiar nos links simbólicos criados.

Alguns valores comuns dessa opção:

• Suprimir a criação de symlinks: --symlink_prefix=/ fará com que o Bazel não crie nem atualize nenhum symlink, incluindo os symlinks bazel-out e bazel-<workspace>. Use essa opção para suprimir completamente a criação de links simbólicos.

• Facilite a organização: --symlink_prefix=.bazel/ vai fazer com que o Bazel crie links simbólicos chamados bin (etc.) dentro de um diretório oculto .bazel.

--platform_suffix=string

Adiciona um sufixo ao nome curto da configuração, que é usado para determinar no diretório de saída. Definir esta opção com valores diferentes coloca os arquivos em diretórios diferentes, por exemplo, para melhorar as taxas de ocorrência em cache para builds que prejudicam uns aos outros os arquivos de saída ou mantêm os arquivos de saída para fins de comparação.

--default_visibility=(private|public)

Flag temporária para testar mudanças de visibilidade padrão do Bazel. Não se destina ao uso geral, mas foi documentado para fins de completude.

--starlark_cpu_profile=_file_

Essa flag, que tem o valor do nome de um arquivo, faz com que o Bazel colete estatísticas sobre o uso de CPU por todas as linhas de execução do Starlark. e criar o perfil no formato pprof ao arquivo nomeado.

Use essa opção para ajudar a identificar funções do Starlark que que tornam o carregamento e a análise lentos devido à computação excessiva. Exemplo:

$ 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 visualizações diferentes dos mesmos dados, teste os comandos pprof svg, web e list.

Como usar o Bazel para lançamentos

Ele é usado por engenheiros de software durante o desenvolvimento e por engenheiros de lançamento ao preparar binários para implantação à produção. Esta seção apresenta uma lista de dicas para engenheiros de lançamento que usam o Bazel.

Opções significativas

Ao usar o Bazel para builds de lançamento, os mesmos problemas surgem que para outros scripts que executam um build. Para mais detalhes, consulte Chamar o Bazel de scripts. Especificamente, as seguintes opções são altamente recomendadas:

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

Estas opções também são importantes:

• --package_path
• --symlink_prefix: para gerenciar builds para várias configurações, pode ser conveniente distinguir cada build por um identificador distinto, como "64 bits" x "32 bits". Esta opção diferencia os links simbólicos de bazel-bin (etc.).

Como executar testes

Para criar e executar testes com o Bazel, digite bazel test seguido de o nome dos destinos de teste.

Por padrão, esse comando executa atividades de build e teste simultâneas, criando todos os destinos especificados (incluindo destinos não de teste especificados na linha de comando) e testando *_test e test_suite assim que os pré-requisitos são criados, o que significa que a execução do teste é intercalada com a criação. Isso geralmente resulta em problemas ganhos de velocidade.

Opções de bazel test

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

Se essa opção estiver definida como "automática", (padrão), o Bazel só vai executar novamente um teste as seguintes condições se aplicam:

• O Bazel detecta mudanças no teste ou nas dependências dele.
• o teste está marcado como external
• várias execuções de teste foram solicitadas com --runs_per_test
• o teste falhou.

Se "não", todos os testes serão executados incondicionalmente.

Se "sim", o comportamento do armazenamento em cache será o mesmo que o automático exceto que pode armazenar em cache falhas de teste e execuções de teste com --runs_per_test:

Observação :os resultados do teste sempre são salvos na árvore de saída do Bazel. independentemente de essa opção estar ativada. não é necessário usar --cache_test_results execuções anteriores de bazel test para receber ocorrências em cache. A opção só afeta se o Bazel vai usar resultados salvos anteriormente, não se ele vai salvar os resultados da execução atual.

Os usuários que ativaram essa opção por padrão no arquivo .bazelrc podem achar as abreviações -t (ativado) ou -t- (desativado) convenientes para substituir o padrão em uma execução específica.

--check_tests_up_to_date

Essa opção diz ao Bazel para não executar os testes, mas apenas verificar e relatar os resultados armazenados em cache. Se houver testes que não foram criados e executados anteriormente ou com resultados de testes desatualizados (por exemplo, devido a o código-fonte ou as opções de build tiverem mudado), o Bazel vai informar uma mensagem de erro ("o resultado do teste não está atualizado") status como "SEM STATUS" (em vermelho, se a saída de cor estiver ativada) e retornará um código de saída diferente de zero.

Essa opção também implica Comportamento de --check_up_to_date.

Essa opção pode ser útil para verificações antes do envio.

--test_verbose_timeout_warnings

Esta opção diz ao Bazel para avisar explicitamente o usuário se o tempo limite de um teste for muito maior do que o tempo de execução real do teste. Enquanto um teste deve ser definido de modo que não seja instável, um teste que tem uma um tempo limite muito generoso pode ocultar problemas reais que surgem inesperadamente.

Por exemplo, um teste que normalmente é executado em um ou dois minutos não deve ter tempo limite de ETERNAL ou LONG porque são generosos demais.

Essa opção é útil para ajudar os usuários a decidir sobre um bom valor de tempo limite ou verificação de integridade dos valores de tempo limite.

Observação: cada fragmento de teste tem o tempo limite alocado Meta de XX_test. O uso dessa opção não afeta o valor do tempo limite de um teste, apenas avisa se o Bazel achar que o tempo limite pode ser restrito ainda mais.

--[no]test_keep_going

Por padrão, todos os testes são executados até a conclusão. Se essa sinalização estiver desativada, No entanto, o build é cancelado em qualquer teste que não passe. Etapas de build subsequentes e as invocações de teste não são executadas, e as invocações em andamento são canceladas. Não especifique --notest_keep_going e --keep_going ao mesmo tempo.

--flaky_test_attempts=attempts

Essa opção especifica o número máximo de vezes que um teste precisa ser tentado se ele falhar por qualquer motivo. um teste que falha inicialmente, mas eventualmente bem-sucedidos é relatado como FLAKY no resumo do teste. No entanto, ele é considerado aprovado quando se trata de identificar o código de saída do Bazel ou o número total de testes aprovados. Os testes que falham em todas as tentativas permitidas são foram consideradas reprovadas.

Por padrão (quando essa opção não é especificada ou quando é definida como padrão), apenas uma tentativa é permitida para testes regulares, e 3 para regras de teste com o atributo flaky definido. É possível especificar um valor inteiro para substituir o limite máximo de tentativas de teste. O Bazel permite no máximo 10 tentativas de teste para evitar abusos do sistema.

--runs_per_test=[regex@]number

Essa opção especifica o número de vezes que cada teste precisa ser executado. Tudo execuções de teste são tratadas como testes separados (funcionalidade substituto se aplicam a cada uma delas de maneira independente).

O status de um destino com falhas em execuções depende do valor Sinalização --runs_per_test_detects_flakes:

• Se ausente, qualquer execução com falha fará com que todo o teste falhe.
• Se estiver presente e duas execuções do mesmo fragmento retornarem PASS e FAIL, o teste receberá o status de instável, a menos que outras execuções com falhas causem a falha.

Se um único número for especificado, todos os testes serão executados na mesma quantidade de vezes. Como alternativa, uma expressão regular pode ser especificada usando a sintaxe regex@número. Isso restringe o efeito de --runs_per_test às metas que correspondem ao regex (--runs_per_test=^//pizza:.*@4 executa todos os testes menos de //pizza/ quatro vezes). Esse tipo de --runs_per_test pode ser especificado mais de uma vez.

--[no]runs_per_test_detects_flakes

Se essa opção for especificada (por padrão, não é), o Bazel detectará erros fragmentos de teste usando --runs_per_test. Se uma ou mais execuções para um único fragmento e uma ou mais execuções para o mesmo passe de fragmento, o destino será considerada irregular com a sinalização. Se não for especificado, o destino informará uma o status de falha.

--test_summary=output_style

Especifica como o resumo do resultado do teste deve ser exibido.

• short imprime os resultados de cada teste junto com o nome do o arquivo que contém a saída do teste em caso de falha. Esse é o valor padrão.
• terse como short, mas ainda mais curto: mostra apenas informações sobre testes que não foram aprovados.
• detailed imprime cada caso de teste individual que falhou, não apenas para cada teste. Os nomes dos arquivos de saída de teste são omitidos.
• none não imprime o resumo do teste.

--test_output=output_style

Especifica como a saída do teste deve ser exibida:

• summary mostra um resumo de se cada teste foi aprovado ou reprovado. Também mostra o nome do arquivo de registro de saída dos testes com falha. Resumo será impresso no final da compilação (durante a criação, veria apenas mensagens de progresso simples quando os testes são iniciados, aprovados ou reprovados). Esse é o comportamento padrão.
• errors envia uma saída combinada stdout/stderr de testes com falha apenas para a stdout imediatamente após a conclusão do teste, garantindo que a saída de testes simultâneos não é intercalada entre si. Imprime um resumo no build de acordo com a saída de resumo acima.
• all é semelhante a errors, mas mostra a saída para todos os testes, incluindo aqueles que foram aprovados.
• O streamed transmite a saída stdout/stderr de cada teste em tempo real.

--java_debug

Essa opção faz com que a máquina virtual Java de um teste Java aguarde uma conexão de um Depurador compatível com JDWP antes de iniciar o teste. Essa opção implica --test_output=streamed.

--[no]verbose_test_summary

Por padrão, essa opção é ativada, o que faz com que os tempos de teste e outras (como tentativas de teste) a serem impressas no resumo do teste. Se --noverbose_test_summary for especificado, o resumo do teste vai incluir apenas o nome do teste, o status do teste e o indicador de teste em cache e vai ser formatado para ficar dentro de 80 caracteres, quando possível.

--test_tmpdir=path

Especifica o diretório temporário para testes executados localmente. Cada teste será em um subdiretório separado dentro desse diretório. O diretório vai ser limpos no início de cada comando bazel test. Por padrão, o Bazel colocará esse diretório no diretório base de saída do Bazel.

Observação :esse é um diretório para executar testes, não para armazenar resultados. Eles sempre são armazenados no diretório bazel-out.

--test_timeout=seconds OU --test_timeout=seconds,seconds,seconds,seconds

Substitui o valor do tempo limite para todos os testes usando o número especificado de segundos como um novo valor de tempo limite. Se apenas um valor for fornecido, ele será ser usado para todas as categorias de tempo limite de teste.

Como alternativa, quatro valores separados por vírgulas podem ser fornecidos, especificando tempos limite individuais para testes curtos, moderados, longos e eternos (nessa ordem). De qualquer forma, zero ou um valor negativo para qualquer um dos tamanhos de teste ser substituídos pelo tempo limite padrão pelas categorias de tempo limite fornecidas conforme definida pela página Como programar testes. Por padrão, o Bazel vai usar esses limites de tempo para todos os testes, inferindo o limite de tempo do tamanho do teste, seja implícito ou explícito.

Os testes que declaram explicitamente a categoria de tempo limite como distinta do tamanho vão receber o mesmo valor como se esse tempo limite tivesse sido definido implicitamente pela tag de tamanho. Então, um teste de tamanho "pequeno" que declara um "longo" tempo limite vai têm o mesmo tempo limite efetivo que um "large" que os testes não têm com políticas tempo limite.

--test_arg=arg

Transmite opções/flags/argumentos da linha de comando para cada processo de teste. Isso pode ser usada várias vezes para passar vários argumentos. Por exemplo, --test_arg=--logtostderr --test_arg=--v=3.

Observe que, ao contrário do comando bazel run, não é possível transmitir argumentos de teste. diretamente como em bazel test -- target --logtostderr --v=3. Isso acontece porque argumentos estranhos transmitidos para bazel test são interpretados como destinos de teste adicionais. Ou seja, --logtostderr e --v=3 seriam interpretados individualmente como uma destino do teste. Essa ambiguidade não existe para um comando bazel run, que apenas aceita um destino.

--test_arg pode ser transmitido para um comando bazel run, mas será ignorado, a menos que o que está sendo executado é um destino de teste. Como qualquer outra flag, se ela for transmitida em um comando bazel run após um token --, não será processada pelo Bazel, mas encaminhada literalmente para o destino executado.

--test_env=variable=_value_ OU --test_env=variable

Especifica variáveis adicionais que precisam ser injetadas no teste para cada teste. Se value não for especificado, ele será herdado do ambiente de shell usado para iniciar o comando bazel test.

O ambiente pode ser acessado em um teste usando System.getenv("var") (Java), getenv("var") (C ou C++),

--run_under=command-prefix

Isso especifica um prefixo que o executor de testes vai inserir na frente do comando de teste antes de executá-lo. O command-prefix é dividido em palavras usando as regras de tokenização do shell Bourne, e a lista de palavras é adicionada ao comando que será executado.

Se a primeira palavra for um rótulo totalmente qualificado (começa com //) é criado. Em seguida, o rótulo é substituído pelo local executável correspondente que é adicionado ao comando que será executado com as outras palavras.

Algumas ressalvas se aplicam:

• O PATH usado para executar testes pode ser diferente do PATH no seu ambiente. Portanto, talvez seja necessário usar um caminho absoluto para o comando --run_under (a primeira palavra em command-prefix).
• stdin não está conectado, portanto, --run_under não pode ser usado para comandos interativos.

Exemplos:

        --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'

Seleção de teste

Conforme documentado em Opções de seleção de saída, é possível filtrar testes por tamanho, tempo limite, tag ou idioma. Uma conveniência filtro de nome geral pode encaminhar determinados filtrar args para o executor de testes.

Outras opções para bazel test

A sintaxe e as outras opções são exatamente iguais bazel build

Como executar executáveis

O comando bazel run é semelhante a bazel build, mas ele é usado para criar e executar um único destino. Esta é uma sessão típica (//java/myapp:myapp diz olá e mostra os 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

Observação: o -- é necessário para que o Bazel não interprete --arg1 e --arg2 como opções do Bazel, mas como parte da linha de comando para executar o binário. Além disso, o Bazel evita o registro desses argumentos no console caso elas contêm informações sensíveis.

O bazel run é semelhante, mas não idêntico, para invocar diretamente o binário criado pelo Bazel, e o comportamento dele é diferente dependendo se o binário a ser invocado é um teste ou não.

Quando o binário não for um teste, o diretório de trabalho atual será o árvore de arquivos de execução do binário.

Quando o binário for um teste, o diretório de trabalho atual será a raiz "exec" e uma tentativa de boa-fé é feita para replicar os testes de ambiente geralmente são ser executado. No entanto, a emulação não é perfeita, e testes com vários fragmentos não podem ser executados dessa maneira (a opção de linha de comando --test_sharding_strategy=disabled pode ser usada para contornar esse problema).

As seguintes variáveis de ambiente extras também estão disponíveis para o binário:

• BUILD_WORKSPACE_DIRECTORY: a raiz do espaço de trabalho em que o build foi executado.
• BUILD_WORKING_DIRECTORY: o diretório de trabalho atual em que o Bazel foi executado.

Elas podem ser usadas, por exemplo, para interpretar nomes de arquivos na linha de comando de uma maneira fácil de usar.

Opções de bazel run

--run_under=command-prefix

Isso tem o mesmo efeito que a opção --run_under para bazel test (veja acima), exceto que se aplica ao comando que está sendo executado por bazel run em vez dos testes sendo executados por bazel test. e não podem ser executados sob o rótulo.

Como filtrar saídas de geração de registros do Bazel

Ao invocar um binário com bazel run, o Bazel imprime a saída de geração de registros do Bazel. e o binário em invocação. Para deixar os registros com menos ruído, é possível suprima as saídas do próprio Bazel com os métodos --ui_event_filters e --noshow_progress.

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

Como executar testes

O bazel run também pode executar binários de teste, o que tem o efeito de executar o teste em uma aproximação do ambiente descrito em Como programar testes. Nenhum dos argumentos --test_* tem efeito ao executar um teste dessa maneira, exceto --test_arg.

Como limpar saídas de build

O comando clean

O Bazel tem um comando clean, análogo ao do Make. Ele exclui os diretórios de saída de todas as configurações de build realizadas por essa instância do Bazel ou toda a árvore de trabalho criada por essa instância do Bazel e redefine os caches internos. Se executada sem nenhuma opções de linha de comando e, em seguida, o diretório de saída para todas as configurações que serão limpos.

Lembre-se de que cada instância do Bazel está associada a um único espaço de trabalho. Portanto, o comando clean exclui todas as saídas de todos os builds que você fez com essa instância do Bazel nesse espaço de trabalho.

Para remover completamente toda a árvore de trabalho criada por uma instância do Bazel, especifique a opção --expunge. Quando executado com --expunge, o comando clean simplesmente remove toda a árvore de base de saída que, além do build saída, contém todos os arquivos temporários criados pelo Bazel. Ela também interrompe o servidor do Bazel após a limpeza, equivalente ao comando shutdown. Por exemplo, para limpar todos os rastros de disco e memória de uma instância do Bazel, especificar:

  % bazel clean --expunge

Como alternativa, é possível eliminar em segundo plano usando --expunge_async: É seguro invocar um comando do Bazel no mesmo cliente enquanto a exclusão assíncrona continua sendo executada.

Observação: isso pode causar contenção de E/S.

O comando clean é fornecido principalmente como um meio de recuperar espaço em disco para espaços de trabalho que não são mais necessários. As recompilações incrementais do Bazel podem não ser perfeitos, para que clean possa ser usado para recuperar um bloco quando surgem problemas.

O design do Bazel permite que esses problemas sejam corrigidos e esses bugs são de alta prioridade. Se você encontrar um build incremental incorreto, envie um relatório de bug e informe bugs nas ferramentas em vez de usar clean.

Como consultar o gráfico de dependências

O Bazel inclui uma linguagem de consulta para fazer perguntas sobre o gráfico de dependência usado durante o build. A linguagem de consulta é usada por dois comandos: consulta e cconsulta. A principal diferença entre os dois comandos é que a consulta é executada após a fase de carregamento e a consulta C é executada após a fase de análise. Essas ferramentas são uma ajuda valiosa para muitas tarefas de engenharia de software.

A linguagem de consulta é baseada na ideia operações algébricas sobre gráficos; está documentado em detalhes

Referência de consulta do Bazel. Consulte esse documento para referência, exemplos e opções de linha de comando específicas da consulta.

A ferramenta de consulta aceita várias opções de linha de comando. --output seleciona o formato de saída. --[no]keep_going (desativado por padrão) faz com que a consulta para continuar a progredir com os erros. esse comportamento pode ser desativado se um resultado incompleto não for aceitável em caso de erros.

A opção --[no]tool_deps, ativado por padrão, faz com que as dependências em configurações que não sejam de destino sejam incluídas no gráfico de dependência em que a consulta opera.

A opção --[no]implicit_deps, ativada por padrão, faz com que dependências implícitas a serem incluídas no gráfico de dependências sobre o qual a consulta opera. Uma dependência implícita não é especificada explicitamente no arquivo BUILD, mas é adicionada pelo Bazel.

Exemplo: "Mostrar os locais das definições (em arquivos BUILD) de todas as regras gerais necessárias para criar todos os testes na árvore PEBL".

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

Como consultar o gráfico de ações

Atenção: o comando aquery ainda é experimental, e a API dele vai mudar.

O comando aquery permite consultar ações no gráfico de build. Ele opera no gráfico de destino configurado após a análise e expõe informações sobre ações, artefatos e as relações deles.

A ferramenta aceita várias opções de linha de comando. --output seleciona o formato de saída. O formato de saída padrão (text) é legível. Use proto ou textproto para legível por máquina. O comando aquery é executado sobre um build regular do Bazel e herda o conjunto de opções disponíveis durante um build.

Ela suporta o mesmo conjunto de funções que também está disponível para query, mas siblings, buildfiles e tests.

Para mais detalhes, consulte Consulta do gráfico de ações.

Comandos e opções diversas

help

O comando help oferece ajuda on-line. Por padrão, ele mostra um resumo dos comandos e tópicos de ajuda disponíveis, conforme mostrado em Como criar com o Bazel. Especificar um argumento mostra ajuda detalhada para um tópico específico. A maioria dos tópicos são comandos do Bazel, como build ou query, mas existem alguns tópicos de ajuda adicionais que não correspondem a comandos.

--[no]long (-l)

Por padrão, o bazel help [topic] imprime apenas uma resumo das opções relevantes para um tópico. Se a opção --long for especificada, o tipo, o valor padrão e a descrição completa de cada opção também é impressa.

shutdown

Os processos do servidor do Bazel podem ser interrompidos usando o shutdown. kubectl. Esse comando faz com que o servidor Bazel seja encerrado assim que se tornar ocioso (por exemplo, após a conclusão de quaisquer builds ou outras comandos que estão em andamento). Para mais detalhes, consulte Implementação de cliente/servidor.

Como os servidores do Bazel são interrompidos após um tempo limite de inatividade, esse comando raramente é necessário; No entanto, pode ser útil em scripts quando for conhecido que nenhuma outra construção ocorrerá em um determinado espaço de trabalho.

shutdown aceitou uma --iff_heap_size_greater_than _n_, que requer um argumento de número inteiro (em MB). Se especificado, isso faz com que o encerramento com base na quantidade de memória já consumida. Isso é útil para scripts que iniciam muitos builds, porque qualquer vazamento de memória no servidor do Bazel pode causar falhas ocasionais. A execução de uma reinicialização condicional evita essa condição.

info

O comando info imprime vários valores associados à instância do servidor do Bazel ou a uma configuração de build específica. Elas podem ser usadas por scripts que direcionam um build.

O comando info também permite um único argumento (opcional), que é o nome de uma das chaves na lista abaixo. Neste caso, bazel info key só vai imprimir o valor dessa chave. Isso é bastante conveniente quando criar o script do Bazel para evitar a necessidade de canalizar o resultado. até sed -ne /key:/s/key://p:

Dados independentes de configuração

• release: o rótulo de lançamento para essa instância do Bazel ou "versão de desenvolvimento" se não for um binário lançado.
• workspace o caminho absoluto para o diretório de espaço de trabalho base.

• install_base: o caminho absoluto para a instalação. da instância do Bazel usado pela instância do Bazel para o usuário atual. Júlio instala os executáveis internamente necessários abaixo desse diretório.

• output_base: o caminho absoluto para a saída base. da instância do Bazel usado pela instância do Bazel para o usuário atual e de espaço de trabalho. O Bazel coloca todo o rascunho e o build abaixo desse diretório.

• execution_root: o caminho absoluto para a execução. diretório raiz em output_base. Esse diretório é a raiz de todos os arquivos acessíveis aos comandos executados durante o build e é o diretório de trabalho desses comandos. Se o diretório do espaço de trabalho for gravável, uma link simbólico chamado bazel-<workspace> está ali apontando para esse diretório.

• output_path: o caminho absoluto para o diretório de saída abaixo da raiz de execução usada para todos os arquivos gerados como resultado de comandos de build. Se o diretório do espaço de trabalho for gravável, um link simbólico com o nome bazel-out é colocado ali apontando para este diretório.

• server_pid: o ID do processo do servidor do Bazel.

• server_log: o caminho absoluto para o arquivo de registro de depuração do servidor do Bazel. Esse arquivo contém informações de depuração de todos os comandos durante o ciclo de vida do servidor do Bazel e é destinado ao consumo humano por desenvolvedores e usuários avançados do Bazel.

• command_log: o caminho absoluto para o arquivo de registro do comando. contém os streams intercalados stdout e stderr dos mais recentes do Bazel. A execução de bazel info vai substituir o conteúdo desse arquivo, já que ele se torna o comando mais recente do Bazel. No entanto, o local do arquivo de registro do comando não será alterado, a menos que você mude a configuração de --output_base ou --output_user_root opções.

• used-heap-size, committed-heap-size, max-heap-size: informa vários parâmetros de tamanho de heap da JVM. Respectivamente: memória usada no momento, memória garantida no momento para estar disponível para a JVM no sistema, a alocação máxima possível.

• gc-count, gc-time: a contagem cumulativa de coletas de lixo desde o início deste servidor Bazel e o tempo gasto para realizá-las. Esses valores não são redefinidos no início de cada build.

• package_path: uma lista separada por dois-pontos de caminhos que seriam procurou pacotes pelo Bazel. Tem o mesmo formato do argumento de linha de comando de build --package_path.

Exemplo: o ID do processo do servidor do Bazel.

% bazel info server_pid
1285

Dados específicos da configuração

Esses dados podem ser afetados pelas opções de configuração transmitidas para bazel info, por exemplo, --cpu, --compilation_mode etc. O comando info aceita todas as opções que controlam a análise de dependência, já que algumas delas determinam a localização do diretório de saída de um build, a escolha do compilador etc.

• bazel-bin, bazel-testlogs e bazel-genfiles: informa o caminho absoluto para os diretórios bazel-* em que os programas gerados pelo build estão localizados. Isso geralmente é o mesmo que os links simbólicos bazel-* criados no diretório de espaço de trabalho de base após uma compilação bem-sucedida. No entanto, se o diretório do espaço de trabalho for somente leitura, nenhum link simbólico bazel-* poderá ser criado. Scripts que usam o valor relatado por bazel info, em vez de presumir o existência do link simbólico será mais robusto.
• O guia "Marca" de código aberto. Se a flag --show_make_env for especificada, todas as variáveis no ambiente "Make" da configuração atual também serão exibidas (como CC, GLIBC_VERSION etc.). Essas são as variáveis acessadas usando o método $(CC) ou varref("CC") dentro dos arquivos BUILD.

Exemplo: o compilador C++ para a configuração atual. Essa é a variável $(CC) no ambiente "Make", portanto, a flag --show_make_env é necessária.

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

Exemplo: o diretório de saída bazel-bin para o diretório atual configuração do Terraform. Essa informação está correta mesmo nos casos em que Por algum motivo, não é possível criar o link simbólico bazel-bin. por exemplo, ao compilar de um diretório somente leitura.

% 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 e --version

O comando "version" mostra os detalhes da versão do Bazel criado. binário, incluindo a lista de alterações em que ele foi criado e a data. Eles são especialmente úteis para determinar se você tem a versão o Bazel ou caso você esteja relatando bugs. Alguns dos valores interessantes são:

• changelist: a lista de alterações em que esta versão do O Bazel foi lançado.
• label: o rótulo da versão deste Bazel. instância ou "versão de desenvolvimento" se este não for um lançamento binário. Muito útil ao informar bugs.

bazel --version, sem outros argumentos, vai emitir a mesma saída que bazel version --gnu_format, exceto sem o efeito colateral de potencialmente iniciar um servidor do Bazel ou descompactar o arquivo do servidor. O bazel --version pode ser executado de qualquer lugar, sem a necessidade de um diretório de espaço de trabalho.

mobile-install

O comando mobile-install instala apps em dispositivos móveis. No momento, apenas dispositivos Android com o ART são compatíveis.

Consulte bazel mobile-install para ver mais informações.

Observação: esse comando não instala o mesmo que bazel build produz: o Bazel ajusta o app para que ele possa ser criados, instalados e reinstalados rapidamente. No entanto, isso deve ocorrer, transparentes para o app.

As seguintes opções são compatíveis:

--incremental

Se definido, o Bazel tenta instalar o app de forma incremental, ou seja, apenas as partes que mudaram desde o último build. Não é possível atualizar os recursos referenciado de AndroidManifest.xml, código nativo ou Java (como os referenciados por Class.getResource()). Se essas as coisas mudarem, essa opção deve ser omitida. Contrariando o espírito do Bazel e devido às limitações da plataforma Android, é responsabilidade do usuário saber quando esse comando é bom o suficiente e quando uma instalação completa é necessária.

Se você usa um dispositivo com o Marshmallow ou uma versão mais recente, considere as flag --split_apks.

--split_apks

Define se os APKs divididos devem ser usados para instalar e atualizar o app no dispositivo. Funciona apenas com dispositivos com o Marshmallow ou versões mais recentes. A flag --incremental não é necessária ao usar --split_apks.

--start_app

Inicia o app em um estado limpo após a instalação. É equivalente a --start=COLD.

--debug_app

Espera que o depurador seja anexado antes de iniciar o app em um estado limpo após a instalação. É equivalente a --start=DEBUG.

--start=_start_type_

Como o app deve ser iniciado após a instalação. Os _start_type_s compatíveis são:

• NO Não inicia o app. Esse é o padrão.
• COLD Inicia o app em um estado limpo após a instalação.
• WARM Preserva e restaura o estado do aplicativo em instalações incrementais.
• DEBUG Aguarda o depurador antes de iniciar o app em um estado limpo após a instalação.

Observação: se mais de um dos valores --start=_start_type_, --start_app ou --debug_app for definido, o último valor será usado.

--adb=path

Indica o binário adb a ser usado.

O padrão é usar o adb no SDK do Android especificado por --android_sdk

--adb_arg=serial

Argumentos extras para adb. Eles vêm antes do subcomando na linha de comando e normalmente são usados para especificar em qual dispositivo será instalado. Por exemplo, para selecionar o dispositivo ou emulador Android que será usado:

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

invoca adb como

adb -s deadbeef install ...

--incremental_install_verbosity=number

O nível de detalhes da instalação incremental. Defina como 1 para que o registro de depuração seja impresso no console.

dump

O comando dump é impresso em stdout um despejo do interno do servidor Bazel. Esse comando é destinado principalmente ao uso por desenvolvedores do Bazel. Portanto, a saída desse comando não é especificada e está sujeita a alterações.

Por padrão, o comando apenas imprime uma mensagem de ajuda descrevendo as possíveis opções para despejar áreas específicas do estado do Bazel. Para despejar o estado interno, pelo menos uma das opções precisa ser especificada.

As seguintes opções são aceitas:

• --action_cache despeja o conteúdo do cache da ação.
• --packages armazena o conteúdo do cache do pacote.
• --skyframe faz o despejo de estado do gráfico de dependências interno do Bazel.
• --rules faz o download do resumo de cada regra e classe de aspecto, incluindo contagens e contagens de ações. Isso inclui regras nativas e Starlark. Se o rastreamento de memória estiver ativado, o consumo de memória das regras também será impresso.
• --skylark_memory despeja um arquivo .gz compatível com pprof para o caminho especificado. É necessário ativar o rastreamento de memória para que isso funcione.

Monitoramento de memória

Alguns comandos dump exigem rastreamento de memória. Para ativar, você precisa transmitir sinalizações de inicialização para o Bazel:

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

O java-agent é verificado no Bazel em third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar, então não se esqueça de ajustar $BAZEL para o local em que o repositório do Bazel será armazenado.

Não se esqueça de transmitir essas opções para o Bazel em todos os comandos, ou o servidor será reiniciado.

Exemplo:

    % 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

O comando analyze-profile analisa um perfil de rastreamento JSON coletado anteriormente durante uma invocação do Bazel.

canonicalize-flags

O comando canonicalize-flags, que recebe uma lista de opções para um comando do Bazel e retorna uma lista de opções com o mesmo efeito. A nova lista de opções é canônica. Por exemplo: duas listas de opções com o mesmo efeito são canonizadas na mesma lista nova.

A opção --for_command pode ser usada para selecionar entre diferentes comandos No momento, apenas build e test são compatíveis. Opções que o comando não oferece suporte causam um erro.

Observação :um pequeno número de opções não pode ser reordenado, porque o Bazel não garantem que o efeito seja idêntico. Observe também que este comando não expande as sinalizações de --config.

Como exemplo:

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

Opções de inicialização

As opções descritas nesta seção afetam a inicialização da máquina virtual Java usada pelo processo do servidor Bazel e se aplicam a todos os comandos subsequentes processados por esse servidor. Se já existe servidor do Bazel em execução e as opções de inicialização não corresponderem, ele vai e será reiniciada.

Todas as opções descritas nesta seção devem ser especificadas usando o --key=value ou --key value . Além disso, essas opções precisam aparecer antes do nome do Bazel kubectl. Use startup --key=value para listá-los em um arquivo .bazelrc.

--output_base=dir

Essa opção requer um argumento de caminho, que precisa especificar um diretório gravável. O Bazel vai usar esse local para gravar toda a saída. A base de saída também é a chave pela qual o cliente localiza o servidor do Bazel. Ao alterar a base de saída, você altera o servidor que vai processar o comando.

Por padrão, a base de saída é derivada do nome de login do usuário, e o nome do diretório do espaço de trabalho (na verdade, o resumo MD5), Assim, um valor típico será semelhante a este: /var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e:

Observação: o cliente usa a base de saída para encontrar a instância do servidor Bazel. Portanto, se você especificar uma base de saída diferente em um comando Bazel, um servidor diferente será encontrado (ou iniciado) para processar a solicitação. É possível executar dois builds simultâneos no mesmo diretório de espaço de trabalho variando a base de saída.

Exemplo:

 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

Nesse comando, os dois comandos do Bazel são executados simultaneamente (por causa do operador & do shell), cada um usando uma instância de servidor do Bazel diferente (devido às diferentes bases de saída). Por outro lado, se a base de saída padrão fosse usada nos dois comandos, as duas solicitações seriam enviadas ao mesmo servidor, que as processaria sequencialmente: primeiro o build //foo, seguido por um build incremental de //bar.

Observação: recomendamos não usar um NFS ou um sistema de arquivos em rede semelhante para a raiz porque a latência de acesso maior gera builds visivelmente mais lentos.

--output_user_root=dir

Indica o diretório raiz em que as bases de saída e de instalação são criadas. O diretório não pode existir ou pertencer ao usuário que fez a chamada. Antes, ter permissão para apontar para um diretório compartilhado por vários usuários mas não são mais permitidos. Isso pode ser permitido uma vez O problema 11100 foi resolvido.

Se a opção --output_base for especificada, ela vai substituir usando --output_user_root para calcular a base de saída.

O local da base de instalação é calculado com base em --output_user_root, além da identidade MD5 dos binários incorporados do Bazel.

Use a opção --output_user_root para escolher local de base alternativo para todas as saídas do Bazel (base de instalação e saída se houver um local melhor no layout do seu sistema de arquivos.

Observação: recomendamos que você não use um NFS ou um sistema de arquivos em rede semelhante para o diretório raiz, porque a latência de acesso mais alta causa builds visivelmente mais lentos.

--server_javabase=dir

Especifica a máquina virtual Java em que o Bazel é executado. O valor precisa ser um caminho para diretório que contém um JDK ou JRE. Ele não deve ser um rótulo. Essa opção precisa aparecer antes de qualquer comando do Bazel, por exemplo:

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

Essa flag não afeta as JVMs usadas pelos subprocessos do Bazel, como aplicativos, testes ferramentas e assim por diante. Use as opções de build --javabase ou --host_javabase.

Essa flag era chamada de --host_javabase (às vezes chamada de --host_javabase do "lado esquerdo"), mas foi renomeada para evitar confusão com a flag de build --host_javabase (às vezes chamada de --host_javabase do "lado direito").

--host_jvm_args=string

Especifica uma opção de inicialização a ser transmitida para a máquina virtual Java em que o próprio Bazel é usado. é executado. Isso pode ser usado para definir o tamanho da pilha, por exemplo:

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

Essa opção pode ser usada várias vezes com argumentos individuais. Observe que configurar essa flag raramente será necessária. Também é possível transmitir uma lista de strings separada por espaços, cada uma delas será interpretada como um argumento separado da JVM, mas esse recurso será descontinuado em breve.

Isso não afeta nenhuma JVM usada por subprocessos do Bazel: aplicativos, testes, ferramentas etc. Para transmitir opções da JVM a programas Java executáveis, seja por bazel run ou na linha de comando, use o argumento --jvm_flags, que é compatível com todos os programas java_binary e java_test. Como alternativa, para testes, use bazel test --test_arg=--jvm_flags=foo ....

--host_jvm_debug

Essa opção faz com que a máquina virtual Java aguarde uma conexão de um depurador compatível com JDWP antes chamando o método principal do próprio Bazel. Isso ocorre principalmente destinado aos desenvolvedores do Bazel.

Observação: isso não afeta nenhuma JVMs usadas por subprocessos do Bazel: aplicativos, testes, ferramentas etc.

--autodetect_server_javabase

Essa opção faz com que o Bazel busque automaticamente um JDK instalado na inicialização. e para voltar para o JRE instalado se o JRE incorporado não estiver disponível. --explicit_server_javabase pode ser usado para escolher um JRE explícito para que executa o Bazel.

--batch

O modo em lote faz com que o Bazel não use a modo padrão de cliente/servidor, mas executa um Bazel java para um único comando, que foi usado em sistemas semântica com relação ao tratamento de sinais, controle de jobs e ambiente herança variável e é necessário para executar o Bazel em uma jail chroot.

O modo de lote mantém a semântica de fila adequada na mesma output_base. Ou seja, as invocações simultâneas serão processadas em ordem, sem sobreposição. Se um modo de lote do Bazel for executado em um cliente com um servidor em execução, ele primeiro encerrará o servidor antes de processar o comando.

O Bazel é executado mais lentamente no modo de lote ou com as alternativas descritas acima. Isso ocorre porque, entre outras coisas, o cache do arquivo de build está presente na memória, portanto, não é preservado entre invocações sequenciais em lote. Portanto, o uso do modo de lote geralmente faz mais sentido em casos em que a performance é menos crítica, como builds contínuos.

Aviso: --batch é consideravelmente mais lento do que o modo padrão de cliente/servidor. Além disso, é possível que ele não seja compatível com todos os recursos e otimizações que são possibilitadas por um servidor Bazel permanente. Se você usa --batch Para fins de isolamento de build, use a opção de comando --nokeep_state_after_build, que garante que nenhum valor incremental o estado na memória é mantido entre builds. Para reiniciar o servidor Bazel e a JVM após uma versão, faça isso explicitamente usando a opção "encerramento" .

--max_idle_secs=n

Essa opção especifica quanto tempo, em segundos, o processo do servidor do Bazel precisa esperar após a última solicitação do cliente antes de sair. O o valor padrão é 10.800 (3 horas). --max_idle_secs=0 faz com que o processo do servidor do Bazel persista indefinidamente.

Observação :essa flag só será lida se o Bazel precisar iniciar um novo servidor. Alterar essa opção não fará com que o servidor seja reiniciado.

Essa opção pode ser usada por scripts que invocam o Bazel para garantir que eles não deixam processos do servidor do Bazel na máquina do usuário ao não estaria em execução de outra forma. Por exemplo, um script de pré-envio pode querer invoque bazel query para garantir que um bloco de anúncios mudança não introduz dependências indesejadas. No entanto, se o usuário não tiver feito uma versão recente nesse espaço de trabalho, seria que o script de pré-envio inicie um servidor Bazel. para que ele permaneça ocioso pelo resto do dia. Ao especificar um valor pequeno de --max_idle_secs na solicitação de consulta, o script pode garantir que se ele fez com que um novo servidor fosse iniciado, esse servidor será encerrado imediatamente, mas se já houvesse um servidor em execução, ele continuaria em execução até ficar ocioso pelo tempo normal. Obviamente, o modelo o timer de inatividade do servidor será redefinido.

--[no]shutdown_on_low_sys_mem

Se ativada e --max_idle_secs estiver definida com uma duração positiva, depois que o servidor de compilação estiver ocioso por um tempo, encerre-o quando o sistema estiver com pouca memória. Somente no Linux.

Além de executar uma verificação de inatividade correspondente a max_idle_secs, o servidor de build também começa a monitorar a memória disponível do sistema depois que o servidor fica ocioso por algum tempo. Se a memória disponível do sistema ficar criticamente baixa, o servidor será fechado.

--[no]block_for_lock

Se ativado, o Bazel aguardará outros comandos que contenham a que o bloqueio do servidor seja concluído antes de progredir. Se desativado, o Bazel vai sair com um erro se não conseguir adquirir a trava imediatamente e prosseguir.

Os desenvolvedores podem usar isso nas verificações de pré-envio para evitar esperas longas causadas por outro comando do Bazel no mesmo cliente.

--io_nice_level=n

Define um nível de 0 a 7 para a programação de E/S de melhor esforço. 0 é a prioridade mais alta, 7 é o menor. O programador antecipado só pode atender até a prioridade 4. Valores negativos são ignorados.

--batch_cpu_scheduling

Usar a programação de CPU batch para o Bazel. Esta política é útil para cargas de trabalho não interativas, mas que não querem reduzir seu valor adequado. Consulte "man 2 sched_setscheduler". Esta política pode oferecer uma estrutura que torne o sistema interatividade, em detrimento da capacidade de processamento do Bazel.

Opções diversas

--[no]announce_rc

Controla se o Bazel anuncia opções de inicialização e opções de comando lidas dos arquivos bazelrc na inicialização.

--color (yes|no|auto)

Esta opção determina se o Bazel vai usar cores para destacar a saída dele na tela.

Se essa opção for definida como yes, a saída de cores será ativada. Se esta opção for definida como auto, o Bazel vai usar a saída de cor somente se a saída está sendo enviada para um terminal e a variável de ambiente TERM for definido como um valor diferente de dumb, emacs ou xterm-mono. Se esta opção for definida como no, a saída de cor será desativada. com ou sem destino a um terminal ou terminal. da configuração da variável de ambiente TERM.

--config=name

Seleciona outra seção de configuração dos arquivos rc. Para o command atual, ele também extrai as opções de command:name, se essa seção existir. Pode ser especificados várias vezes para adicionar sinalizações de várias seções de configuração. As expansões podem se referir a outras definições (por exemplo, podem ser encadeadas).

--curses (yes|no|auto)

Essa opção determina se o Bazel vai usar controles do cursor na saída da tela. Isso resulta em menos dados de rolagem stream de saída compacto e fácil de ler do Bazel. Isso funciona bem com --color:

Se esta opção for definida como yes, o uso dos controles do cursor será ativado. Se esta opção for definida como no, o uso dos controles do cursor será desativado. Se essa opção for definida como auto, o uso dos controles do cursor será ativado nas mesmas condições de --color=auto.

--[no]show_timestamps

Se especificado, um carimbo de data/hora é adicionado a cada mensagem gerada pelo Bazel, especificando o horário em que a mensagem foi exibida.