Esta página aborda as opções disponíveis com vários comandos do Bazel,
como bazel build
, bazel run
e bazel test
. Esta página é um complemento
à lista de comandos do Bazel em Build with Bazel.
Sintaxe de destino
Alguns comandos, como build
ou test
, podem operar em uma lista de destinos. Eles
usam uma sintaxe mais flexível que rótulos, o que é documentado em
Especificar destinos a serem compilados.
Opções
As seções a seguir descrevem as opções disponíveis durante um
ser construído. Quando --long
é usado em um comando de ajuda, o
as mensagens de ajuda fornecem informações resumidas sobre o significado, tipo e
o valor padrão de cada opção.
A maioria das opções só pode ser especificada uma vez. Quando especificado várias vezes, o a última instância vença. As opções que podem ser especificadas várias vezes são identificados na ajuda on-line com o texto "pode ser usado várias vezes".
Localização do pacote
--package_path
Esta opção especifica o conjunto de diretórios que são pesquisados encontrar o arquivo BUILD de um determinado pacote.
O Bazel encontra os pacotes pesquisando o caminho deles. Isso é um sinal de dois-pontos lista ordenada separada de diretórios do Bazel, sendo cada um a raiz de um árvore de origem parcial.
Para especificar um caminho de pacote personalizado usando a opção --package_path
:
% bazel build --package_path %workspace%:/some/other/root
Os elementos do caminho do pacote podem ser especificados em três formatos:
- Se o primeiro caractere for
/
, o caminho será absoluto. - Se o caminho começar com
%workspace%
, ele será considerado relativo para o diretório do Bazel mais próximo. Por exemplo, se o diretório de trabalho for/home/bob/clients/bob_client/bazel/foo
, o valor A string%workspace%
no caminho do pacote é expandida. para/home/bob/clients/bob_client/bazel
. - Qualquer outra coisa é levada em relação ao diretório de trabalho.
Geralmente, não é isso que você quer fazer,
e podem 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 package-path
.
: e, em seguida, "cd" no diretório/home/bob/clients/bob_client/bazel/foo
, pacotes serão resolvidas a partir da/home/bob/clients/bob_client/bazel/foo
.
Se você usar um caminho de pacote não padrão, especifique-o no Arquivo de configuração do Bazel por conveniência.
O Bazel não exige que nenhum pacote esteja no diretório atual, para que você possa criar um build usando um bazel vazio. Workspace se todos os pacotes necessários puderem ser encontrados em outro lugar no caminho do pacote.
Exemplo: como criar a partir de um cliente vazio
% mkdir -p foo/bazel % cd foo/bazel % touch WORKSPACE % bazel build --package_path /some/other/path //foo
--deleted_packages
Essa opção especifica uma lista separada por vírgulas de pacotes que o Bazel deve considerar excluída e não tentar carregar de nenhum diretório no caminho do pacote. Isso pode ser usado para simular a exclusão de pacotes sem e realmente excluí-las. Essa opção pode ser passada várias vezes. Nesse caso, as listas individuais são concatenadas.
Verificação de erros
Essas opções controlam a verificação de erros e/ou os avisos do Bazel.
--[no]check_visibility
Se essa opção for definida como falsa, as verificações de visibilidade serão rebaixadas a avisos. O valor padrão dessa opção é verdadeiro, de modo que, por padrão, a visibilidade a verificação for concluída.
--output_filter=regex
A opção --output_filter
vai mostrar apenas o build e a compilação.
avisos para destinos que correspondem à expressão regular. Se um destino
corresponder à expressão regular em questão e sua execução for bem-sucedida, seu padrão
a saída e o erro padrão serão descartados.
Confira alguns valores típicos para essa opção:
`--output_filter='^//(first/project|second/project):'` | Mostra a saída dos pacotes especificados. |
`--output_filter='^//((?!(first/bad_project|second/bad_project):).)*$'` | Não mostra a saída dos pacotes especificados. |
`--output_filter=` | Mostrar tudo. |
`--output_filter=DONT_MATCH_ANYTHING` | Não mostrar nada. |
Sinalizações de ferramentas
Elas controlam quais opções o Bazel transmite para outras ferramentas.
--copt=cc-option
Essa opção usa um argumento que será passado ao 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 o código do assembler. Ele não será transmitido durante a vinculação.
Essa opção pode ser usada várias vezes. Exemplo:
% bazel build --copt="-g0" --copt="-fpic" //foo
vai compilar a biblioteca foo
sem depurar tabelas, gerando
código independente de posição.
--host_copt=cc-option
Essa opção aceita um argumento que deve ser passado ao compilador para arquivos de origem
que são compiladas na configuração "exec". Isso é análogo ao
a opção --copt
, mas se aplica somente aos
"exec".
--host_conlyopt=cc-option
Essa opção aceita um argumento que deve ser passado ao compilador para arquivos de origem C
que são compiladas na configuração "exec". Isso é análogo ao
a opção --conlyopt
, mas se aplica apenas
à configuração "exec".
--host_cxxopt=cc-option
Essa opção usa um argumento que deve ser passado ao compilador para arquivos de origem C++
que são compiladas na configuração "exec". Isso é análogo ao
a opção --cxxopt
, mas se aplica somente aos
"exec".
--host_linkopt=linker-option
Essa opção usa um argumento que deve ser passado ao vinculador para arquivos de origem
que são compiladas na configuração "exec". Isso é análogo ao
a opção --linkopt
, mas se aplica apenas a
a configuração "exec".
--conlyopt=cc-option
Essa opção aceita um argumento que deve ser passado ao compilador na compilação de arquivos de origem em C.
Isso é semelhante ao --copt
, mas só se aplica à compilação C.
e não à compilação
ou vinculação em C++. Então é possível passar opções específicas para C
(como -Wno-pointer-sign
) usando --conlyopt
.
--cxxopt=cc-option
Essa opção usa um argumento que deve ser passado ao compilador quando compilar arquivos de origem em C++.
Isso é semelhante a --copt
, mas só se aplica à compilação C++.
e não à compilação
ou vinculação em C. É possível transmitir opções específicas de C++
(como -fpermissive
ou -fno-implicit-templates
) usando --cxxopt
.
Exemplo:
% bazel build --cxxopt="-fpermissive" --cxxopt="-Wno-error" //foo/cruddy_code
--linkopt=linker-option
Essa opção usa um argumento que precisa ser passado ao compilador durante a vinculação.
Isso é semelhante ao --copt
, mas só se aplica a vinculações,
e não à compilação. Portanto, é possível passar opções de compilador que só fazem sentido
no momento da vinculação (como -lssp
ou -Wl,--wrap,abort
)
usando --linkopt
. Exemplo:
% bazel build --copt="-fmudflap" --linkopt="-lmudflap" //foo/buggy_code
As regras de criação também podem especificar opções de vinculação nos atributos. A configuração sempre terão precedência. Consulte também cc_library.linkopts
--strip (always|never|sometimes)
Essa opção determina se o Bazel vai remover as informações de depuração
todos os binários e bibliotecas compartilhadas invocando o vinculador com a opção -Wl,--strip-debug
.
--strip=always
significa sempre remover as informações de depuração.
--strip=never
significa que nunca remova as informações de depuração.
O valor padrão de --strip=sometimes
significa remover se a --compilation_mode
é fastbuild
.
% bazel build --strip=always //foo:bar
vai compilar o destino e remover as informações de depuração de todos os binários.
A opção --strip
do Bazel corresponde à opção --strip-debug
do ld:
somente as informações de depuração. Se, por algum motivo, você quiser remover todos os símbolos,
não apenas símbolos debug, seria necessário usar a opção --strip-all
de ld,
Basta transmitir --linkopt=-Wl,--strip-all
para o Bazel. Além disso, tenha
saber que a definição da flag --strip
do Bazel vai substituir
--linkopt=-Wl,--strip-all
. Portanto, defina apenas um ou outro.
Se estiver criando apenas um binário e quiser que todos os símbolos sejam removidos, também é possível
transmitir --stripopt=--strip-all
e criar explicitamente o
Versão //foo:bar.stripped
do destino. Conforme descrito na seção sobre
--stripopt
, aplica uma ação de remoção após o binário final ser
vinculado em vez de incluir a remoção em todas as ações de link da versão.
--stripopt=strip-option
Essa é uma opção extra para transmitir ao comando strip
ao gerar
um binário *.stripped
. O padrão
é -S -p
. Essa opção pode ser usada várias vezes.
--fdo_instrument=profile-output-dir
A opção --fdo_instrument
permite a geração de
Saída do perfil de FDO (otimização direcionada por feedback) quando o
binário C/C++ criado. Para o GCC, o argumento fornecido é usado como
Prefixo do diretório para uma árvore de diretório de arquivos por objeto de arquivos .gcda
que contêm informações de perfil para cada arquivo .o.
Assim que a árvore de dados de perfil tiver sido gerada, a árvore de perfil
deve ser compactado e fornecido ao
--fdo_optimize=profile-zip
Opção do Bazel para ativar a compilação otimizada para FDO.
Para o compilador do LLVM, o argumento também é o diretório em que o perfil bruto do LLVM
arquivo(s) de dados for despejado. Por exemplo: --fdo_instrument=/path/to/rawprof/dir/
.
As opções --fdo_instrument
e --fdo_optimize
não podem ser usadas ao mesmo tempo.
--fdo_optimize=profile-zip
A opção --fdo_optimize
permite o uso do
informações de perfil de arquivo por objeto para realizar o FDO (feedback
otimização dirigida) na compilação. Para o GCC, o argumento
fornecido é o arquivo zip que contém a árvore de arquivos gerada anteriormente
de arquivos .gcda com informações de perfil para cada arquivo .o.
Como alternativa, o argumento fornecido pode apontar para um perfil automático identificados pela extensão .afdo.
Para o compilador do LLVM, o argumento fornecido precisa apontar para o LLVM indexado de perfil preparado pela ferramenta llvm-profdata e precisa ter um arquivo .profdata .
As opções --fdo_instrument
e --fdo_optimize
não podem ser usadas ao mesmo tempo.
--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 por
como 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. Por exemplo:
% bazel run --java_runtime_version=remotejdk_11 java/com/example/common/foo:java_application
faz o download do JDK 11 de um repositório remoto e executa o aplicativo Java usando esse repositório.
O valor padrão é local_jdk
.
Os valores possíveis são: local_jdk
, local_jdk_version
,
remotejdk_11
e remotejdk_17
.
Estenda os valores registrando uma JVM personalizada usando
Regras de repositório local_java_repository
ou remote_java_repository
.
--tool_java_runtime_version=version
A versão da JVM usada para executar ferramentas necessárias durante um build.
O valor padrão é remotejdk_11
.
--jvmopt=jvm-option
Essa opção permite que os argumentos sejam passados para a VM do Java. 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 para a VM de 256 MB.
--javacopt=javac-option
Essa opção permite que os argumentos sejam passados para javac. Pode ser usado com um argumento grande ou várias vezes com argumentos individuais. Exemplo:
% bazel build --javacopt="-g:source,lines" //myprojects:prog
vai recriar um java_binary com as informações de depuração padrão javac (em vez do padrão do Bazel).
A opção é transmitida para javac depois das opções padrão integradas do Bazel para javac e antes das opções por regra. A última especificação qualquer opção para javac vencer. As opções padrão para javac são:
-source 8 -target 8 -encoding UTF-8
--strict_java_deps (default|strict|off|warn|error)
Essa opção controla se javac verifica se há dependências diretas ausentes. Os destinos Java precisam declarar explicitamente todos os destinos usados diretamente como dependências. Essa flag instrui o javac a determinar os jars realmente usados. para a verificação de tipo de cada arquivo Java, e “warning/error” se eles não forem a saída de uma dependência direta do destino atual.
off
significa que a verificação está desativada.warn
significa que javac gerará avisos Java padrão de digite[strict]
para cada dependência direta ausente.default
,strict
eerror
todos significa que javac gerará erros em vez de avisos, fazendo com que o código falha na criação se alguma dependência direta ausente for encontrada. Esse também é o comportamento padrão quando a sinalização não é especificada.
Semântica de build
Essas opções afetam os comandos de compilação e/ou o conteúdo do arquivo de saída.
--compilation_mode (fastbuild|opt|dbg)
(-c)
A opção --compilation_mode
(geralmente abreviada para -c
,
especialmente -c opt
) usa um argumento de fastbuild
, dbg
ou opt
e afeta vários modelos de geração de código C/C++
opções, como o nível de otimização e a abrangência
tabelas de depuração. O Bazel usa um diretório de saída diferente para cada
um modo de compilação diferente, para que você possa alternar entre os modos sem
precisar recriar todas as vezes.
fastbuild
significa criar o mais rápido possível: gerar informações mínimas de depuração (-gmlt -Wl,-S
) e não otimizar. Esse é o padrão. Observação:-DNDEBUG
não será definido.dbg
significa build com depuração ativada (-g
), para que você possa usar o gdb (ou outro depurador).opt
significa criar com otimização ativada e comassert()
chamadas desativadas (-O2 -DNDEBUG
). As informações de depuração não serão geradas no modoopt
. a menos que você também passe--copt -g
.
--cpu=cpu
Essa opção especifica a arquitetura de CPU de destino a ser usada a compilação de binários durante o build.
--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 pelo nome. Nesse caso, o valor será retirado do
ambiente de invocação, ou pelo par name=value
, que define o valor independente do
ambiente de invocação.
Essa sinalização --action_env
pode ser especificada várias vezes. Se um valor for atribuído ao mesmo
em várias flags --action_env
, a última atribuição vence.
--experimental_action_listener=label
A opção experimental_action_listener
instrui o Bazel a usar
detalhes da regra action_listener
especificada por label para
inserir extra_actions
no gráfico de build.
--[no]experimental_extra_action_top_level_only
Se esta opção for definida como verdadeira, as ações extras especificadas pelo
Comando --experimental_action_listener
a opção de linha só será programada para segmentações de nível superior.
--experimental_extra_action_filter=regex
A opção experimental_extra_action_filter
instrui o Bazel a
filtrar o conjunto de segmentações para programar extra_actions
.
Essa sinalização só é aplicável em combinação com o
flag --experimental_action_listener
.
Por padrão, todos os extra_actions
no fechamento transitivo da
os destinos solicitados para criação são programados para execução.
--experimental_extra_action_filter
vai restringir a programação a
extra_actions
dos quais o rótulo do proprietário corresponda ao especificado
expressão regular.
O exemplo a seguir limita a programação de extra_actions
para aplicar somente a ações que tenham '/bar/' no marcador do proprietário:
% 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 deve ser usados para criar ferramentas host.
--android_platforms=platform[,platform]*
As plataformas para criar a deps
transitiva de
Regras android_binary
(especificamente para dependências nativas, como C++). Para
exemplo, se um cc_library
aparece na deps
transitiva de uma
android_binary
, que é criada uma vez para cada plataforma especificada com
--android_platforms
para a regra android_binary
e incluída no
saída.
Não há valor padrão para esta flag: é preciso ter uma plataforma Android personalizada definidos e usados.
Um arquivo .so
é criado e empacotado no APK para cada plataforma especificada.
com --android_platforms
. O nome do arquivo .so
tem como prefixo o nome do
Regra android_binary
com "lib". Por exemplo, se o nome
android_binary
é "foo", então o arquivo é libfoo.so
.
--per_file_copt=[+-]regex[,[+-]regex]...@option[,option]...
Quando presente, qualquer arquivo C++ com um rótulo ou caminho de execução correspondente a um do regex de inclusão
expressões que não correspondam a nenhuma das expressões de exclusão serão construídas
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++. Também inclui todos os prefixos dependentes da plataforma.
Para fazer a correspondência dos arquivos gerados (como saídas de genrule)
O Bazel só pode usar o caminho de execução. Nesse caso, o regexp não deve começar com "//"
já que não corresponde
a nenhum caminho de execução. Os nomes dos pacotes podem ser usados da seguinte forma:
--per_file_copt=base/.*\.pb\.cc@-g0
: Isso corresponderá a todos
.pb.cc
em um diretório chamado base
.
Essa opção pode ser usada várias vezes.
A opção é aplicada independentemente do modo de compilação usado. Por exemplo, é possível
para compilar com --compilation_mode=opt
e compilar seletivamente
arquivos com otimização mais forte ativada ou com otimização desativada.
Advertência: se alguns arquivos são compilados seletivamente com símbolos de depuração, os símbolos
podem ser removidos durante a vinculação. Isso pode ser evitado definindo
--strip=never
:
Sintaxe: [+-]regex[,[+-]regex]...@option[,option]...
, em que
regex
representa uma expressão regular que pode ser prefixada com
uma +
para identificar padrões de inclusão e com -
para identificar
excluir padrões. option
significa uma opção arbitrária transmitida
ao compilador C++. Se uma opção tiver um ,
, ela precisará ser citada dessa forma.
\,
. As opções também podem conter @
, já que apenas o primeiro
@
é usada para separar expressões regulares das opções.
Exemplo:
--per_file_copt=//foo:.*\.cc,-//foo:file\.cc@-O0,-fprofile-arcs
adiciona as opções -O0
e -fprofile-arcs
ao comando
linha 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 eoff
para cygwin.default
: permite que o Bazel escolha se quer vincular dinamicamente. Consulte linkstatic para saber mais informações imprecisas ou inadequadas.fully
: vincula todos os destinos dinamicamente. Isso vai acelerar o tempo de vinculação e reduz o tamanho dos binários resultantes.off
: vincula todos os destinos em modo principalmente estático. Se-static
estiver definido em linkopts, os destinos serão alterados para totalmente estáticos.
--fission (yes|no|[dbg][,opt][,fastbuild])
Ativa a fissão, que grava informações de depuração C++ em arquivos .dwo dedicados em vez de arquivos .o, onde Caso contrário, vá. Isso reduz substancialmente o tamanho da entrada para os links e pode diminuir o tempo deles.
Quando definido como [dbg][,opt][,fastbuild]
(exemplo:
--fission=dbg,fastbuild
), a fissão está ativada
apenas para o conjunto especificado de modos de compilação. Isso é útil para o Bazel
configurações. Quando definida como yes
, a fissão é ativada
universalmente. Quando definida como no
, a fissão é desativada
universalmente. O padrão é no
.
--force_ignore_dash_static
Se esta sinalização for definida, todas as opções -static
nos linkopts de
Os arquivos BUILD de regras cc_*
são ignorados. Isso é apenas um
alternativa para builds de aumento da proteção do C++.
--[no]force_pic
Se ativada, todas as compilações em C++ produzirão 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.
--android_resource_shrinking
Seleciona se quer realizar a redução de recursos para as regras android_binary. Define o padrão do atributo reduce_resources de regras de android_binary; consulte a documentação dessa regra para mais detalhes. O padrão é desativado.
--custom_malloc=malloc-library-target
Quando especificado, sempre usa a implementação Malloc especificada, substituindo todos
malloc="target"
, inclusive nos destinos que usam o
padrão (sem especificar malloc
).
--crosstool_top=label
Esta opção especifica o local do pacote do compilador crosstool
para ser usada para toda a compilação em C++ durante um build. o Bazel vai verificar
local para um arquivo CROSSTOOL e o utiliza para determinar automaticamente
configurações para --compiler
.
--host_crosstool_top=label
Se não for especificado, o Bazel usa o valor de --crosstool_top
para compilar
na configuração "exec", como as ferramentas que são executadas durante o build. O principal objetivo dessa sinalização
é ativar a compilação cruzada.
--apple_crosstool_top=label
O crosstool a ser usado para compilar regras C/C++ no deps
transitivo do
objc*, ios* e apple*. Para esses destinos, esta sinalização substitui
--crosstool_top
:
--android_crosstool_top=label
O crosstool a ser usado para compilar regras C/C++ no deps
transitivo do
android_binary
regras. Isso é útil se outros destinos no
ou build, exigem uma ferramenta diferente. O padrão é usar o crosstool
geradas pela regra android_ndk_repository
no arquivo WORKSPACE.
Consulte também --android_platforms
.
--compiler=version
Essa opção especifica a versão do compilador C/C++ (como gcc-4.1.0
).
para ser usada na compilação de binários durante o build. Se você quiser
com uma ferramenta cruzada personalizada, você deve usar um arquivo CROSSTOOL em vez de
especificando essa sinalização.
--android_sdk=label
Obsoleto. Isso não deve ser especificado diretamente.
Esta opção especifica o conjunto de ferramentas do SDK/plataforma do Android e a biblioteca Android Runtime que será usada para criar qualquer biblioteca de regra de firewall.
O SDK do Android será selecionado automaticamente se um android_sdk_repository
é definida no arquivo WORKSPACE.
--java_toolchain=label
Essa opção especifica o rótulo do java_Dataset usado para compilar Java arquivos de origem.
--host_java_toolchain=label
Se não for especificado, o Bazel vai usar o valor de --java_toolchain
para compilar
na configuração do exec, por exemplo, para ferramentas executadas durante o build. O principal objetivo dessa sinalização
é ativar a compilação cruzada.
--javabase=(label)
Essa opção define o rótulo da instalação Java de base a ser usado para o bazel run.
bazel test, e para binários Java criados por java_binary
e
java_test
. JAVABASE
e JAVA
"Marca" variáveis são derivadas dessa opção.
--host_javabase=label
Essa opção define o rótulo da instalação Java de base para usar na configuração do "exec" por exemplo, para ferramentas de build de host, incluindo JavaBuilder e Singlejar.
Isso não seleciona o compilador Java usado para compilar Java
arquivos de origem. O compilador pode ser selecionado pelas configurações que o
--java_toolchain
.
Estratégia de execução
Essas opções afetam como o Bazel vai executar a compilação. Eles não devem ter nenhum efeito significativo nos arquivos de saída gerado pelo build. Normalmente, o principal efeito é na e a velocidade do build.
--spawn_strategy=strategy
Essa opção controla onde e como os comandos são executados.
standalone
faz com que os comandos sejam executados como subprocessos locais. Esse valor é descontinuada. Em vez disso, uselocal
sandboxed
faz com que os comandos sejam executados dentro de um sandbox na máquina local. Isso exige que todos os arquivos de entrada, dependências de dados e ferramentas sejam listados como diretos dependências nos atributossrcs
,data
etools
. O Bazel ativa o sandbox local por padrão em sistemas compatíveis com a execução em sandbox.local
faz com que os comandos sejam executados como subprocessos locais.worker
faz com que os comandos sejam executados usando um worker permanente, se disponível.docker
faz com que os comandos sejam executados dentro de um sandbox do Docker na máquina local. Isso requer que o Docker esteja instalado.remote
faz com que os comandos sejam executados remotamente; só estará disponível se um O executor remoto foi configurado separadamente.
--strategy mnemonic=strategy
Essa opção controla onde e como os comandos são executados, substituindo a --spawn_strategy (e --genrule_strategy com comandos mnemônicos genrule), de acordo com a mnemônica. Consulte --spawn_strategy para os recursos estratégias e seus efeitos.
--strategy_regexp=<filter,filter,...>=<strategy>
Esta opção especifica qual estratégia deve ser usada para executar comandos que têm descrições
correspondentes a um determinado regex_filter
. Consulte
--per_file_copt para detalhes sobre
regex_filter correspondente. Consulte
--spawn_strategy para os recursos
estratégias e seus efeitos.
O último regex_filter
que corresponde à descrição é usado. Essa opção substitui
outras flags para especificar a estratégia.
- Exemplo:
--strategy_regexp=//foo.*\\.cc,-//foo/bar=local
significa executar ações usando Estratégialocal
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égiasandboxed
, mas reverter o pedido a executa comlocal
. - Exemplo: execuções de
--strategy_regexp='Compiling.*/bar=local,sandboxed'
'Compilando //foo/bar/baz' com a estratégialocal
e usasandboxed
em caso de falha.
--genrule_strategy=strategy
Essa é uma abreviação descontinuada de --strategy=Genrule=strategy
.
--jobs=n
(-j)
Essa opção, que usa um argumento de número inteiro, especifica um limite a quantidade de jobs que devem ser executados simultaneamente durante o e a fase de execução do build.
--progress_report_interval=n
O Bazel imprime periodicamente um relatório de progresso dos jobs que não estão
concluído ainda (como testes de longa duração). Essa opção define
frequência de relatório, o progresso será impresso a cada n
segundos.
O padrão é 0, o que significa um algoritmo incremental: o primeiro relatório será impresso após 10 segundos, depois 30 segundos e depois esse progresso é relatado uma vez por minuto.
Quando o Bazel 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 da CPU)
que o Bazel pode considerar ao programar atividades de compilação e teste para execução local. Elas levam
um número inteiro ou uma palavra-chave (HOST_RAM ou HOST_CPUS) opcionalmente seguida por [-|*
float]
(por exemplo, --local_cpu_resources=2
, --local_ram_resources=HOST_RAM*.5
,
--local_cpu_resources=HOST_CPUS-1
).
As sinalizações são independentes. uma ou ambas podem ser definidas. Por padrão, o Bazel estima
a quantidade de RAM e o número de núcleos de CPU diretamente da configuração do sistema local.
--[no]build_runfile_links
Essa opção, que é ativada por padrão, especifica se os arquivos de execução
No diretório de saída, crie links simbólicos para testes e binários.
Usar --nobuild_runfile_links
pode ser útil
para confirmar se todos os destinos foram compilados sem gerar sobrecarga
para criar as árvores dos arquivos de execução.
Quando testes (ou aplicativos) são executados, os dados do ambiente de execução
as dependências ficam reunidas em um só lugar. No
árvore de saída, esse "runfiles" normalmente tem raízes como um irmão
o 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
do qual eles têm uma dependência declarada e nada mais. De
padrão, a árvore de arquivos de execução é implementada construindo um conjunto de
links simbólicos para os arquivos necessários. À medida que o conjunto de links aumenta, então
o custo dessa operação e, para alguns builds grandes, ele pode
contribuem significativamente para o tempo total de compilação, especialmente porque
cada teste (ou aplicativo) individual exige uma árvore de arquivos de execução própria.
--[no]build_runfile_manifests
Essa opção, que é ativada por padrão, especifica se os manifestos de arquivos de execução
deve ser gravado na árvore de saída.
Desativá-la implica --nobuild_runfile_links
.
Ele pode ser desativado ao executar testes remotamente, pois as árvores dos arquivos de execução ser criados remotamente a partir de manifestos na memória.
--[no]discard_analysis_cache
Quando esta opção está ativada, o Bazel descarta o cache de análise logo antes do início da execução, liberando memória adicional (cerca de 10%) para a fase de execução. A desvantagem é que mais builds incrementais serão mais lentos. Consulte também modo de economia de memória.
--[no]keep_going
(- mil)
Como no GNU Make, a fase de execução de uma compilação é interrompida quando a primeira erro for encontrado. Às vezes, é útil tentar construir como o máximo possível, mesmo com erros. Essa opção ativa esse comportamento e, quando especificado, o build tentará criar todos os destinos que tiveram pré-requisitos, mas ignora os erros.
Embora essa opção seja normalmente associada à fase de execução do
de um build, isso também afeta a fase de análise: se vários destinos forem
especificados em um comando de criação, mas apenas alguns deles podem ser
for analisado, o build será interrompido com um erro
a menos que --keep_going
seja especificado. Nesse caso,
build vai prosseguir para a fase de execução, mas apenas para os destinos
que foram analisados com sucesso.
--[no]use_ijars
Essa opção muda a forma como as segmentações java_library
são
compilado pelo Bazel. Em vez de usar a saída de uma
java_library
para compilar dependências
java_library
destinos, o Bazel vai criar jars de interface
que contenham apenas as assinaturas de membros não privados (públicos,
protegidos e padrão (pacotes) e use
os jars da interface para compilar os destinos dependentes. Assim,
possível de evitar a recompilação quando alterações são feitas apenas
corpos de métodos ou membros privados de uma classe.
--[no]interface_shared_objects
Essa opção ativa objetos compartilhados por interface, o que torna binários e Outras bibliotecas compartilhadas dependem da interface de um objeto compartilhado e não na implementação. Quando apenas a implementação muda, o Bazel pode evitar a recriação de destinos que dependem da biblioteca compartilhada alterada desnecessariamente.
Seleção de saída
Essas opções determinam o que compilar ou testar.
--[no]build
Essa opção faz com que a fase de execução do build ocorra. ele é são ativados por padrão. Quando ele é desativado, a fase de execução pulados, e apenas as duas primeiras fases, carregamento e análise, ocorrem.
Essa opção pode ser útil para validar arquivos BUILD e detectar erros nas entradas, sem realmente criar nada.
--[no]build_tests_only
Se especificado, o Bazel cria apenas o que é necessário para executar a *_test
e test_suite
regras que não foram filtradas devido a
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
solicitado, incluindo *_test
e test_suite
regras que foram filtradas de
testes. Isso é útil porque executar
bazel test --build_tests_only foo/...
pode não detectar todos os builds
de segurança na árvore foo
.
--[no]check_up_to_date
Essa opção faz com que o Bazel não execute uma compilação, apenas verifique se todos os destinos especificados estão atualizados. Nesse caso, o build é concluída com sucesso, como de costume. No entanto, se algum arquivo estiver fora do em vez de ser criado, um erro é informado e o build falhar. Essa opção pode ser útil para determinar se um build tem foi realizada mais recentemente do que uma edição de origem (por exemplo, para pré-envio de testes) sem incorrer no custo de um build.
Consulte também --check_tests_up_to_date
.
--[no]compile_one_dependency
Compila uma única dependência dos arquivos de argumento. Isso é útil para a sintaxe de arquivos de origem em ambientes de desenvolvimento integrado, por exemplo, reconstruindo uma de destino que depende do arquivo de origem para detectar erros possível no ciclo de edição/criação/teste. Esse argumento afeta a maneira como argumentos sem sinalização são interpretados: cada argumento deve ser um rótulo de destino do arquivo ou um nome de arquivo simples relativo ao arquivo em funcionamento atual e uma regra que depende do nome do arquivo de origem é criada. Para C++ e Java fontes, regras no mesmo espaço de linguagem são escolhidas preferencialmente. Para várias regras com a mesma preferência, a que aparece primeiro na BUILD é escolhido. Um padrão de destino nomeado explicitamente que não referenciar um arquivo de origem resulta em erro.
--save_temps
A opção --save_temps
faz com que as saídas temporárias do compilador sejam
salvas. Isso inclui arquivos .s (código assembler), .i (pré-processado em C) e .ii
(C++ pré-processados). Essas saídas geralmente são úteis para depuração. As temperaturas programadas só serão
gerado para o conjunto de destinos especificados na linha de comando.
No momento, a sinalização --save_temps
funciona somente para regras cc_*.
Para que o Bazel imprima o local dos outros arquivos de saída, verifique se
seu --show_result n
é alta o suficiente.
--build_tag_filters=tag[,tag]*
Se especificado, o Bazel cria apenas destinos que têm pelo menos uma tag obrigatória (se alguma delas for especificada) e não tem tags excluídas. Tag de build filtro é especificado como uma lista delimitada por vírgulas de palavras-chave de tag; opcionalmente, precedido por "-" usado para indicar tags excluídas. As tags obrigatórias também podem têm um sinal "+" antes sinal
Ao executar testes, o Bazel ignora --build_tag_filters
para destinos de teste.
que são criados e executados mesmo que não correspondam a esse filtro. Para não construí-los, filtre
destinos de teste usando --test_tag_filters
ou os excluindo explicitamente.
--test_size_filters=size[,size]*
Se especificado, o Bazel vai testar (ou compilar se --build_tests_only
)
também é especificado) somente testes com o tamanho determinado. 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 '-' usado para indicar
tamanhos de teste excluídos. Por exemplo,
% bazel test --test_size_filters=small,medium //foo:all
e
% bazel test --test_size_filters=-large,-enormous //foo:all
testará somente testes pequenos e médios em //foo.
Por padrão, a filtragem de tamanho do teste não é aplicada.
--test_timeout_filters=timeout[,timeout]*
Se especificado, o Bazel vai testar (ou compilar se --build_tests_only
)
também é especificado) somente em destinos de teste com o tempo limite especificado. Testar filtro de tempo limite
é especificado como uma lista delimitada por vírgulas de valores de tempo limite de teste permitidos (curtos,
moderado, longo ou eterno), opcionalmente precedido por "-" usado para indicar
tempos limite de teste excluídos. Veja --test_size_filters
por exemplo, sintaxe.
Por padrão, a filtragem de tempo limite do teste não é aplicada.
--test_tag_filters=tag[,tag]*
Se especificado, o Bazel vai testar (ou compilar se --build_tests_only
)
também é especificada) somente destinos de teste que tenham pelo menos uma tag obrigatória
(se alguma delas for especificada) e não tem tags excluídas. Tag de teste
filtro é especificado como uma lista delimitada por vírgulas de palavras-chave de tag; opcionalmente,
precedido por "-" usado para indicar tags excluídas. As tags obrigatórias também podem
têm um sinal "+" antes sinal
Por exemplo,
% bazel test --test_tag_filters=performance,stress,-flaky //myproject:all
testa os destinos marcados com performance
ou
stress
, mas não são marcadas com flaky
.
Por padrão, a filtragem de tags de teste não é aplicada. Também é possível filtrar
nas tags size
e local
do teste em
dessa maneira.
--test_lang_filters=string[,string]*
Especifica uma lista separada por vírgulas de strings referentes aos nomes da regra de teste
classes. Para se referir à classe de regra foo_test
, use a string "foo". O Bazel vai
Somente teste (ou build se --build_tests_only
também for especificado)
destinos das classes de regras referenciadas. Para excluir essas segmentações, use
pela string "-foo". Por exemplo,
% bazel test --test_lang_filters=foo,bar //baz/...
testará somente destinos que são instâncias de foo_test
ou bar_test
em
//baz/...
, enquanto
% bazel test --test_lang_filters=-foo,-bar //baz/...
vai testar todos os destinos na //baz/...
, exceto foo_test
e
bar_test
instâncias.
--test_filter=filter-expression
Especifica um filtro que o executor de testes pode usar para escolher um subconjunto de testes para em execução. Todos os destinos especificados na invocação são criados, mas dependendo a expressão. Apenas alguns deles poderão ser executados; em alguns casos, apenas alguns métodos de teste são executados.
A interpretação específica de filter-expression depende de
o framework responsável por executar o teste. Pode ser uma massa,
substring ou regexp. --test_filter
é uma conveniência
passando diferentes argumentos de filtro --test_arg
,
mas nem todos os frameworks aceitam.
Verbosidade
Essas opções controlam o nível de detalhes 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ências na fase de execução do bazel build
para
explicar, para cada etapa de build, por que ela está sendo executada ou
para confirmar que está atualizado. A explicação está escrita
em logfile.
Se você se deparar com recriações inesperadas, essa opção pode ajudar a
entender o motivo. Adicione-o ao .bazelrc
para que
a geração de registros ocorre em todos os builds subsequentes e, em seguida, inspeciona o registro
quando uma etapa de execução é executada inesperadamente. Esta opção
pode ter uma pequena queda de desempenho, e convém remover
quando não forem mais necessários.
--verbose_explanations
Essa opção aumenta o nível de detalhes das explicações geradas quando a opção --explain está ativada.
Se as explicações detalhadas estiverem ativadas, e um arquivo de saída é recriado porque o comando usado para o build tiver sido alterado, a saída no arquivo de explicação incluem os detalhes completos do novo comando (pelo menos para a maioria .
Usar essa opção pode aumentar significativamente a duração do
de explicação gerado e a penalidade de desempenho ao usar
--explain
:
Se --explain
não estiver ativado,
--verbose_explanations
não tem efeito.
--profile=file
Essa opção, que usa um argumento de nome de arquivo, faz com que o Bazel grave
a criação de perfil
em um arquivo. Em seguida, os dados podem ser analisados usando o
bazel analyze-profile
. O perfil de criação pode ser útil
entender onde o comando build
do Bazel está gastando tempo.
--[no]show_loading_progress
Essa opção faz com que o Bazel mostre o progresso do carregamento do pacote e envio de mensagens. Se estiver desativada, as mensagens não serão mostradas.
--[no]show_progress
Essa opção exibe mensagens de progresso. está ativado por padrão. Quando desativada, 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 desta opção é 0,02, o que significa que o Bazel vai limitar o progresso.
uma mensagem a cada 0,02 segundo.
--show_result=n
Esta opção controla a impressão das informações do resultado no final
de um comando bazel build
. Por padrão, se um único
destino de build for especificado, o Bazel imprimirá uma mensagem informando se
ou não, o destino foi atualizado com sucesso e, em caso afirmativo,
a lista de arquivos de saída criados pelo destino. Se várias
destino forem especificados, as informações do resultado não serão exibidas.
Embora as informações do resultado possam ser úteis para builds de um único
destino ou alguns destinos, para builds grandes (como um repositório
árvore de projeto), essas informações podem ser esmagadoras e distrativas;
essa opção permite que ele seja controlado. --show_result
usa um argumento de número inteiro, que é o número máximo de alvos
para o qual as informações completas do resultado devem ser impressas. Por padrão,
o valor será 1. Acima desse limite, nenhuma informação de resultado é
exibidos para destinos individuais. Assim, zero faz com que o resultado
a informação seja sempre suprimida, e um valor muito grande causa
o resultado seja sempre impresso.
Os usuários podem escolher um valor entre os dois valores
alternar entre criar um pequeno grupo de destinos (por exemplo,
durante o ciclo de compilação-edição-teste) e um grande grupo de destinos
(por exemplo, ao estabelecer um novo espaço de trabalho ou
testes de regressão). No primeiro caso, as informações do resultado são
muito útil, enquanto no último caso não é. Assim como em todos os
essa opção pode ser especificada implicitamente por
arquivo .bazelrc
.
Os arquivos são impressos para facilitar a cópia e a colagem do nome do arquivo ao shell, para executar executáveis compilados. A fase "atualizado" ou "falha" as mensagens para cada destino podem ser facilmente analisadas por scripts que impulsionam o build.
--sandbox_debug
Essa opção faz com que o Bazel imprima informações extras de depuração ao usar o sandbox para ações execução. Essa opção também preserva os diretórios de sandbox, para que os arquivos visíveis para as ações durante a execução podem ser examinadas.
--subcommands
(-s
)
Essa opção faz com que a fase de execução do Bazel mostre a linha de comando completa para cada comando antes de executá-lo.
>>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world'] (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \ exec env - \ /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
Sempre que possível, os comandos são impressos em uma sintaxe compatível com shell Bourne,
para que possam ser facilmente copiadas e coladas em um prompt de comando do shell.
(Os parênteses ao redor são fornecidos para proteger o shell contra os
Chamadas cd
e exec
lembre-se de copiá-los.
No entanto, alguns comandos são implementados internamente no Bazel, como
a criação de árvores de links simbólicos. Para esses casos, não há linha de comando para exibir.
--subcommands=pretty_print
pode ser transmitido para impressão
os argumentos do comando como uma lista, e não como uma única linha. Isso pode
ajudam a tornar as 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.
--verbose_failures
Essa opção faz com que a fase de execução do Bazel mostre a linha de comando completa para comandos que falharam. Isso pode ser inestimável para depurar build com falha.
Os comandos com falha são impressos em uma sintaxe compatível com shell Bourne, adequada para copiar e colar em um prompt de shell.
Status do espaço de trabalho
Use estas opções para "carimbo" Binários criados pelo Bazel: para incorporar mais informações ao
binários, como a revisão do controle de origem ou outras informações relacionadas ao espaço de trabalho. Você pode usar
esse mecanismo com regras compatíveis com o atributo stamp
, como
genrule
, cc_binary
, entre outros.
--workspace_status_command=program
Essa flag permite especificar um binário que o Bazel executa antes de cada build. O programa pode informar informações sobre o status do espaço de trabalho, como a revisão atual do controle de origem.
O valor da sinalização precisa ser um caminho para um programa nativo. No Linux/macOS, isso pode ser qualquer executável. No Windows, precisa ser um binário nativo, normalmente um ".exe", ".bat" ou um ".cmd" .
O programa precisa mostrar zero ou mais pares de chave-valor na saída padrão, uma entrada em cada linha. e sair com zero (caso contrário, o build falhará). Os nomes das chaves podem ser qualquer coisa, mas só podem use letras maiúsculas e sublinhados. O primeiro espaço após o nome da chave a separa do . O valor é o resto da linha (incluindo espaços em branco adicionais). Nem a chave nem a o valor pode se estender por várias linhas. As chaves não podem ser duplicadas.
O Bazel particiona as chaves em dois buckets: "estáveis". e "volátil". (Os nomes "estável" e "volátil" são um pouco pouco intuitivas, então não pense muito sobre elas.)
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 comSTABLE_
bazel-out/volatile-status.txt
contém o restante das chaves e seus valores
O contrato é:
"estável" chaves" valores devem mudar raramente, se possível. Se o conteúdo do
bazel-out/stable-status.txt
mudança, o Bazel invalida as ações que dependem deles. Em Em outras palavras, se o valor de uma chave estável mudar, o Bazel vai executar novamente as ações marcadas. Portanto, o status estável não deve conter elementos como carimbos de data/hora, porque eles mudam todos e faria com que o Bazel executasse novamente ações estampadas em cada build.O Bazel sempre gera as seguintes chaves estáveis:
BUILD_EMBED_LABEL
: valor de--embed_label
BUILD_HOST
: o nome da máquina host em que o Bazel está sendo executado.BUILD_USER
: o nome do usuário em que o Bazel está sendo executado.
"volátil" chaves" os valores podem mudar com frequência. Bazel espera que eles mudem o tempo todo, os carimbos de data/hora fazem e atualiza
bazel-out/volatile-status.txt
. Para evitar sempre executando ações estampadas, o Bazel finge que o arquivo volátil nunca mudanças. Em outras palavras, se o arquivo de status volátil for o único arquivo cujo conteúdo tenha alterado, o Bazel não invalida as ações que dependem dele. Se outras entradas das ações forem alteradas, o Bazel vai executar a ação novamente, e a ação vai conferir o status, mas a alteração do status volátil por si só não invalida a ação.O Bazel sempre gera as seguintes chaves voláteis:
BUILD_TIMESTAMP
: tempo do build em segundos desde a época Unix (o valor deSystem.currentTimeMillis()
dividido por mil)FORMATTED_DATE
: horário do build. Formatado comoyyyy MMM d HH mm ss EEE
(por exemplo, 2 de junho de 2023, 1o de junho de 2023, 29h, 29h) em UTC.
No Linux/macOS, você pode transmitir --workspace_status_command=/bin/true
para
desativar a recuperação do status do espaço de trabalho, porque true
não faz nada, com êxito (saia
com zero) e não gera nenhum resultado. No Windows, você pode transmitir o caminho do true.exe
do MSYS
para obter o mesmo efeito.
Se o comando de status do espaço de trabalho falhar (sair em um número diferente de zero) por qualquer motivo, o build falhará.
Exemplo de programa no Linux usando 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
e 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 se é preciso
para incorporar informações do build em binários.
A marcação pode ser ativada ou desativada explicitamente de acordo com a regra usando o método
stamp
. Consulte a Enciclopédia de Criação para mais detalhes. Quando
uma regra definir stamp = -1
(o padrão para *_binary
regras), esta opção
determina se a estampagem está ativada.
O Bazel nunca grava binários criados para a configuração "exec".
independentemente dessa opção ou do atributo stamp
. Para regras que definem stamp =
0
(o padrão para regras *_test
), a estampagem é desativada, independentemente
--[no]stamp
Especificar --stamp
não força os destinos a serem recriados se
suas dependências não mudaram.
Em geral, é recomendável definir --nostamp
para melhorar o desempenho do build, já que
reduz a volatilidade da entrada e maximiza o armazenamento em cache do build.
Plataforma
Use essas opções para controlar as plataformas host e de destino que configuram o funcionamento das versões e para controlam quais plataformas de execução e conjuntos de ferramentas estão disponíveis para as regras do Bazel.
Consulte informações básicas sobre plataformas e conjuntos de ferramentas.
--platforms=labels
Os rótulos das regras de 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
As plataformas que estão disponíveis como plataformas de execução para executar ações. As plataformas podem ser especificadas por destino exato ou como um padrão de destino. Esses plataformas serão consideradas antes daquelas declaradas no arquivo WORKSPACE por register_execution_platforms(); Essa opção aceita uma lista de plataformas separada por vírgulas em ordem de prioridade. Se a sinalização for transmitida várias vezes, as substituições mais recentes serão feitas.
--extra_toolchains=labels
As regras do conjunto de ferramentas a serem consideradas durante a resolução. Conjuntos de ferramentas pode ser especificado por destino exato ou como um padrão de destino. Esses conjuntos de ferramentas ser consideradas antes daquelas declaradas no arquivo WORKSPACE register_toolchains().
--toolchain_resolution_debug=regex
Imprime informações de depuração ao encontrar conjuntos de ferramentas se o tipo de conjunto de ferramentas corresponder
o regex. Várias regex podem ser separadas por vírgulas. A regex pode ser
negado usando um -
no início. Isso pode ajudar os desenvolvedores
de regras do Bazel ou 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 mais mais detalhes, consulte a Configurações do Starlark.
--symlink_prefix=string
Altera o prefixo dos links simbólicos de conveniência gerados. A
o valor padrão para o prefixo do link simbólico é bazel-
, que
vai criar os links simbólicos bazel-bin
, bazel-testlogs
e
bazel-genfiles
.
Se não for possível criar os links simbólicos por qualquer motivo, será exibido um aviso emitida, mas o build ainda é considerado um sucesso. Especificamente, você poderá criar em um diretório somente leitura ou em um que permissão de gravação. Caminhos exibidos em páginas informativas mensagens na conclusão de uma versão usarão apenas o forma abreviada do link simbólico se os links simbólicos apontarem para a página localização; Em outras palavras, você pode confiar na precisão caminhos, mesmo que não possa confiar nos links simbólicos que estão sendo criados.
Alguns valores comuns dessa opção:
Suprimir a criação de links simbólicos:
--symlink_prefix=/
fará com que o Bazel não criar ou atualizar links simbólicos, incluindobazel-out
ebazel-<workspace>
links simbólicos. Use essa opção para suprimir completamente a criação de links simbólicos.Facilite a organização:
--symlink_prefix=.bazel/
vai fazer com que o Bazel crie links simbólicos chamadosbin
(etc.) dentro de um diretório oculto.bazel
.
--platform_suffix=string
Adiciona um sufixo ao nome curto da configuração, que é usado para determinar no diretório de saída. Definir esta opção com valores diferentes coloca os arquivos em diretórios diferentes, por exemplo, para melhorar as taxas de ocorrência em cache para builds que prejudicam uns aos outros os arquivos de saída ou mantêm os arquivos de saída para fins de comparação.
--default_visibility=(private|public)
Sinalização temporária para testar as mudanças de visibilidade padrão do Bazel. Não destinado ao uso geral mas documentado para integridade" saquê.
--starlark_cpu_profile=_file_
Essa flag, que tem o valor do nome de um arquivo, faz com que o Bazel colete estatísticas sobre o uso de CPU por todas as linhas de execução do Starlark. e criar o perfil no formato pprof ao arquivo nomeado.
Use essa opção para ajudar a identificar funções do Starlark que que tornam o carregamento e a análise lentos devido à computação excessiva. Exemplo:
$ bazel build --nobuild --starlark_cpu_profile=/tmp/pprof.gz my/project/... $ pprof /tmp/pprof.gz (pprof) top Type: CPU Time: Feb 6, 2020 at 12:06pm (PST) Duration: 5.26s, Total samples = 3.34s (63.55%) Showing nodes accounting for 3.34s, 100% of 3.34s total flat flat% sum% cum cum% 1.86s 55.69% 55.69% 1.86s 55.69% sort_source_files 1.02s 30.54% 86.23% 1.02s 30.54% expand_all_combinations 0.44s 13.17% 99.40% 0.44s 13.17% range 0.02s 0.6% 100% 3.34s 100% sorted 0 0% 100% 1.38s 41.32% my/project/main/BUILD 0 0% 100% 1.96s 58.68% my/project/library.bzl 0 0% 100% 3.34s 100% main
Para visualizações diferentes dos mesmos dados, teste os comandos pprof
svg
,
web
e list
.
Como usar o Bazel para versões
Ele é usado por engenheiros de software durante o desenvolvimento e por engenheiros de lançamento ao preparar binários para implantação à produção. Esta seção fornece uma lista de dicas para engenheiros usando o Bazel.
Opções importantes
Ao usar o Bazel para builds de lançamento, surgem os mesmos problemas que outros scripts. que executam um build. Para mais detalhes, consulte Chame o Bazel usando scripts. Especificamente, as opções a seguir são altamente recomendados:
Estas opções também são importantes:
--package_path
--symlink_prefix
: para gerenciar builds para várias configurações, pode ser conveniente distinguir cada build por um identificador distinto, como "64 bits" x "32 bits". Esta opção diferencia os links simbólicos debazel-bin
(etc.).
Como executar testes
Para criar e executar testes com o Bazel, digite bazel test
seguido de
o nome dos destinos de teste.
Por padrão, esse comando executa build e teste simultâneos
atividade, criando todos os destinos especificados (incluindo aqueles que não sejam de teste
destinos especificados na linha de comando) e testes
Metas *_test
e test_suite
assim que
os pré-requisitos são criados, o que significa que a execução do teste
intercaladas com a construção. Isso geralmente resulta em problemas
ganhos de velocidade.
Opções de bazel test
--cache_test_results=(yes|no|auto)
(-t
)
Se essa opção estiver definida como "automática", (padrão), o Bazel só vai executar novamente um teste as seguintes condições se aplicam:
- O Bazel detecta mudanças no teste ou nas dependências dele.
- o teste está marcado como
external
- várias execuções de teste foram solicitadas com
--runs_per_test
- o teste falhou.
Se "não", todos os testes serão executados incondicionalmente.
Se "sim", o comportamento do armazenamento em cache será o mesmo que o automático
exceto que pode armazenar em cache falhas de teste e execuções de teste com
--runs_per_test
:
Os usuários que ativaram essa opção por padrão no
o arquivo .bazelrc
dele poderá encontrar a
abreviações -t
(ativada) ou -t-
(desativada)
conveniente para substituir o padrão em uma execução específica.
--check_tests_up_to_date
Essa opção diz ao Bazel para não executar os testes, mas apenas verificar e relatar os resultados armazenados em cache. Se houver testes que não foram criados e executados anteriormente ou com resultados de testes desatualizados (por exemplo, devido a o código-fonte ou as opções de build tiverem mudado), o Bazel vai informar uma mensagem de erro ("o resultado do teste não está atualizado") status como "SEM STATUS" (em vermelho, se a saída de cor estiver ativada) e retornará um código de saída diferente de zero.
Essa opção também implica
Comportamento de [--check_up_to_date](#check-up-to-date)
.
Essa opção pode ser útil para verificações de pré-envio.
--test_verbose_timeout_warnings
Esta opção diz ao Bazel para avisar explicitamente o usuário se o tempo limite de um teste for muito maior do que o tempo de execução real do teste. Enquanto um teste deve ser definido de modo que não seja instável, um teste que tem uma um tempo limite muito generoso pode ocultar problemas reais que surgem inesperadamente.
Por exemplo, um teste que normalmente é executado em um ou dois minutos não deve ter tempo limite de ETERNAL ou LONG porque são generosos demais.
Essa opção é útil para ajudar os usuários a decidir sobre um bom valor de tempo limite ou verificação de integridade dos valores de tempo limite.
--[no]test_keep_going
Por padrão, todos os testes são executados até a conclusão. Se essa sinalização estiver desativada,
No entanto, o build é cancelado em qualquer teste que não passe. Etapas de build subsequentes
e as invocações de teste não são executadas, e as invocações em andamento são canceladas.
Não especifique --notest_keep_going
e --keep_going
ao mesmo tempo.
--flaky_test_attempts=attempts
Esta opção especifica o número máximo de vezes que um teste deve ser tentado
em caso de falha por qualquer motivo. um teste que falha inicialmente, mas eventualmente
bem-sucedidos é relatado como FLAKY
no resumo do teste. Sim,
No entanto, é considerado transmitido quando se trata de identificar o código de saída do Bazel.
ou o total de testes aprovados. Os testes que falham em todas as tentativas permitidas são
foram consideradas reprovadas.
Por padrão (quando essa opção não é especificada ou quando é definida como
padrão), apenas uma tentativa é permitida para testes regulares, e
3 para regras de teste com o atributo flaky
definido. É possível especificar
um valor inteiro para substituir o limite máximo de tentativas de teste. O Bazel permite
no máximo 10 tentativas de teste para evitar abuso do sistema.
--runs_per_test=[regex@]number
Essa opção especifica o número de vezes que cada teste precisa ser executado. Todos execuções de teste são tratadas como testes separados (funcionalidade substituto se aplicam a cada uma delas de maneira independente).
O status de um destino com falhas em execuções depende do valor
Sinalização --runs_per_test_detects_flakes
:
- Se ausente, qualquer execução com falha fará com que todo o teste falhe.
- Se presente e duas execuções do mesmo fragmento retornarem PASS e FAIL, o teste receberá um status de instável (a menos que outras execuções com falha causem falhar).
Se um único número for especificado, todos os testes serão executados na mesma quantidade de vezes.
Como alternativa, uma expressão regular pode ser especificada usando a sintaxe
regex@número. Isso restringe o efeito de --runs_per_test
às metas
que correspondem ao regex (--runs_per_test=^//pizza:.*@4
executa todos os testes
menos de //pizza/
quatro vezes).
Esta forma de --runs_per_test
pode ser especificada mais de uma vez.
--[no]runs_per_test_detects_flakes
Se essa opção for especificada (por padrão, não é), o Bazel detectará erros
fragmentos de teste usando --runs_per_test
. Se uma ou mais execuções para um único fragmento
e uma ou mais execuções para o mesmo passe de fragmento, o destino será
considerada irregular com a sinalização. Se não for especificado, o destino informará uma
o status de falha.
--test_summary=output_style
Especifica como o resumo do resultado do teste deve ser exibido.
short
imprime os resultados de cada teste junto com o nome do o arquivo que contém a saída do teste em caso de falha. Esse é o valor padrão.terse
gosta deshort
, mas ainda mais curta: somente impressão informações sobre testes que não foram aprovados.detailed
imprime cada caso de teste individual que falhou, não apenas para cada teste. Os nomes dos arquivos de saída de teste são omitidos.none
não mostra o resumo do teste.
--test_output=output_style
Especifica como a saída do teste deve ser exibida:
summary
mostra um resumo se cada teste foi aprovado ou falhou. Também mostra o nome do arquivo de registro de saída dos testes com falha. Resumo será impresso no final da compilação (durante a criação, veria apenas mensagens de progresso simples quando os testes são iniciados, aprovados ou reprovados). Esse é o comportamento padrão.errors
envia uma saída combinada stdout/stderr de testes com falha apenas para a stdout imediatamente após a conclusão do teste, garantindo que a saída de testes simultâneos não é intercalada entre si. Imprime um resumo no build de acordo com a saída de resumo acima.all
é semelhante aerrors
, 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, o que faz com que os tempos de teste e outras
(como tentativas de teste) a serem impressas no resumo do teste. Se
--noverbose_test_summary
for especificado, o resumo do teste
incluir apenas o nome do teste, o status do teste e o indicador de teste armazenado em cache, além de
devem ser formatados para ter até 80 caracteres quando possível.
--test_tmpdir=path
Especifica o diretório temporário para testes executados localmente. Cada teste será
em um subdiretório separado dentro desse diretório. O diretório vai
ser limpos no início de cada comando bazel test
.
Por padrão, o Bazel colocará esse diretório no diretório base de saída do Bazel.
--test_timeout=seconds
OU --test_timeout=seconds,seconds,seconds,seconds
Substitui o valor de tempo limite de todos os testes usando o número especificado de segundos como um novo valor de tempo limite. Se apenas um valor for fornecido, ele será ser usado para todas as categorias de tempo limite de teste.
Como alternativa, é possível fornecer quatro valores separados por vírgula, especificando tempos limite individuais para testes curtos, moderados, longos e eternos (nesse caso, ). De qualquer forma, zero ou um valor negativo para qualquer um dos tamanhos de teste ser substituídos pelo tempo limite padrão pelas categorias de tempo limite fornecidas conforme definida pela página Como programar testes. Por padrão, o Bazel usa esses tempos limite para todos os testes inferir o tempo limite com base no tamanho do teste, independente de ser implicitamente ou explicitamente definidos.
Testes que declaram explicitamente a categoria de tempo limite como diferente dos receberá o mesmo valor como se esse tempo limite tivesse sido definido implicitamente pela a tag de tamanho. Então, um teste de tamanho "pequeno" que declara um "longo" tempo limite vai têm o mesmo tempo limite efetivo que um "large" que os testes não têm com políticas tempo limite.
--test_arg=arg
Transmite opções/flags/argumentos da linha de comando para cada processo de teste. Isso
pode ser usada várias vezes para passar vários argumentos. Por exemplo, --test_arg=--logtostderr --test_arg=--v=3
.
--test_env=variable=_value_
OU --test_env=variable
Especifica variáveis adicionais que precisam ser injetadas no teste
para cada teste. Se value não for especificado, ele será
herdado do ambiente shell usado para iniciar o bazel test
kubectl.
O ambiente pode ser acessado de dentro 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. A A command-prefix é dividida em palavras usando o shell Bourne. regras de tokenização, e a lista de palavras é anexada ao prefixo que será executado.
Se a primeira palavra for um rótulo totalmente qualificado (começa com
//
) é criado. Em seguida, o rótulo é substituído pelo
local executável correspondente que é anexado ao comando
que será executado junto com as outras palavras.
Algumas ressalvas se aplicam:
- O PATH usado para executar testes pode ser diferente do PATH no seu ambiente.
Talvez seja necessário usar um caminho absoluto para o
--run_under
. (a primeira palavra em command-prefix). stdin
não está conectado. Por isso,--run_under
não pode ser usada 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'
Testar seleção
Conforme documentado em Opções de seleção de saída, é possível filtrar os testes por tamanho, tempo limite, tag ou idioma. Uma conveniência filtro de nome geral pode encaminhar determinados filtrar args para o executor de testes.
Outras opções para bazel test
A sintaxe e as outras opções são exatamente iguais
bazel build
Como executar executáveis
O comando bazel run
é semelhante a bazel build
, exceto pelo
ele é usado para criar e executar um único destino. Aqui está 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
bazel run
é semelhante, mas não idêntico, à invocação direta
o binário criado pelo Bazel e o comportamento dele são diferentes dependendo se o
binário a ser invocado
é um teste ou não.
Quando o binário não for um teste, o diretório de trabalho atual será o árvore de arquivos de execução do binário.
Quando o binário for um teste, o diretório de trabalho atual será a raiz "exec"
e uma tentativa de boa-fé é feita para replicar os testes de ambiente geralmente são
ser executado. A emulação não é perfeita, e os testes que têm várias
os fragmentos não podem ser executados dessa forma (a
É possível usar a opção de linha de comando --test_sharding_strategy=disabled
solução)
As variáveis de ambiente extras a seguir também estão disponíveis para o binário:
BUILD_WORKSPACE_DIRECTORY
: a raiz do espaço de trabalho em que o build foi executado.BUILD_WORKING_DIRECTORY
: o diretório de trabalho atual em que O Bazel foi executado.
Elas podem ser usadas, por exemplo, para interpretar nomes de arquivos na linha de comando em fácil de usar.
Opções de bazel run
--run_under=command-prefix
Isso tem o mesmo efeito que a opção --run_under
para
bazel test
(veja acima),
exceto que se aplica ao comando que está sendo executado por bazel
run
em vez dos testes sendo executados por bazel test
.
e não podem ser executados sob o rótulo.
Como filtrar saídas de geração de registros do Bazel
Ao invocar um binário com bazel run
, o Bazel imprime a saída de geração de registros do Bazel.
e o binário em invocação. Para deixar os registros com menos ruído, é possível
suprimir as saídas do próprio Bazel com os métodos --ui_event_filters
e
--noshow_progress
.
Exemplo:
bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp
Como executar testes
O bazel run
também pode executar binários de teste, o que tem o efeito de
executar o teste em uma aproximação do ambiente descrito em
Como programar testes. Nenhuma das
Os argumentos --test_*
têm efeito ao executar um teste dessa maneira, exceto
--test_arg
.
Como limpar saídas de build
O comando clean
O Bazel tem um comando clean
, análogo ao do Make.
Ele exclui os diretórios de saída de todas as configurações de build realizadas.
por esta instância do Bazel ou por toda a árvore de trabalho criada por ela.
instância do Bazel e redefine os caches internos. Se executada sem nenhuma
opções de linha de comando e, em seguida, o diretório de saída para todas as configurações
que serão limpos.
Lembre-se de que cada instância do Bazel está associada a um único espaço de trabalho,
O comando clean
excluirá todas as saídas de todos os builds que você fez
a essa instância do Bazel nesse espaço de trabalho.
remover completamente toda a árvore de trabalho criada por um Bazel.
é possível especificar a opção --expunge
. Quando
executado com --expunge
, o comando clean simplesmente
remove toda a árvore de base de saída que, além do build
saída, contém todos os arquivos temporários criados pelo Bazel. Ela também
interrompe o servidor do Bazel após a limpeza, equivalente ao comando shutdown
. Por exemplo, para
limpar todos os rastros de disco e memória de uma instância do Bazel,
especificar:
% bazel clean --expunge
Como alternativa, é possível eliminar em segundo plano usando
--expunge_async
: É seguro invocar um comando do Bazel
no mesmo cliente enquanto a eliminação assíncrona continua em execução.
O comando clean
é fornecido principalmente como um meio de
recuperar espaço em disco para espaços de trabalho que não são mais necessários.
As recompilações incrementais do Bazel podem não ser
perfeitos, para que clean
possa ser usado para recuperar um bloco
quando surgem problemas.
O design do Bazel permite que esses problemas sejam corrigidos
esses bugs têm alta prioridade
para serem corrigidos. Se você
encontrar um build incremental incorreto, enviar um relatório do bug e informar bugs nas ferramentas
em vez de usar clean
.
Como consultar o gráfico de dependências
O Bazel inclui uma linguagem de consulta para fazer perguntas sobre o gráfico de dependência usado durante o build. A linguagem de consulta é usada por dois comandos: query e cquery. A principal diferença entre o dois comandos é que a consulta é executada após a fase de carregamento. e o cquery é executado após a fase de análise. Essas ferramentas são ajuda inestimável em muitas tarefas de engenharia de software.
A linguagem de consulta é baseada na ideia operações algébricas sobre gráficos; está documentado em detalhes
Referência de consulta do Bazel. Consulte esse documento para referência, para e para opções de linha de comando específicas de consultas.
A ferramenta de consulta aceita diversas opções de
é a melhor opção. --output
seleciona o formato de saída.
--[no]keep_going
(desativado por padrão) faz com que a consulta
para continuar a progredir com os erros. esse comportamento pode ser
desativado se um resultado incompleto não for aceitável em caso de erros.
A opção --[no]tool_deps
,
ativado por padrão, faz com que as dependências em configurações que não sejam de destino sejam incluídas no
gráfico de dependência em que a consulta opera.
A opção --[no]implicit_deps
, ativada por padrão, faz com que
dependências implícitas a serem incluídas no gráfico de dependências sobre o qual a consulta opera. Um
A dependência implícita é aquela que não está explicitamente especificada no arquivo BUILD.
mas adicionados por 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
O comando aquery
permite consultar ações no gráfico de build.
Ele opera no gráfico de destino configurado pós-análise e expõe
informações sobre ações, artefatos e os relacionamentos delas.
A ferramenta aceita várias opções de linha de comando.
--output
seleciona o formato de saída. O formato de saída padrão
(text
) é legível. Use proto
ou textproto
para
legível por máquina.
O comando aquery é executado sobre um build regular do Bazel e herda
o conjunto de opções disponíveis durante um build.
Ela suporta o mesmo conjunto de funções que também está disponível para
query
, mas siblings
, buildfiles
e
tests
.
Para mais detalhes, consulte Consulta do gráfico de ações.
Comandos e opções diversos
help
O comando help
fornece ajuda on-line. Por padrão, ele
mostra um resumo dos comandos disponíveis e dos tópicos de ajuda, como mostrado em
Como criar com o Bazel.
A especificação de um argumento exibe a ajuda detalhada para um determinado
tópico. 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 a comandos.
--[no]long
(-l
)
Por padrão, o bazel help [topic]
imprime apenas uma
resumo das opções relevantes para um tópico. Se
a opção --long
for especificada, o tipo, o valor padrão
e a descrição completa de cada opção também é impressa.
shutdown
Os processos do servidor do Bazel podem ser interrompidos usando o shutdown
.
kubectl. Esse comando faz com que o servidor do Bazel seja encerrado assim que
se tornar ocioso (por exemplo, após a conclusão de quaisquer builds ou outras
comandos que estão em andamento). Para mais detalhes, consulte
Implementação de cliente/servidor.
Como os servidores do Bazel são interrompidos após um tempo limite de inatividade, esse comando raramente é necessário; No entanto, pode ser útil em scripts quando for conhecido que nenhuma outra construção ocorrerá em um determinado espaço de trabalho.
shutdown
aceitou uma
--iff_heap_size_greater_than _n_
, que
requer um argumento de número inteiro (em MB). Se especificado, isso faz com que o encerramento
com base na quantidade de memória já consumida. Isso é
útil para scripts que iniciam vários builds, já que qualquer
vazamentos no servidor do Bazel podem causar falhas indevidas
ocasião; executar uma reinicialização condicional antecipa essa condição.
info
O comando info
imprime vários valores associados às
a instância do servidor Bazel ou com uma configuração de build específica.
Elas podem ser usadas por scripts que direcionam um build.
O comando info
também permite uma única (opcional)
, que é o nome de uma das chaves na lista abaixo.
Neste caso, bazel info key
só vai imprimir
o valor dessa chave. Isso é bastante conveniente quando
criar o script do Bazel para evitar a necessidade de canalizar o resultado.
até sed -ne /key:/s/key://p
:
Dados independentes de configuração
release
: o rótulo da versão deste Bazel. instância ou "versão de desenvolvimento" se este não for um lançamento binário.workspace
: o caminho absoluto para o espaço de trabalho base. diretório.install_base
: o caminho absoluto para a instalação. da instância do Bazel usado pela instância do Bazel para o usuário atual. Júlio instala os executáveis internamente necessários abaixo desse diretório.output_base
: o caminho absoluto para a saída base. da instância do Bazel usado pela instância do Bazel para o usuário atual e de espaço de trabalho. O Bazel coloca todo o rascunho e o build abaixo desse diretório.execution_root
: o caminho absoluto para a execução. diretório raiz em output_base. Esse diretório é a raiz de todos os arquivos acessível aos comandos executados durante a compilação e é o tópico para esses comandos. Se o diretório do espaço de trabalho for gravável, uma link simbólico chamadobazel-<workspace>
está ali apontando para esse diretório.output_path
: o caminho absoluto para a saída. abaixo da raiz de execução usada para todos os arquivos geradas como resultado de comandos de build. Se o diretório do espaço de trabalho for gravável, um link simbólico com o nomebazel-out
é colocado lá apontando para este diretório.server_pid
: o ID do processo do servidor do Bazel. de desenvolvimento de software.server_log
: o caminho absoluto para o arquivo de registro de depuração do servidor do Bazel. Esse arquivo contém informações de depuração de todos os comandos durante o ciclo de vida do servidor do Bazel e é destinado ao consumo humano por desenvolvedores e usuários avançados do Bazel.command_log
: o caminho absoluto para o arquivo de registro do comando. contém os streams intercalados stdout e stderr dos mais recentes do Bazel. Observe que executarbazel info
substituirá o desse arquivo, já que ele se torna o comando mais recente do Bazel. No entanto, o local do arquivo de registro do comando não será alterado, a menos que você mude a configuração de--output_base
ou--output_user_root
opções.used-heap-size
,committed-heap-size
,max-heap-size
: informa vários tamanhos de heap da JVM. parâmetros. Respectivamente: memória usada no momento, memória está disponível para a JVM pelo sistema, possível alocação.gc-count
,gc-time
: a contagem cumulativa de coletas de lixo desde o início deste servidor Bazel e o tempo gasto para realizá-las. Esses valores não são redefinidos no início de cada ser construído.package_path
: uma lista separada por dois-pontos de caminhos que seriam procurou pacotes pelo Bazel. Tem o mesmo formato do Argumento de linha de comando de build--package_path
.
Exemplo: o ID do processo do servidor do Bazel.
% bazel info server_pid 1285
Dados específicos da configuração
Esses dados podem ser afetados pelas opções de configuração passadas
para bazel info
, por
exemplo --cpu
, --compilation_mode
,
etc. O comando info
aceita todas
as opções que controlam a dependência
uma vez que alguns deles determinam a localização
o 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óriosbazel-*
em que os programas gerados pelo build estão localizados. Isso geralmente é o mesmo que, embora não sempre, os links simbólicosbazel-*
criados no diretório base do espaço de trabalho após um build bem-sucedido. No entanto, se o diretório do espaço de trabalho for somente leitura, não é possível criar links simbólicos debazel-*
. Scripts que usam o valor relatado porbazel info
, em vez de presumir o existência do link simbólico será mais robusto.- O guia
"Marca" de código aberto. Se a sinalização
--show_make_env
for especificado, todas as variáveis no campo "Make" da configuração atual meio ambiente (comoCC
,GLIBC_VERSION
etc.) Essas são as variáveis acessadas usando o método$(CC)
ouvarref("CC")
dentro dos arquivos BUILD.
Exemplo: o compilador C++ da configuração atual.
Essa é a variável $(CC)
em "Make" meio ambiente
Portanto, a flag --show_make_env
é necessária.
% bazel info --show_make_env -c opt COMPILATION_MODE opt
Exemplo: o diretório de saída bazel-bin
para o
configuração do Terraform. Essa informação está correta mesmo nos casos em que
Por algum motivo, não é possível criar o link simbólico bazel-bin
.
por exemplo, ao compilar de um diretório somente leitura.
% bazel info --cpu=piii bazel-bin /var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/piii-opt/bin % bazel info --cpu=k8 bazel-bin /var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/k8-opt/bin
version
e --version
O comando "version" mostra os detalhes da versão do Bazel criado. binário, incluindo a lista de alterações em que ele foi criado e a data. Eles são especialmente úteis para determinar se você tem a versão o Bazel ou caso você esteja relatando bugs. Alguns dos valores interessantes são:
changelist
: a lista de alterações em que esta versão do O Bazel foi lançado.label
: o rótulo da versão deste Bazel. instância ou "versão de desenvolvimento" se este não for um lançamento binário. Muito útil ao informar bugs.
bazel --version
, sem outros argumentos, emitirá a mesma saída que
bazel version --gnu_format
, exceto sem o efeito colateral de possivelmente começar
um servidor Bazel ou descompactar o arquivo do servidor. bazel --version
pode ser executado a partir de
em qualquer lugar, pois não requer um diretório de espaço de trabalho.
mobile-install
O comando mobile-install
instala apps em dispositivos móveis.
No momento, só há suporte para dispositivos Android que executam o ART.
Consulte bazel mobile-install para ver mais informações.
As seguintes opções são compatíveis:
--incremental
Se definido, o Bazel tenta instalar o app de forma incremental, ou seja, apenas os usuários
partes que mudaram desde o último build. Não é possível atualizar os recursos
referenciado de AndroidManifest.xml
, código nativo ou Java
(como os referenciados por Class.getResource()
). Se essas
as coisas mudarem, essa opção deve ser omitida. Contra o espírito do Bazel
e, devido às limitações da plataforma Android, é a
responsabilidade do usuário de saber quando esse comando é bom o suficiente e
quando é necessário fazer uma instalação completa.
Se você usa um dispositivo com o Marshmallow ou uma versão mais recente, considere as
flag --split_apks
.
--split_apks
Define se os APKs divididos devem ser usados para instalar e atualizar o app no dispositivo.
Funciona apenas em dispositivos com a versão Marshmallow ou posterior. Observe que o
Sinalização --incremental
não é necessário 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 o depurador ser anexado antes de iniciar o app em um estado limpo após a instalação.
É equivalente a --start=DEBUG
.
--start=_start_type_
Como o app deve ser iniciado após a instalação. Os _start_type_s compatíveis são:
NO
Não inicia o app. Esse é o padrão.COLD
Inicia o app em um estado limpo após a instalação.WARM
Preserva e restaura o estado do aplicativo em instalações incrementais.DEBUG
aguarda o depurador antes de iniciar o app em um estado limpo depois de instalar.
--adb=path
Indica o binário adb
a ser usado.
O padrão é usar o adb no SDK do Android especificado por
--android_sdk
--adb_arg=serial
Argumentos extras para adb
. Eles vêm antes do subcomando na
linha de comando e normalmente são usados para especificar em qual dispositivo será instalado.
Por exemplo, para selecionar o dispositivo ou emulador Android que será usado:
% bazel mobile-install --adb_arg=-s --adb_arg=deadbeef
invoca adb
como
adb -s deadbeef install ...
--incremental_install_verbosity=number
O nível de detalhes da instalação incremental. Defina como 1 para que o registro de depuração seja impresso no console.
dump
O comando dump
é impresso em stdout um despejo do
interno do servidor Bazel. Esse comando é destinado
principalmente para uso de desenvolvedores do Bazel. Portanto, a saída desse comando
não é especificado e está sujeito a alterações.
Por padrão, o comando apenas imprime a mensagem de ajuda que descreve possíveis opções para despejar áreas específicas do estado do Bazel. Para despejar estado interno, é preciso especificar pelo menos uma das opções.
As seguintes opções são aceitas:
--action_cache
despeja o conteúdo do cache da ação.--packages
despeja o conteúdo do cache do pacote.--skyframe
faz o despejo de estado do gráfico de dependências interno do Bazel.--rules
faz o download do resumo de cada regra e classe de aspecto, incluindo contagens e contagens de ações. Isso inclui regras nativas e do Starlark. Se o rastreamento de memória estiver ativado, o tamanho consumo de memória também é mostrado.--skylark_memory
despeja um arquivo .gz compatível com pprof para o caminho especificado. É necessário ativar o rastreamento de memória para que isso funcione.
Monitoramento de memória
Alguns comandos dump
exigem rastreamento de memória. Para ativar, você precisa transmitir
sinalizações de inicialização para o Bazel:
--host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar
--host_jvm_args=-DRULE_MEMORY_TRACKER=1
O java-agent é verificado no Bazel em
third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar
, então
não se esqueça de ajustar $BAZEL
para o local em que o repositório do Bazel será armazenado.
Continue passando essas opções para o Bazel para cada comando, ou o servidor vai reiniciar.
Exemplo:
% bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \ --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \ build --nobuild <targets> # Dump rules % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \ --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \ dump --rules # Dump Starlark heap and analyze it with pprof % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \ --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \ dump --skylark_memory=$HOME/prof.gz % pprof -flame $HOME/prof.gz
analyze-profile
O comando analyze-profile
analisa uma
Perfil de trace JSON anterior
coletadas durante uma invocação do Bazel.
canonicalize-flags
O canonicalize-flags
que pega uma lista de opções para um comando do Bazel e retorna uma lista de
opções que têm o mesmo efeito. A nova lista de opções é canônica. Por exemplo:
duas listas de opções com o mesmo efeito são canonizadas na mesma lista nova.
A opção --for_command
pode ser usada para selecionar entre diferentes
comandos No momento, apenas build
e test
estão
suporte. As opções não aceitas pelo comando fornecido causam um erro.
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 do aplicativo máquina virtual usada pelo processo do servidor Bazel e elas se aplicam a todos comandos subsequentes processados por esse servidor. Se já existe servidor do Bazel em execução e as opções de inicialização não corresponderem, ele vai e será reiniciada.
Todas as opções descritas nesta seção devem ser especificadas usando o
--key=value
ou --key value
. Além disso, essas opções precisam aparecer antes do nome do Bazel
kubectl. Use startup --key=value
para listá-los em um arquivo .bazelrc
.
--output_base=dir
Esta opção requer um argumento de caminho, que deve especificar um gravável. O Bazel vai usar esse local para gravar todos os saída. A base de saída também é a chave pela qual o cliente localiza no servidor Bazel. Ao alterar a base de saída, você altera o servidor que vai processar o comando.
Por padrão, a base de saída é derivada do nome de login do usuário,
e o nome do diretório do espaço de trabalho (na verdade, o resumo MD5),
Assim, um valor típico será semelhante a este:
/var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e
:
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
o operador shell &
), cada um usando um código do Bazel diferente.
instância de servidor (por causa das diferentes bases de saída).
Por outro lado, se a base de saída padrão tiver sido usada nos dois comandos,
as duas solicitações seriam enviadas ao mesmo servidor,
em sequência, criando primeiro a //foo
e depois
por um build incremental de //bar
.
--output_user_root=dir
Aponta para o diretório raiz onde as bases de saída e instalação são criadas. O diretório não pode existir ou pertencer ao usuário que fez a chamada. Antes, ter permissão para apontar para um diretório compartilhado por vários usuários mas não são mais permitidos. Isso pode ser permitido uma vez O problema 11100 foi resolvido.
Se a opção --output_base
for especificada, ela vai substituir
usando --output_user_root
para calcular a base de saída.
O local da base instalada é calculado
--output_user_root
, além da identidade MD5 do Bazel incorporado
binários.
Use a opção --output_user_root
para escolher
local de base alternativo para todas as saídas do Bazel (base de instalação e saída
se houver um local melhor no layout do seu sistema de arquivos.
--server_javabase=dir
Especifica a máquina virtual Java em que o Bazel é executado. O valor precisa ser um caminho para diretório que contém um JDK ou JRE. Ele não deve ser um rótulo. Essa opção precisa aparecer antes de qualquer comando do Bazel, por exemplo:
% bazel --server_javabase=/usr/local/buildtools/java/jdk11 build //foo
Essa flag não afeta as JVMs usadas pelos subprocessos do Bazel, como aplicativos, testes ferramentas e assim por diante. Use as opções de build --javabase ou --host_javabase.
Essa sinalização era chamada anteriormente de --host_javabase
(às vezes chamada de
"lado esquerdo" --host_javabase
), mas foi renomeado para evitar confusão com o
de build --host_javabase (às vezes chamada de
"lado direito" --host_javabase
).
--host_jvm_args=string
Especifica uma opção de inicialização a ser transmitida para a máquina virtual Java em que o próprio Bazel é usado. é executado. Isso pode ser usado para definir o tamanho da pilha, por exemplo:
% bazel --host_jvm_args="-Xss256K" build //foo
Essa opção pode ser usada várias vezes com argumentos individuais. Observe que definir essa flag raramente será necessária. Também é possível transmitir uma lista de strings separada por espaços. cada um dos quais será interpretado como um argumento JVM separado, mas este recurso em breve será descontinuada.
Isso não afeta nenhuma JVMs usadas pelo
subprocessos do Bazel: aplicativos, testes, ferramentas etc. Para ser aprovado
Opções da JVM para programas Java executáveis, executados pelo bazel
run
ou na linha de comando, use
o argumento --jvm_flags
, que
todos os programas java_binary
e java_test
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 chamando o método principal do próprio Bazel. Isso ocorre principalmente destinado aos desenvolvedores do Bazel.
--autodetect_server_javabase
Essa opção faz com que o Bazel busque automaticamente um JDK instalado na inicialização.
e para voltar para o JRE instalado se o JRE incorporado não estiver disponível.
--explicit_server_javabase
pode ser usado para escolher um JRE explícito para
que executa o Bazel.
--batch
O modo em lote faz com que o Bazel não use a modo padrão de cliente/servidor, mas executa um Bazel java para um único comando, que foi usado em sistemas semântica com relação ao tratamento de sinais, controle de jobs e ambiente herança variável e é necessário para executar o Bazel em uma jail chroot.
O modo de lote mantém a semântica de filas adequada dentro da mesma output_base. Ou seja, as invocações simultâneas serão processadas em ordem, sem sobreposição. Se um Bazel no modo de lote for executado em um cliente com um servidor em execução, primeiro encerra o servidor antes de processar o comando.
O Bazel é executado mais lentamente no modo de lote ou com as alternativas descritas acima. Isso ocorre porque, entre outras coisas, o cache do arquivo de compilação é residente da memória e, portanto, não preservados entre as invocações em lote sequenciais. Portanto, usar o modo de lote é mais vantajoso nos casos em que o desempenho menos críticos, como builds contínuos.
--max_idle_secs=n
Essa opção especifica por quanto tempo, em segundos, o processo do servidor do Bazel
deve aguardar após a última solicitação do cliente antes que ela seja encerrada. A
o valor padrão é 10.800 (3 horas). --max_idle_secs=0
fará com que o
que o processo do servidor do Bazel persista indefinidamente;
Essa opção pode ser usada por scripts que invocam o Bazel para garantir que
eles não deixam processos do servidor do Bazel na máquina do usuário quando
não estaria em execução de outra forma.
Por exemplo, um script de pré-envio pode querer
invoque o bazel query
para garantir que as solicitações pendentes de um usuário
mudança não introduz dependências indesejadas. No entanto, se o
usuário não tiver feito uma versão recente nesse espaço de trabalho, seria
que o script de pré-envio inicie um servidor Bazel.
para que ele permaneça ocioso pelo resto do dia.
Ao especificar um valor pequeno de --max_idle_secs
no
solicitação de consulta, o script pode garantir que se ele causou uma nova
servidor seja iniciado, ele será encerrado imediatamente, mas se ao contrário
já havia um servidor em execução, ele continuará em execução
até ficar inativo pelo tempo normal. Obviamente, o modelo
o timer de inatividade do servidor será redefinido.
--[no]shutdown_on_low_sys_mem
Se ativada e --max_idle_secs
estiver definida com uma duração positiva,
Depois que o servidor de compilação estiver ocioso por um tempo, encerre-o quando o sistema estiver
com pouca memória. Somente no Linux.
Além de executar uma verificação de inatividade correspondente a max_idle_secs, o servidor de build também começa a monitorar a memória disponível do sistema depois que o servidor fica ocioso por algum tempo. Se a memória disponível do sistema ficar criticamente baixa, o servidor será fechado.
--[no]block_for_lock
Se ativado, o Bazel aguardará outros comandos que contenham a que o bloqueio do servidor seja concluído antes de progredir. Se desativada, o Bazel vai sairá com erro se não puder adquirir o bloqueio imediatamente e continuar.
Os desenvolvedores podem usar isso nas verificações de pré-envio para evitar esperas longas causadas por outro comando do Bazel no mesmo cliente.
--io_nice_level=n
Define um nível de 0 a 7 para a programação de E/S de melhor esforço. 0 é a prioridade mais alta, 7 é o menor. O programador previsto só pode honrar até a prioridade 4. Valores negativos são ignorados.
--batch_cpu_scheduling
Usar a programação de CPU batch
para o Bazel. Esta política é útil para
cargas de trabalho não interativas, mas que não querem reduzir seu valor adequado.
Consulte "man 2 sched_setscheduler". Esta política pode oferecer uma estrutura que torne o sistema
interatividade, em detrimento da capacidade de processamento do Bazel.
Opções diversas
--[no]announce_rc
Controla se o Bazel anuncia as opções de comando lidas no arquivo do Bazel quando inicializando. As opções de inicialização são anunciadas incondicionalmente.
--color (yes|no|auto)
Esta opção determina se o Bazel vai usar cores para destacar a saída dele na tela.
Se esta opção for definida como yes
, a saída de cor será ativada.
Se esta opção for definida como auto
, o Bazel vai usar a saída de cor somente se
a saída está sendo enviada para um terminal e a variável de ambiente TERM
for definido como um valor diferente de dumb
, emacs
ou xterm-mono
.
Se esta opção for definida como no
, a saída de cor será desativada.
com ou sem destino a um terminal ou terminal.
da configuração da variável de ambiente TERM.
--config=name
Seleciona a seção de configuração adicional de
os arquivos rc; para o command
atual,
ele também extrai as opções de command:name
se essa seção existir. Pode ser
especificados várias vezes para adicionar sinalizações de várias seções de configuração. Expansões podem se referir a outras
(por exemplo, as expansões podem ser encadeadas).
--curses (yes|no|auto)
Esta opção determina se o Bazel vai usar controles de cursor.
na saída da tela. Isso resulta em menos dados de rolagem
stream de saída compacto e fácil de ler do Bazel. Isso funciona bem com
--color
:
Se esta opção for definida como yes
, o uso dos controles do cursor será ativado.
Se esta opção for definida como no
, o uso dos controles do cursor será desativado.
Se esta opção for definida como auto
, o uso dos controles do cursor será
ativado nas mesmas condições que em --color=auto
.
--[no]show_timestamps
Se especificado, um carimbo de data/hora é adicionado a cada mensagem gerada pelo Bazel especificando o horário em que a mensagem foi exibida.