Comandos e opções

Nesta página, abordamos as opções disponíveis para vários comandos do Bazel, como bazel build, bazel run e bazel test. Esta página é um complemento para a lista de comandos do Bazel em Criar com o Bazel.

Sintaxe de destino

Alguns comandos, como build ou test, podem operar em uma lista de destinos. Eles usam uma sintaxe mais flexível do que os rótulos, conforme documentado em Como especificar destinos para criação.

Opções

As seções abaixo descrevem as opções disponíveis durante uma criação. 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 ele é especificado várias vezes, a última instância vence. 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

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 dele. Ela é uma lista ordenada separada por dois pontos de diretórios do Bazel, cada um sendo a raiz de uma á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á usado em relação ao diretório bazel delimitado mais próximo. Por exemplo, se o diretório de trabalho for /home/bob/clients/bob_client/bazel/foo, a string %workspace% no caminho do pacote vai ser expandida para /home/bob/clients/bob_client/bazel.
3. Qualquer outro item é usado em relação ao diretório de trabalho. Geralmente, isso não é o que você quer fazer e pode se comportar de maneira inesperada se você usar o Bazel nos diretórios abaixo do espaço de trabalho do Bazel. Por exemplo, se você usar o elemento de caminho do pacote . e, em seguida, usar cd no diretório /home/bob/clients/bob_client/bazel/foo, os pacotes serão resolvidos a partir do diretório /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. Assim, você pode fazer um build em um espaço de trabalho vazio do bazel se todos os pacotes necessários puderem ser encontrados em outro lugar no caminho do pacote.

Exemplo: como criar usando um cliente vazio

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

--deleted_packages

Essa opção especifica uma lista de pacotes separada por vírgulas que o Bazel deve considerar excluídos e não tenta carregar de qualquer diretório no caminho do pacote. Isso pode ser usado para simular a exclusão de pacotes sem realmente excluí-los.

Verificação de erros

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

--[no]check_visibility

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

--output_filter=regex

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

Veja 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 transmitirá para outras ferramentas.

--copt=cc-option

Essa opção usa um argumento que será transmitido para o compilador. O argumento será passado para o compilador sempre que for invocado para pré-processamento, compilação e/ou montagem de código C, C++ ou assembler. Ele não será transmitido na vinculação.

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

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

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

Observação: mudar as configurações de --copt forçará uma recompilação de todos os arquivos de objetos afetados. Observe também que os valores de copts listados em regras específicas de build cc_library ou cc_binary serão colocados na linha de comando do compilador após essas opções.

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

--host_copt=cc-option

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

--host_conlyopt=cc-option

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

--host_cxxopt=cc-option

Essa opção usa um argumento que será transmitido ao compilador para arquivos de origem C++ compilados na configuração do host. Isso é análogo à opção --cxxopt, mas se aplica apenas à configuração do host.

--host_linkopt=linker-option

Essa opção usa um argumento que será transmitido ao vinculador para arquivos de origem compilados na configuração do host. Isso é análogo à opção --linkopt, mas se aplica apenas à configuração do host.

--conlyopt=cc-option

Essa opção usa um argumento que será transmitido para o compilador ao compilar arquivos de origem em C.

Isso é semelhante a --copt, mas se aplica apenas à compilação em C, não à compilação ou vinculação em C++. Você pode transmitir opções específicas de C (como -Wno-pointer-sign) usando --conlyopt.

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

--cxxopt=cc-option

Essa opção usa um argumento que será transmitido para o compilador ao compilar arquivos de origem C++.

Isso é semelhante a --copt, mas se aplica apenas à compilação em C++, não à compilação ou vinculação em C. Você pode 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 cc_library ou cc_binary específicas são colocados na linha de comando do compilador após essas opções.

--linkopt=linker-option

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

Isso é semelhante a --copt, mas se aplica apenas à vinculação, não à compilação. Você pode transmitir opções do 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 de todos os binários e bibliotecas compartilhadas invocando o vinculador com a opção -Wl,--strip-debug. --strip=always significa sempre remover informações de depuração. --strip=never significa que 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 gerados.

Observação: para informações de depuração, não basta desativar a remoção. Também é necessário garantir que elas tenham sido geradas pelo compilador. Isso pode ser feito usando -c dbg ou --copt -g.

A opção --strip do Bazel corresponde à opção --strip-debug do ld: ela só remove informações de depuração. Se, por algum motivo, você quiser remover todos os símbolos, não apenas os símbolos debug, use a opção --strip-all do ld, transmitindo --linkopt=-Wl,--strip-all para o Bazel. Esteja ciente de que configurar a flag --strip do Bazel vai substituir --linkopt=-Wl,--strip-all, então você só precisa definir uma ou outra.

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

--stripopt=strip-option

Essa é uma opção adicional 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 do binário principal com [--strip](#flag--strip)=(always|sometimes).

--fdo_instrument=profile-output-dir

A opção --fdo_instrument permite a geração de saída de perfil de otimização direcionada por feedback (FDO, na sigla em inglês) quando o binário C/C++ criado é executado. Para o GCC, o argumento fornecido é usado como 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.

Depois que a árvore de dados do perfil for gerada, ela precisa ser compactada e fornecida à opção --fdo_optimize=profile-zip Bazel para ativar a compilação otimizada para FDO.

Para o compilador LLVM, o argumento também é o diretório em que os arquivos brutos de dados de perfil do LLVM são descartados. 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 do 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 .gcda gerada anteriormente com as informações de perfil de cada arquivo .o.

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

Observação: essa opção também aceita rótulos que são resolvidos para 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 do 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.

--[no]output_symbol_counts

Se ativado, cada link gold de um binário executável C++ vai gerar um arquivo de contagem de símbolos (por meio da opção ouro --print-symbol-counts). Para cada entrada do vinculador, o arquivo registra o número de símbolos que foram definidos e o número de símbolos usados no binário. Essa informação pode ser usada para acompanhar dependências de links desnecessárias. O símbolo de contagem do arquivo é gravado no caminho de saída do binário com o nome [targetname].sc.

Esta opção é desativada por padrão.

--java_language_version=version

Esta opção especifica a versão das origens 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 é 11. --> Os valores possíveis são: 8, 9, 10, 11, 14 e 15 e podem ser estendidos ao registrar conjuntos de ferramentas Java personalizados 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 é 11.

--java_runtime_version=version

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

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

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

O valor padrão é localjdk. Os valores possíveis são: localjdk, localjdk_version, remotejdk_11 e remote_jdk17. É possível estender os valores registrando uma JVM personalizada usando as regras de repositório local_java_repository ou remote_java_repostory.

--tool_java_runtime_version=version

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

--jvmopt=jvm-option

Essa opção permite que os argumentos da opção sejam transmitidos para a VM do 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

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

--javacopt=javac-option

Essa opção permite que argumentos de opção sejam passados para javac. Ele 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 do javac (em vez do padrão do Bazel).

A opção é transmitida para javac após as 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 para javac são:

  -source 8 -target 8 -encoding UTF-8

Observação: mudar as configurações de --javacopt forçará uma recompilação de todas as classes afetadas. Os parâmetros javacopts listados em regras específicas de build java_library ou java_binary vão ser colocados na linha de comando javac depois dessas opções.

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

Essa opção controla se o javac verifica se há dependências diretas ausentes. Os destinos Java precisam declarar explicitamente todos os destinos usados diretamente como dependências. Essa sinalização instrui o javac a determinar os jars realmente usados para a verificação de tipo de cada arquivo Java e avisa/erro 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 vai gerar avisos Java padrão do tipo [strict] para cada dependência direta ausente.
• default, strict e error, tudo isso significa que o javac gera erros em vez de avisos, fazendo com que o destino atual não seja criado se alguma dependência direta for encontrada. Esse também é o comportamento padrão quando a sinalização não está especificada.

Semântica de 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, geralmente reduzida 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 modo de compilação diferente. Assim, você pode alternar entre os modos sem precisar fazer uma recompilação completa sempre.

• 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 criar com a depuração ativada (-g), para que você possa usar o gdb (ou outro depurador).
• opt significa criar com a otimização ativada e com chamadas assert() desativadas (-O2 -DNDEBUG). As informações de depuração não serão geradas no modo opt, a menos que você também transmita --copt -g.

--cpu=cpu

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

Observação: uma combinação específica de versão 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. Nesse caso, o valor será extraído 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 à mesma variável em várias sinalizações --action_env, a atribuição mais recente vencerá.

--experimental_action_listener=label

Aviso :as ações extras foram descontinuadas. Em vez disso, use aspects.

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 do build.

--[no]experimental_extra_action_top_level_only

Aviso :as ações extras foram descontinuadas. Em vez disso, use aspects.

Se essa opção for definida como verdadeira, as ações extras especificadas pela opção de linha de comando --experimental_action_listener serão programadas apenas para destinos de nível superior.

--experimental_extra_action_filter=regex

Aviso :as ações extras foram descontinuadas. Em vez disso, use aspects.

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

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

Por padrão, todos os extra_actions no fechamento transitivo dos destinos solicitados para criação são programados para execução. --experimental_extra_action_filter restringe a programação a extra_actions, em que o rótulo do proprietário corresponde à expressão regular especificada.

O exemplo a seguir limita a programação de extra_actions para que se aplique 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 usada para criar ferramentas de host.

--fat_apk_cpu=cpu[,cpu]*

As CPUs para criar bibliotecas C/C++ no deps transitivo das regras android_binary. Outras regras C/C++ não foram afetadas. Por exemplo, se um cc_library aparecer na deps transitiva de uma regra android_binary e em uma regra cc_binary, o cc_library será criado pelo menos duas vezes: uma para cada CPU especificada com --fat_apk_cpu para a regra android_binary e outra para a CPU especificada com --cpu para a regra cc_binary.

O padrão é armeabi-v7a.

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

Observação: é preciso selecionar uma ferramenta cruzada compatível com Android. Se uma regra android_ndk_repository for definida no arquivo do ESPAÇO DE TRABALHO, um crosstool compatível com o Android vai ser selecionado automaticamente. Caso contrário, o crostool pode ser selecionado com as sinalizações --android_crosstool_top ou --crosstool_top.

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

Quando presente, qualquer arquivo C++ com um rótulo ou um caminho de execução correspondente a uma das expressões regex de inclusão e que não corresponda a nenhuma das expressões de exclusão será criado com as opções oferecidas. 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 para o diretório do espaço de trabalho, incluindo o nome base (incluindo a extensão) do arquivo C++. Ele também inclui os prefixos dependentes da plataforma.

Observação :as opções serão usadas se apenas um dos rótulos ou do caminho de execução corresponder.

Para corresponder os arquivos gerados (como saídas de regra geral), o Bazel só pode usar o caminho de execução. Nesse caso, o regexp não deve começar com "//", já que ele não corresponde a nenhum caminho de execução. Os nomes de pacotes podem ser usados desta forma: --per_file_copt=base/.*\.pb\.cc@-g0. Ela 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 compilar com --compilation_mode=opt e compilar seletivamente alguns arquivos com a otimização mais forte ativada ou com a otimização desativada.

Ressalva: se alguns arquivos forem 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 um + para identificar padrões de inclusão e com - para identificar padrões de exclusão. option significa uma opção arbitrária transmitida para o compilador C++. Se uma opção contiver um ,, ela precisará ser citada da seguinte forma: \,. As opções também podem conter @, já que apenas o primeiro @ é usado 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 dinamicamente, interagindo com o atributo linkstatic nas regras de build.

Modos:

• auto: traduz para um modo dependente da plataforma. default para Linux e off para cygwin.
• default: permite que o Bazel escolha se quer vincular dinamicamente. Consulte linkstatic para mais informações.
• fully: vincula todos os destinos dinamicamente. Isso acelera o tempo de vinculação e reduz o tamanho dos binários resultantes.
• off: vincula todos os destinos no modo principalmente estático. Se -static for definido em linkopts, as segmentações vão mudar para totalmente estáticas.

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

Ativa a Fission, que grava informações de depuração em C++ em arquivos .dwo dedicados em vez de arquivos .o, onde aconteciam. Isso reduz significativamente o tamanho da entrada dos links e pode reduzir os tempos de vinculação.

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

--force_ignore_dash_static

Se essa sinalização for definida, todas as opções -static em linksopts de arquivos BUILD de regras cc_* serão ignoradas. Isso é apenas uma solução alternativa para builds de aumento da proteção do C++.

--[no]force_pic

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

Observação :os binários vinculados dinamicamente (por exemplo, --dynamic_mode fully) geram o código PIC, seja qual for a configuração dessa sinalização. Portanto, essa sinalização é útil para casos em que os usuários querem que o código PIC seja gerado explicitamente para links estáticos.

--android_resource_shrinking

Seleciona se a redução de recursos será realizada para as regras android_binary. Define o padrão para o atributo reduzir_recursos nas regras android_binary. Consulte a documentação dessa regra para mais detalhes. O padrão é desativado.

--custom_malloc=malloc-library-target

Quando especificada, usa sempre a implementação maloca especificada, substituindo todos os atributos malloc="target", incluindo os destinos que usam o padrão (sem especificar nenhum malloc).

--crosstool_top=label

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

--host_crosstool_top=label

Se não for especificado, o Bazel usará o valor de --crosstool_top para compilar código na configuração do host, como ferramentas executadas durante a compilação. O principal objetivo dessa flag é permitir a compilação cruzada.

--apple_crosstool_top=label

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

--android_crosstool_top=label

A crosstool a ser usada para compilar regras C/C++ no deps transitivo de regras android_binary. Isso é útil se outros destinos no build exigirem um crosstool diferente. O padrão é usar o crosstool gerado pela regra android_ndk_repository no arquivo do ESPAÇO DE TRABALHO. Consulte também --fat_apk_cpu.

--compiler=version

Essa opção especifica a versão do compilador C/C++ (como gcc-4.1.0) a ser usada para a compilação de binários durante o build. Se você quiser criar com uma crosstool personalizada, use um arquivo CROSSTOOL em vez de especificar essa flag.

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

--android_sdk=label

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

O SDK do Android será selecionado automaticamente se uma regra android_sdk_repository for definida no arquivo do ESPAÇO DE TRABALHO.

--java_toolchain=label

Essa opção especifica o rótulo do java_toolkit usado para compilar arquivos de origem Java.

--host_java_toolchain=label

Se não for especificado, o Bazel usará o valor de --java_toolchain para compilar código na configuração do host, como para ferramentas executadas durante a criação. O principal objetivo dessa flag é permitir a compilação cruzada.

--javabase=(label)

Essa opção define o rótulo da instalação básica do Java a ser usado para bazel run, teste do bazel e para binários Java criados pelas regras java_binary e java_test. As variáveis"Make" JAVABASE e JAVA são derivadas dessa opção.

--host_javabase=label

Essa opção define o rótulo da instalação básica do Java a ser usado na configuração do host, por exemplo, para ferramentas de build do host, incluindo JavaBuilder e Singlejar.

Essa ação não seleciona o compilador Java usado para compilar arquivos de origem Java. O compilador pode ser selecionado pelas configurações na opção --java_toolchain.

Estratégia de execução

Essas opções afetam a forma como o Bazel executa a versão. Eles não têm nenhum efeito significativo nos arquivos de saída gerados pelo build. Normalmente, o principal efeito delas é na velocidade de criação.

--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 dependências diretas nos atributos srcs, data e tools. O Bazel ativa o sandbox local por padrão em sistemas compatíveis com a execução no modo 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. Isso só estará disponível se um executor remoto tiver sido configurado separadamente.

--strategy mnemonic=strategy

Essa opção controla onde e como os comandos são executados, substituindo --spawn_strategy (e --genrule_strategy com mnemonic Genrule) em cada mnemônico. Consulte --spawn_strategy para conhecer as estratégias com suporte e os respectivos efeitos.

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

Essa opção especifica qual estratégia precisa ser usada para executar comandos com descrições correspondentes a um determinado regex_filter. Consulte --per_file_copt para ver detalhes sobre a correspondência de regex_filter. Consulte --spawn_strategy para conhecer as estratégias com suporte e os respectivos efeitos.

É usado o último regex_filter que corresponde à descrição. Essa opção substitui outras sinalizações para especificar a estratégia.

• Exemplo: --strategy_regexp=//foo.*\\.cc,-//foo/bar=local significa executar ações usando a 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 a inversão da ordem executa a compilação com local.
• Exemplo: --strategy_regexp='Compiling.*/bar=local,sandboxed' executa "Compilando //foo/bar/baz" com a estratégia local e volta para sandboxed se falhar.

--genrule_strategy=strategy

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

--jobs=n (-j)

Essa opção, que usa um argumento inteiro, especifica um limite para o número de jobs que precisam ser executados simultaneamente durante a fase de execução da versão.

Observação :o número de jobs simultâneos que o Bazel vai executar é determinado não apenas 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 estão disponíveis, com base em algumas estimativas (muito brutas) do consumo de cada job. O comportamento do programador pode ser controlado pela opção --local_ram_resources.

--progress_report_interval=n

O Bazel exibe periodicamente um relatório de progresso sobre jobs que ainda não foram concluídos, como testes de longa duração. Essa opção define a frequência de geração de relatórios. O progresso será mostrado a cada n segundos.

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

Quando o Bazel está usando o controle de 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 de CPU) que o Bazel pode considerar ao programar atividades de build e teste para serem executadas localmente. Elas usam 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 da configuração do sistema local.

--[no]build_runfile_links

Essa opção, que é ativada por padrão, especifica se os links simbólicos de arquivos de execução para testes e binários precisam ser criados no diretório de saída. 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 arquivos de execução.

Quando os testes (ou aplicativos) são executados, as dependências de dados do ambiente de execução são reunidas em um só lugar. Dentro da árvore de saída do Bazel, essa árvore "runfiles" normalmente tem acesso root 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/workspace/packagename/filename. A árvore de arquivos de execução garante que os testes tenham acesso a todos os arquivos em que eles têm uma dependência declarada e nada mais. Por padrão, a árvore de arquivos de execução é implementada com a criação de um conjunto de links simbólicos para os arquivos necessários. À medida que o conjunto de links cresce, o custo dessa operação aumenta. Para alguns builds grandes, isso pode contribuir significativamente para o tempo total de build, especialmente porque cada teste individual (ou aplicativo) requer a própria árvore de arquivos de execução.

--[no]build_runfile_manifests

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

Ela pode ser desativada 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 é ativada, o Bazel descarta o cache de análise antes do início da execução, liberando mais memória (cerca de 10%) para a fase de execução. A desvantagem é que builds incrementais serão mais lentos. Consulte também modo de economia de memória.

--[no]keep_going (mil)

Como no GNU Make, a fase de execução de um build é interrompida quando o primeiro erro é encontrado. Às vezes, é útil tentar criar o máximo possível, mesmo diante de erros. Essa opção ativa esse comportamento e, quando ela é especificada, o build tenta criar todos os destinos cujos pré-requisitos foram criados, mas ignora erros.

Embora essa opção geralmente esteja 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 somente alguns deles puderem ser analisados, o build vai ser interrompido com um erro, a menos que --keep_going seja especificado. Nesse caso, o build avançará 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 criará jars de interface que contêm apenas as assinaturas de métodos e campos de acesso público, protegido e padrão (pacote) e usa os jars de interface para compilar os destinos dependentes. Isso permite evitar a recompilação quando as mudanças são feitas apenas em corpos de métodos ou membros privados de uma classe.

Observação: o uso de --use_ijars pode fornecer uma mensagem de erro diferente quando você estiver se referindo acidentalmente a um membro não visível de outra classe. Em vez de receber um erro de que o membro não está visível, você receberá um erro de que o membro não existe. Mudar a configuração --use_ijars forçará uma recompilação de todas as classes afetadas.

--[no]interface_shared_objects

Essa opção ativa objetos compartilhados de interface, o que faz com que binários e outras bibliotecas compartilhadas dependam da interface de um objeto compartilhado, e não da implementação dela. Quando apenas a implementação muda, o Bazel pode evitar a recriação desnecessária de destinos que dependem da biblioteca compartilhada mudada.

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. Ela fica ativada por padrão. Quando ele é desligado, a fase de execução é ignorada 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 que é 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 ignora outros destinos especificados na linha de comando. Por padrão, essa opção está desativada, e o Bazel vai criar tudo o solicitado, incluindo as regras *_test e test_suite que foram filtradas dos 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 versão, apenas verifica se todos os destinos especificados estão atualizados. Em caso afirmativo, o build será concluído com êxito, como de costume. No entanto, se algum arquivo estiver desatualizado, em vez de ser criado, um erro será informado e o build falhará. Essa opção pode ser útil para determinar se um build foi executado mais recentemente do que uma edição de origem (por exemplo, para verificações de pré-envio) sem incorrer no custo de criação.

Consulte também --check_tests_up_to_date.

--[no]compile_one_dependency

Compilar uma única dependência dos arquivos de argumentos. Isso é útil para verificar a sintaxe de arquivos de origem em ambientes de desenvolvimento integrado, por exemplo, ao recriar um único destino que depende do arquivo de origem para detectar erros o mais cedo possível no ciclo de edição/criação/teste. Esse argumento afeta a forma como todos os argumentos que não são de sinalização 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

Em origens C++ e Java, regras no mesmo espaço de linguagem são escolhidas de preferência. Para várias regras com a mesma preferência, é escolhida aquela que aparece primeiro no arquivo BUILD. Um padrão de destino nomeado explicitamente que não se refere a 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), arquivos .i (C pré-processado) e .ii (C++ pré-processado). Essas saídas geralmente são úteis para depuração. As temperaturas serão geradas somente para o conjunto de destinos especificados na linha de comando.

Observação: a implementação de --save_temps não usa a flag -save-temps do compilador. Em vez disso, há dois cartões, um com -S e outro com -E. Uma consequência disso é que, se sua compilação falhar, talvez o Bazel ainda não tenha produzido os arquivos ".i", ".ii" e ".s". Se você estiver tentando usar --save_temps para depurar uma compilação com falha, talvez precise usar também --keep_going para que o Bazel ainda tente produzir os arquivos pré-processados depois que a compilação falhar.

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

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

--build_tag_filters=tag[,tag]*

Se especificado, o Bazel vai criar apenas destinos que tenham pelo menos uma tag obrigatória (se alguma delas for especificada) e não tenha tags excluídas. O filtro de tag de build é especificado como uma lista de palavras-chave de tag delimitada por vírgulas, opcionalmente precedida por um sinal "-" usado para indicar as tags excluídas. As tags obrigatórias também podem ter um sinal "+" anterior.

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 evitar a criação delas, filtre os destinos de teste usando --test_tag_filters ou excluindo-os explicitamente.

--test_size_filters=size[,size]*

Se especificado, o Bazel testa (ou cria, se --build_tests_only também for especificado) apenas destinos de teste com o tamanho determinado. O filtro de tamanho de teste é especificado como uma lista delimitada por vírgulas de valores de tamanho de teste permitidos (pequeno, médio, grande ou enorme), opcionalmente precedido por um 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á apenas 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 testa (ou cria, se --build_tests_only também for especificado) apenas destinos de teste com o tempo limite determinado. O filtro de tempo limite do teste é especificado como uma lista delimitada por vírgulas de valores de tempo limite de teste permitidos (curto, moderado, longo ou eterno), opcionalmente precedido pelo sinal "-", usado para indicar os tempos limite de teste excluídos. Consulte --test_size_filters para ver exemplos de sintaxe.

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

--test_tag_filters=tag[,tag]*

Se especificado, o Bazel testa (ou cria se --build_tests_only também for especificado) apenas destinos de teste que tenham pelo menos uma tag obrigatória (se alguma delas for especificada) e não tiver tags excluídas. O filtro de tag de teste é especificado como uma lista de palavras-chave de tag delimitada por vírgulas, opcionalmente precedida por um sinal "-" usado para indicar as tags excluídas. As tags obrigatórias também podem ter um sinal "+" anterior.

Por exemplo,

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

testa os destinos marcados com a tag performance ou stress, mas não com a tag flaky.

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

--test_lang_filters=lang[,lang]*

Especifica uma lista separada por vírgulas de idiomas de teste para idiomas com uma regra *_test oficial. Consulte enciclopédia de build para ver uma lista completa deles. Cada idioma pode ser precedido por "-" para especificar os idiomas excluídos. O nome usado para cada idioma precisa ser o mesmo que o prefixo do idioma na regra *_test, por exemplo, cc, java ou sh.

Se especificado, o Bazel testa (ou cria, se --build_tests_only também for especificado) apenas destinos dos idiomas especificados.

Por exemplo,

  % bazel test --test_lang_filters=cc,java foo/...

testará apenas os testes C/C++ e Java (definidos usando as regras cc_test e java_test, respectivamente) em foo/..., enquanto

  % bazel test --test_lang_filters=-sh,-java foo/...

executará todos os testes em foo/..., exceto sh_test e java_test.

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

--test_filter=filter-expression

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

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

Verbosidade

Essas opções controlam o detalhamento da saída do Bazel para o terminal ou para outros arquivos de registro.

--explain=logfile

Essa opção, que requer um argumento de nome de arquivo, faz com que o verificador de dependência na fase de execução de bazel build explique, para cada etapa de build, por que ele está sendo executado ou que está atualizado. A explicação é gravada em logfile.

Se você encontrar recriações inesperadas, essa opção pode ajudar a entender o motivo. Adicione-o a .bazelrc para que a geração de registros ocorra para todos os builds subsequentes. Em seguida, inspecione o registro quando uma etapa de execução for executada inesperadamente. Essa opção pode ter uma pequena queda de desempenho. Por isso, convém removê-la quando ela não for mais necessária.

--verbose_explanations

Essa opção aumenta o detalhamento das explicações geradas quando a opção --explain é ativada.

Em particular, se as explicações detalhadas estiverem ativadas e um arquivo de saída for recriado porque o comando usado para criá-lo mudou, a saída no arquivo de explicação incluirá todos os detalhes do novo comando (pelo menos para a maioria dos comandos).

O uso dessa opção pode aumentar significativamente o tamanho do arquivo de explicação gerado e a penalidade de desempenho do uso de --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 os dados de criação 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 é ativada por padrão. Quando desativadas, as mensagens de progresso são suprimidas.

--show_progress_rate_limit=n

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

--show_result=n

Essa opção controla a impressão de informações de resultado no final de um comando bazel build. Por padrão, se um único destino de build for especificado, o Bazel vai imprimir uma mensagem informando se o destino foi atualizado ou não e, em caso afirmativo, a lista de arquivos de saída criados pelo destino. Se vários destinos 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 de alguns destinos, para builds grandes (como uma árvore de projeto de nível superior inteira), essas informações podem ser sobrecarregadas e distraídas. Essa opção permite que ela seja controlada. --show_result usa um argumento inteiro, que é o número máximo de destinos em que as informações completas do resultado precisam ser impressas. Por padrão, o valor é 1. Acima desse limite, nenhuma informação de resultado é exibida para destinos individuais. Assim, o zero faz com que as informações do resultado sejam sempre suprimidas, e um valor muito grande faz com que o resultado seja sempre mostrado.

É possível que os usuários queiram escolher um valor entre eles se alternam regularmente entre a criação de um pequeno grupo de destinos (por exemplo, durante o ciclo de compilação/edição-teste) e um grupo grande 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 úteis, enquanto no último caso não são tão úteis. Como acontece com todas as opções, isso pode ser especificado implicitamente pelo arquivo .bazelrc.

Os arquivos são impressos para facilitar a cópia e a colagem do nome do arquivo no shell para executar executáveis compilados. As mensagens "atualizadas" ou "falhadas" para cada destino podem ser facilmente analisadas por scripts que geram um build.

--sandbox_debug

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

--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 Bourne Shell, para que possam ser facilmente copiados e colados em um prompt de comando do shell. Os parênteses ao redor são fornecidos para proteger seu shell das chamadas cd e exec. Copie-os. No entanto, alguns comandos são implementados internamente no Bazel, como a criação de árvores de links simbólicos. Para eles, não é necessário exibir uma linha de comando.

--subcommands=pretty_print pode ser transmitido para mostrar os argumentos do comando como uma lista em vez de uma única linha. Isso pode ajudar a tornar linhas de comando longas mais legíveis.

Veja 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 (links em inglês).

--verbose_failures

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

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

Status do espaço de trabalho

Use estas opções para "carigar" os binários criados pelo Bazel para incorporar mais informações aos binários, como a revisão de controle de origem ou outras informações relacionadas ao espaço de trabalho. Você pode 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 relatar informações sobre o status do espaço de trabalho, como a revisão de controle de origem atual.

O valor da flag precisa ser um caminho para um programa nativo. No Linux/macOS, qualquer executável. No Windows, 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 vai 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 valor. O valor é o resto 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: "estável" e "volátil". (Os nomes "estável" e "volátil" são um pouco contraintuitivos, então não pense muito sobre eles.)

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 os valores delas.

O contrato é:

• Os valores das chaves "estáveis" raramente mudam, se possível. Se o conteúdo de bazel-out/stable-status.txt mudar, o Bazel invalidará as ações que dependem dele. Em outras palavras, se o valor de uma chave estável mudar, o Bazel executará novamente as ações marcadas. Portanto, o status estável não pode conter itens como carimbos de data/hora, porque eles mudam o tempo todo, fazendo com que o Bazel execute novamente as ações marcadas 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.

• os valores das chaves "voláteis" podem mudar com frequência. Assim como os carimbos de data/hora, o Bazel espera que elas mudem o tempo todo e atualiza corretamente o arquivo bazel-out/volatile-status.txt. No entanto, para evitar sempre que ações sejam executadas novamente, Bazel finge que o arquivo volátil nunca muda (link em inglês). Em outras palavras, se o arquivo de status volátil for o único com conteúdo alterado, o Bazel não invalidará as ações que dependem dele. Se outras entradas das ações tiverem sido alteradas, o Bazel executará novamente essa ação e verá o status volátil atualizado, mas apenas a alteração do status volátil não invalidará a ação.

  O Bazel sempre gera as seguintes chaves voláteis:

  • BUILD_TIMESTAMP: tempo do build em segundos desde a era Unix (o valor de System.currentTimeMillis() dividido por mil)

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

Se o comando de status do espaço de trabalho falhar (saída de um valor diferente de zero) por qualquer motivo, o build falhará.

Exemplo de programa no Linux usando 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 desse programa com --workspace_status_command. O arquivo de status estável incluirá as linhas STABLE e o arquivo de status volátil incluirá o restante das linhas.

--[no]stamp

Esta opção, em conjunto com o atributo de regra stamp, controla a incorporação de informações de build em binários.

O carimbo pode ser ativado ou desativado explicitamente em cada regra usando o atributo stamp. Consulte a Build Encyclopedia para mais detalhes. Quando uma regra define stamp = -1 (o padrão para regras *_binary), essa opção determina se a estampa está ativada.

Ele nunca marca os binários criados para a configuração do host, independentemente dessa opção ou do atributo stamp. Para regras que definem stamp = 0 (o padrão para regras *_test), a estampa é desativada, independente de --[no]stamp. Especificar --stamp não forçará a recriação dos destinos se as dependências não tiverem sido modificadas.

Geralmente, a definição de --nostamp é ideal para melhorar o desempenho do build, já que 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 destino que configuram o funcionamento das versões e para controlar quais plataformas de execução e conjuntos de ferramentas estão disponíveis para as regras do Bazel.

Consulte as 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 para o comando atual.

--host_platform=label

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

--extra_execution_platforms=labels

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 no arquivo do ESPAÇO DE TRABALHO por register_execution_platforms().

--extra_toolchains=labels

As regras do conjunto de ferramentas a serem consideradas durante a resolução do conjunto de ferramentas. Os conjuntos de ferramentas podem ser especificados por destino exato ou como um padrão de destino. Esses conjuntos de ferramentas serão considerados antes daqueles declarados no arquivo WORKSPACE por register_toolchains().

--toolchain_resolution_debug=regex

Imprime informações de depuração enquanto encontra os conjuntos de ferramentas, se o tipo corresponde ao regex. Várias regex podem ser separadas por vírgulas. A regex pode ser negada usando um - no início. Isso pode ajudar os desenvolvedores de regras do Bazel ou do Starlark com falhas de depuração devido à ausência de conjuntos de ferramentas.

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 ver mais detalhes, consulte as Configurações do Starlark.

--symlink_prefix=string

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

Se os links simbólicos não puderem ser criados por qualquer motivo, um aviso será emitido, mas o build ainda será considerado um sucesso. Isso permite criar em um diretório somente leitura ou em que você não tenha permissão para gravar. Os caminhos impressos em mensagens informativas na conclusão de um build só vão usar a forma curta relativa a links simbólicos se eles apontarem para o local esperado. Em outras palavras, você pode confiar na precisão desses caminhos, mesmo que não dependa dos links simbólicos criados.

Alguns valores comuns dessa opção:

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

• Reduzir a desordem:--symlink_prefix=.bazel/ fará 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 o diretório de saída. Definir essa 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 interrompem arquivos de saída entre si ou para manter os arquivos de saída por perto para comparações.

--default_visibility=(private|public)

Sinalização temporária para testar as mudanças de visibilidade padrão do Bazel. Não se destina ao uso geral, mas documentada para fins de integridade.

--[no]use_action_cache

Esta opção é ativada por padrão. Se desativada, o Bazel não usa o cache de ações locais. Desativar o cache de ações locais economiza memória e espaço em disco para builds limpos, mas torna as versões incrementais mais lentas.

--starlark_cpu_profile=_file_

Essa flag, cujo valor é o nome de um arquivo, faz com que o Bazel reúna estatísticas sobre o uso da CPU por todas as linhas de execução do Starlark e grave o perfil, no formato pprof, no arquivo nomeado.

Use essa opção para ajudar a identificar funções do Starlark que tornam o carregamento e a análise lentos devido ao excesso de computação. 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 versões

Ele é usado por engenheiros de software durante o ciclo de desenvolvimento e por engenheiros de lançamento ao preparar binários para implantação na produção. Nesta seção, você encontra uma lista de dicas para engenheiros de versões que usam o Bazel.

Opções importantes

Ao usar o Bazel para builds de lançamento, os mesmos problemas surgem de outros scripts que executam uma compilação. Para saber mais, consulte Chamar o Bazel usando scripts. As opções a seguir são altamente recomendadas:

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

Essas 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 com um identificador distinto, como "64 bits" e "32 bits". Essa opção diferencia os links simbólicos bazel-bin (etc.).

Executar testes

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

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

Opções de bazel test

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

Se essa opção for definida como "auto" (padrão), o Bazel só vai executar um teste novamente se alguma das seguintes condições se aplicar:

• 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 vão ser executados incondicionalmente.

Se "sim", o comportamento de 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 de testes são sempre salvos na árvore de saída do Bazel, independentemente de essa opção estar ou não ativada. Portanto, não é necessário usar --cache_test_results nas execuções anteriores de bazel test para receber ocorrências em cache. A opção afeta apenas se o Bazel vai usar os resultados salvos anteriormente, não se 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 (ativadas) ou -t- (desativadas) convenientes para substituir o padrão em uma determinada execução.

--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 algum teste que não tenha sido criado e executado anteriormente ou com resultados desatualizados (por exemplo, porque o código-fonte ou as opções de build mudaram), o Bazel vai informar uma mensagem de erro ("resultado do teste não está atualizado"), registrar o status do teste 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 o comportamento [--check_up_to_date](#check-up-to-date).

Essa opção pode ser útil para verificações pré-envio.

--test_verbose_timeout_warnings

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

Por exemplo, um teste que normalmente é executado em um ou dois minutos não precisa ter um tempo limite de ETERNAL ou LONG, já que eles são muito generosos.

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

Observação :cada fragmento de teste recebe um tempo limite definido para todo o destino XX_test. O uso dessa opção não afeta o valor de tempo limite de um teste, apenas avisa se o Bazel acha que o tempo limite pode ser mais restrito.

--[no]test_keep_going

Por padrão, todos os testes são executados até o fim. No entanto, se essa sinalização estiver desativada, o build será cancelado em qualquer teste não aprovado. As etapas de build subsequentes e as invocações de teste não serão executadas, e as invocações em trânsito serã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 será tentado se ele falhar por qualquer motivo. Um teste que inicialmente falha, mas é concluído, é informado 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 considerados reprovados.

Por padrão, quando essa opção não é especificada ou é definida como padrão, apenas uma tentativa é permitida para testes regulares e três 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. Ele permite no máximo 10 tentativas de teste para evitar abuso do sistema.

--runs_per_test=[regex@]number

Essa opção especifica o número de vezes que cada teste deve ser executado. Todas as execuções de teste são tratadas como testes separados. A funcionalidade de fallback se aplica a cada uma delas de maneira independente.

O status de um destino com execuções com falha depende do valor da flag --runs_per_test_detects_flakes:

• Se ausente, qualquer execução com falha fará com que todo o teste falhe.
• Se presente e duas execuções do mesmo fragmento retornarem PASS e FAIL, o teste vai receber um status instável, a menos que outras execuções com falha façam ele falhar.

Se um único número for especificado, todos os testes serão executados várias vezes. Como alternativa, uma expressão regular pode ser especificada com a sintaxe regex@number. Isso restringe o efeito de --runs_per_test a destinos que correspondem ao regex (--runs_per_test=^//pizza:.*@4 executa todos os testes em //pizza/ quatro vezes). Essa forma de --runs_per_test pode ser especificada mais de uma vez.

--[no]runs_per_test_detects_flakes

Se essa opção for especificada (não é por padrão), o Bazel detectará fragmentos de teste instáveis usando --runs_per_test. Se uma ou mais execuções para uma única falha no fragmento e uma ou mais execuções para a mesma passagem de fragmento forem executadas, o destino será considerado instável com a sinalização. Se não for especificado, o destino vai informar um 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 com o nome do arquivo que contém a saída do teste se ele falhar. 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 cada teste. Os nomes dos arquivos de saída de teste são omitidos.
• O none não mostra o resumo do teste.

--test_output=output_style

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

• summary mostra um resumo da aprovação ou reprovação de cada teste. Também mostra o nome do arquivo de registro de saída dos testes com falha. O resumo será mostrado no final da criação. Durante a criação, veria apenas mensagens de progresso simples quando os testes eram iniciados, aprovados ou reprovados. Esse é o comportamento padrão.
• O errors envia a saída stdout/stderr combinada de testes com falha apenas para o stdout imediatamente após a conclusão do teste, garantindo que a saída do teste de testes simultâneos não seja intercalada uma com a outra. Mostra um resumo no build conforme o resultado do resumo acima.
• all é semelhante a errors, mas mostra a saída para todos os testes, incluindo aqueles que foram aprovados.
• 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, fazendo com que os tempos de teste e outras informações (como tentativas de teste) sejam mostradas no resumo do teste. Se --noverbose_test_summary for especificado, o resumo do teste incluirá apenas o nome, o status e o indicador de teste em cache e será formatado para permanecer dentro de 80 caracteres, quando possível.

--test_tmpdir=path

Especifica o diretório temporário para testes executados localmente. Cada teste será executado em um subdiretório separado dentro desse diretório. O diretório será limpo no início de cada comando bazel test. Por padrão, o Bazel coloca 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 de testes. Eles são sempre armazenados no diretório bazel-out.

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

Modifica o valor de 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á usado para todas as categorias de tempo limite do teste.

Como alternativa, podem ser fornecidos quatro valores separados por vírgula, especificando tempos limite individuais para testes curtos, moderados, longos e eternos (nessa ordem). Seja qual for o formato, zero ou um valor negativo para qualquer um dos tamanhos de teste será substituído pelo tempo limite padrão para as categorias de tempo limite fornecidas, conforme definido na página Como gravar testes. Por padrão, o Bazel usa esses tempos limite para todos os testes, inferindo o tempo limite do tamanho do teste, se o tamanho está definido ou definido de forma implícita ou explícita.

Os testes que declaram explicitamente a categoria de tempo limite como diferente do tamanho receberão o mesmo valor como se esse tempo limite tivesse sido definido implicitamente pela tag de tamanho. Assim, um teste de tamanho "pequeno" que declara um tempo limite "longo" terá o mesmo tempo limite efetivo que um teste "grande" sem um tempo limite explícito.

--test_arg=arg

Transmite opções/sinalizações/argumentos de linha de comando para cada processo de teste. Essa opção pode ser usada várias vezes para transmitir vários argumentos. Por exemplo, --test_arg=--logtostderr --test_arg=--v=3.

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

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

O ambiente pode ser acessado de 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 inserirá na frente do comando de teste antes de executá-lo. O command-prefix é dividido em palavras usando regras de tokenização do shell Bourne e, em seguida, a lista de palavras é anexada ao comando que será executado.

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

Aplicam-se algumas ressalvas:

• O PATH usado para executar testes pode ser diferente do PATH no seu ambiente. Portanto, pode ser necessário usar um caminho absoluto para o comando --run_under (a primeira palavra em command-prefix).
• O stdin não está conectado, então o --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 os testes por tamanho, tempo limite, tag ou idioma. Um filtro de nome geral de conveniência pode encaminhar argumentos de filtro específicos para o executor de teste.

Outras opções para bazel test

A sintaxe e as opções restantes são exatamente como bazel build.

Como executar executáveis

O comando bazel run é semelhante ao bazel build, mas é usado para criar e executar um único destino. Esta é uma sessão típica:

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

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

Observaçã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. (O programa em execução simplesmente diz "hello" e mostra os argumentos.)

O bazel run é semelhante, mas não idêntico, à invocação direta do binário criado pelo Bazel. 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á a árvore de runfiles do binário.

Quando o binário for um teste, o diretório de trabalho atual será a raiz executiva e uma tentativa de boa-fé é feita para replicar os testes de ambiente em que costuma ser executado. No entanto, a emulação não é perfeita e os 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.

Eles podem ser usados, 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), mas se aplica ao comando executado por bazel run em vez dos testes executados por bazel test e não podem ser executados em rótulos.

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 próprio Bazel e do binário sob invocação. Para tornar os registros menos barulhentos, você pode suprimir as saídas do próprio Bazel com as sinalizações --ui_event_filters e --noshow_progress.

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

Execução de testes

O bazel run também pode executar binários de teste, que têm o efeito de executar o teste em uma aproximação do ambiente descrito em Como criar 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 parecido com o do Make. Ela exclui os diretórios de saída de todas as configurações de compilação realizadas por esta instância do Bazel ou toda a árvore de trabalho criada por essa instância do Bazel e redefine os caches internos. Se executado sem nenhuma opção de linha de comando, o diretório de saída de todas as configurações será limpo.

Lembre-se de que cada instância do Bazel está associada a um único espaço de trabalho. Portanto, o comando clean vai excluir todas as saídas de todas as versões que você fez com a instância do Bazel no 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 remove toda a árvore base de saída que, além da saída do build, contém todos os arquivos temporários criados pelo Bazel. Isso também para o servidor do Bazel após a limpeza, que é equivalente ao comando shutdown. Por exemplo, para limpar todos os rastros de disco e memória de uma instância do Bazel, especifique:

  % bazel clean --expunge

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

Observação: isso pode introduzir 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 perfeitas. Portanto, clean pode ser usado para recuperar um estado consistente quando surgirem problemas.

No design do Bazel, esses problemas podem ser corrigidos e eles têm alta prioridade. Se você encontrar um build incremental incorreto, envie um relatório do bug e informe os bugs nas ferramentas em vez de usar clean.

Como consultar o gráfico de dependência

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: query e cquery. A principal diferença entre os dois comandos é que a consulta é executada após a fase de carregamento e a cquery é executada após a fase de análise. Essas ferramentas são uma ajuda inestimável para muitas tarefas de engenharia de software.

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

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

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 ferramenta de consulta continue a progredir após 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, ativada 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 as dependências implícitas sejam incluídas no gráfico de dependências em que a consulta opera. Uma dependência implícita é aquela que não é especificada explicitamente no arquivo BUILD, mas adicionada pelo bazel.

Exemplo: "Mostre 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

Cuidado :o comando aquery ainda é experimental, e a API dele vai mudar.

O comando aquery permite que você consulte ações no gráfico do build. Ele opera no gráfico de destino configurado pós-análise e expõe informações sobre ações, artefatos e relacionamentos.

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 o formato legível por máquina. O comando aquery é executado em um build normal do Bazel e herda o conjunto de opções disponíveis durante uma compilação.

Ele oferece suporte ao mesmo conjunto de funções que também está disponível para a query tradicional, mas siblings, buildfiles e tests.

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

Comandos e opções diversos

help

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

--[no]long (-l)

Por padrão, bazel help [topic] mostra apenas um 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 serão mostrados.

shutdown

Os processos do servidor do Bazel podem ser interrompidos usando o comando shutdown. Esse comando faz com que o servidor do Bazel seja encerrado assim que ficar inativo (por exemplo, após a conclusão de qualquer build ou de outros comandos em andamento). Para ver mais detalhes, consulte Implementação de cliente/servidor.

Os servidores Bazel são interrompidos automaticamente após um tempo limite de inatividade. Portanto, esse comando raramente é necessário. No entanto, ele pode ser útil em scripts quando se sabe que nenhuma outra versão ocorrerá em um determinado espaço de trabalho.

shutdown aceita uma opção, --iff_heap_size_greater_than _n_, que requer um argumento de número inteiro (em MB). Se especificado, isso torna o encerramento condicional à quantidade de memória já consumida. Isso é útil para scripts que iniciam muitas versões, já que qualquer vazamento de memória no servidor do Bazel pode fazer com que ele falhe intencionalmente às vezes. A execução de uma reinicialização condicional impede essa condição.

info

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

O comando info também permite um único argumento (opcional), que é o nome de uma das chaves na lista abaixo. Nesse caso, bazel info key exibirá apenas o valor dessa chave. Isso é especialmente conveniente ao criar scripts do Bazel, porque evita a necessidade de canalizar o resultado por sed -ne /key:/s/key://p:

Dados independentes de configuração

• release: o rótulo de lançamento dessa 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 do espaço de trabalho de base.

• install_base: o caminho absoluto para o diretório de instalação usado por esta instância do Bazel para o usuário atual. O Bazel instala os executáveis internamente necessários abaixo desse diretório.

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

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

• output_path: o caminho absoluto para o diretório de saída abaixo da raiz de execução usado para todos os arquivos realmente gerados como resultado de comandos de build. Se o diretório do espaço de trabalho for gravável, um link simbólico chamado bazel-out será colocado nele, apontando para esse diretório.

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

• server_log: o caminho absoluto para o arquivo de registros 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 registros do comando. Contém os fluxos stdout e stderr intercalados do comando mais recente do Bazel. Observe que executar bazel info substituirá o conteúdo desse arquivo, porque ele se tornará o comando mais recente do Bazel. No entanto, o local do arquivo de registros de comando não será alterado, a menos que você mude a configuração das opções --output_base ou --output_user_root.

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

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

• package_path: uma lista de caminhos separados por dois-pontos que seriam pesquisados por pacotes pelo Bazel. Tem o mesmo formato que o 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 determinam o local do diretório de saída de um build, a escolha do compilador etc.

• bazel-bin, bazel-testlogs, bazel-genfiles: informa o caminho absoluto para os diretórios bazel-* em que os programas gerados pelo build estão localizados. Geralmente, ele é igual, mas não sempre, aos links simbólicos bazel-* criados no diretório do espaço de trabalho base após um build bem-sucedido. No entanto, se o diretório do espaço de trabalho for somente leitura, nenhum link simbólico bazel-* poderá ser criado. Os scripts que usam o valor informado por bazel info, em vez de presumir a existência do link simbólico, serão mais robustos.
• O ambiente"Make" completo. Se a sinalização --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 a sintaxe $(CC) ou varref("CC") nos arquivos BUILD.

Exemplo: o compilador C++ da configuração atual. Essa é a variável $(CC) no ambiente "Make", portanto, a sinalização --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 a configuração atual. Isso é garantido mesmo nos casos em que o link simbólico bazel-bin não pode ser criado por algum motivo (como se você estiver criando a partir 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" imprime detalhes da versão sobre o binário criado do Bazel, incluindo a lista de mudanças em que ele foi criado e a data. Eles são particularmente úteis para determinar se você tem o Bazel mais recente ou se está relatando bugs. Alguns dos valores interessantes são:

• changelist: a lista de mudanças em que esta versão do Bazel foi lançada.
• label: o rótulo de lançamento dessa instância do Bazel ou "versão de desenvolvimento", se não for um binário lançado. Muito útil ao informar bugs.

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

mobile-install

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

Consulte bazel mobile-install para saber mais.

Observação: esse comando não instala o mesmo que bazel build produz. O Bazel ajusta o app para que ele possa ser criado, instalado e reinstalado rapidamente. No entanto, isso precisa ser transparente para o app.

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

--incremental

Se definido, o Bazel tentará instalar o app de forma incremental, ou seja, apenas as partes que foram alteradas desde o último build. Isso não pode atualizar recursos referenciados em AndroidManifest.xml, código nativo ou recursos Java (como aqueles referenciados por Class.getResource()). Se isso mudar, essa opção precisa ser omitida. Ao contrário do 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ê estiver usando um dispositivo com o Android Marshmallow ou mais recente, considere a flag --split_apks.

--split_apks

Define se APKs divididos para instalar e atualizar o aplicativo no dispositivo serão usados. Só funciona em dispositivos com o Android Marshmallow ou mais recente. 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 até 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 de 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 estiver 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 geralmente são usados para especificar em qual dispositivo instalar. Por exemplo, para selecionar o dispositivo ou emulador Android a 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 a geração de registros de depuração seja impressa no console.

dump

O comando dump imprime em stdout um despejo do estado interno do servidor do Bazel. Esse comando é destinado principalmente a desenvolvedores do Bazel. Portanto, a saída dele não é especificada e está sujeita a mudanças.

Por padrão, o comando vai apenas mostrar uma mensagem de ajuda descrevendo 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 de ação.
• --packages descarta o conteúdo do cache do pacote.
• --skyframe despeja o estado do gráfico de dependências interno do Bazel.
• --rules descarta o resumo da regra para cada regra e classe de aspecto, incluindo contagens e contagens de ações. Isso inclui tanto as regras nativas quanto as de Starlark. Se o rastreamento de memória estiver ativado, o consumo de memória das regras também será mostrado.
• --skylark_memory despeja um arquivo .gz compatível com o pprof para o caminho especificado. Ative o rastreamento de memória para que isso funcione.

Monitoramento de memória

Alguns comandos dump exigem rastreamento de memória. Para ativar essa opção, você precisa transmitir as 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. Portanto, ajuste o $BAZEL para onde você mantém o repositório do Bazel.

Não se esqueça de continuar transmitindo essas opções ao Bazel para cada comando. Caso contrário, o servidor será reiniciado.

Exemplos

    % 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 dados coletados anteriormente durante a criação usando a opção --profile. Ele oferece várias opções para realizar análises da execução da versão ou exportar dados no formato especificado.

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

• --dump mostra todos os dados coletados em um formato legível. No entanto, ele ainda não oferece suporte a outros formatos.

Para detalhes sobre o formato e ajuda de uso, consulte Como solucionar problemas de desempenho por criação de perfil.

canonicalize-flags

O comando canonicalize-flags, que usa 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 canônicas na mesma nova lista.

A opção --for_command pode ser usada para selecionar comandos diferentes. No momento, apenas build e test são compatíveis. As opções não compatíveis com o comando específico causam um erro.

Observação: não é possível reordenar um pequeno número de opções, porque o Bazel não pode garantir que o efeito seja idêntico. Além disso, esse 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 do Bazel e se aplicam a todos os comandos subsequentes processados por esse servidor. Se já houver um servidor do Bazel em execução e as opções de inicialização não corresponderem, ele será reiniciado.

Todas as opções descritas nesta seção precisam ser especificadas usando a sintaxe --key=value ou --key value. Além disso, essas opções precisam aparecer antes do nome do comando do Bazel. 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 manipulará o comando.

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

Observação :o cliente usa a base de saída para encontrar a instância do servidor do Bazel. Portanto, se você especificar uma base de saída diferente em um comando do Bazel, um servidor diferente será encontrado (ou iniciado) para processar a solicitação. É possível executar dois builds simultâneos no mesmo diretório do 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 diferente do servidor do Bazel por causa das diferentes bases de saída. Por outro lado, se a base de saída padrão fosse usada em ambos os comandos, as solicitações seriam enviadas para o mesmo servidor, que as processaria sequencialmente: criando //foo primeiro, seguido por um build incremental de //bar.

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

--output_user_root=dir

Aponta para o diretório raiz em que as bases de saída e instalação são criadas. O diretório não pode existir ou ser de propriedade do usuário que fez a chamada. Antes, isso podia apontar para um diretório compartilhado entre vários usuários, mas não é mais permitido. Isso poderá ser permitido assim que o problema 11100 for resolvido.

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

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

Você pode usar a opção --output_user_root para escolher um local base alternativo para todas as saídas do Bazel (base instalada e base de saída) se houver um local melhor no layout do 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, já que a maior latência de acesso causa builds visivelmente mais lentos.

--server_javabase=dir

Especifica a máquina virtual Java na qual o próprio Bazel é executado. O valor precisa ser um caminho para o diretório que contém um JDK ou JRE. 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 sinalização não afeta as JVMs usadas por 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 anteriormente de --host_javabase (às vezes chamada de --host_javabase do "lado esquerdo"), mas foi renomeada para evitar confusão com a sinalização 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 na qual o próprio Bazel é 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. Raramente é necessário definir essa flag. Também é possível transmitir uma lista de strings separadas por espaços, cada uma sendo interpretada como um argumento JVM separado, mas esse recurso será descontinuado em breve.

Isso não afeta nenhuma JVMs usadas por subprocessos do Bazel: aplicativos, testes, ferramentas e assim por diante. Para transmitir opções de JVM para programas Java executáveis, sejam executados por bazel run ou na linha de comando, use o argumento --jvm_flags, que todos os programas java_binary e java_test oferecem suporte. 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 de chamar o método principal do próprio Bazel (link em inglês). Isso é destinado principalmente para 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 procure automaticamente um JDK instalado na inicialização e use 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 executar o Bazel.

--batch

O modo de lote faz com que o Bazel não use o modo cliente/servidor padrão, mas executa um processo Bazel Java para um único comando, que foi usado para uma semântica mais previsível em relação ao processamento de indicadores, ao controle de jobs e à herança da variável de ambiente, além de ser necessário para executar o bazel em uma cadeia chroot.

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

O Bazel vai ser executado mais lentamente no modo em lote ou com as alternativas descritas acima. Isso ocorre porque, entre outras coisas, o cache do arquivo de build reside na memória. Portanto, ele não é preservado entre as invocações de lote sequenciais. Portanto, o uso do modo em lote geralmente faz mais sentido nos casos em que o desempenho é menos importante, como nas versões contínuas.

Aviso: --batch é suficientemente mais lento do que o modo cliente/servidor padrão. Além disso, ele pode não oferecer suporte a todos os recursos e otimizações viáveis por um servidor persistente do Bazel. Se você estiver usando --batch para fins de isolamento de build, use a opção de comando --nokeep_state_after_build, que garante que nenhum estado incremental na memória seja mantido entre os builds. Para reiniciar o servidor do Bazel e a JVM após um build, faça isso explicitamente usando o comando "shutdown".

--max_idle_secs=n

Essa opção especifica quanto tempo, em segundos, o processo do servidor do Bazel deve aguardar após a última solicitação de cliente até sair. O valor padrão é 10800 (3 horas). --max_idle_secs=0 fará com que o processo do servidor Bazel persista indefinidamente.

Observação: essa sinalização só será lida se o Bazel precisar iniciar um novo servidor. Mudar 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 não saiam dos processos do servidor do Bazel na máquina de um usuário quando não seriam executados de outra forma. Por exemplo, um script de pré-envio pode invocar bazel query para garantir que a mudança pendente de um usuário não introduza dependências indesejadas. No entanto, se o usuário não tiver feito um build recente nesse espaço de trabalho, será indesejável que o script de pré-envio inicie um servidor do Bazel apenas para que ele permaneça inativo pelo resto do dia. Ao especificar um pequeno valor de --max_idle_secs na solicitação de consulta, o script pode garantir que if isso causou a inicialização de um novo servidor, esse servidor será encerrado imediatamente. No entanto, se já houver um servidor em execução, esse servidor continuará sendo executado até ficar inativo pelo tempo normal. Obviamente, o timer de inatividade do servidor existente será redefinido.

--[no]shutdown_on_low_sys_mem

Se ativado e --max_idle_secs for definido com uma duração positiva, depois que o servidor de build ficar inativo por um tempo, desligue o servidor 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 inicia o monitoramento da memória disponível do sistema após o servidor ficar inativo por algum tempo. Se a memória do sistema disponível ficar criticamente baixa, o servidor será encerrado.

--[no]block_for_lock

Se ativado, o Bazel aguarda a conclusão de outros comandos que contêm o bloqueio do servidor antes de progredir. Se desativado, o Bazel sairá por engano se não conseguir imediatamente o bloqueio e prosseguir.

Os desenvolvedores podem usar isso em 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 é prioridade mais alta e 7 é a mais baixa. O programador antecipado só pode respeitar a prioridade 4. Valores negativos são ignorados.

--batch_cpu_scheduling

Use a programação de CPU batch para o Bazel. Essa política é útil para cargas de trabalho que não são interativas, mas que não querem diminuir o valor delas. Consulte "man 2 sged_setscheduler". Essa política pode melhorar a interatividade do sistema em detrimento da capacidade do Bazel.

Opções diversas

--[no]announce_rc

Controla se o Bazel anuncia opções de comando lidas do arquivo bazelrc ao inicializar. As opções de inicialização são anunciadas incondicionalmente.

--color (yes|no|auto)

Essa opção determina se o Bazel usará cores para destacar a saída na tela.

Se essa opção for definida como yes, a saída de cor será ativada. Se essa opção for definida como auto, o Bazel usará a saída de cor somente se ela estiver sendo enviada para um terminal e a variável de ambiente TERM estiver definida como um valor diferente de dumb, emacs ou xterm-mono. Se essa opção for definida como no, a saída de cor será desativada, mesmo que a saída seja para um terminal ou da configuração da variável de ambiente TERM.

--config=name

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

--curses (yes|no|auto)

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

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

--[no]show_timestamps

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