bazel [<startup options>] <command> [<args>]
bazel [<startup options>] <command> [<args>] -- [<target patterns>]
Sintaxe da opção
As opções podem ser transmitidas ao Bazel de diferentes maneiras. As opções que exigem um valor podem ser transmitidas com um sinal de igual ou um espaço:
--<option>=<value> --<option> <value>
-<short_form> <value>
As opções booleanas podem ser ativadas da seguinte maneira:
--<option> --<option>=[true|yes|1]
--no<option> --<option>=[false|no|0]
As opções de três estados geralmente são definidas como automáticas por padrão e podem ser ativadas à força da seguinte maneira:
--<option>=[true|yes|1]
--no<option> --<option>=[false|no|0]
Comandos
aquery |
Analisa os destinos especificados e consulta o gráfico de ações. |
build |
Cria os destinos especificados. |
canonicalize-flags |
Canonicaliza uma lista de opções do Bazel. |
clean |
Remove arquivos de saída e, opcionalmente, para o servidor. |
coverage |
Gera um relatório de cobertura de código para os destinos de teste especificados. |
cquery |
Carrega, analisa e consulta os destinos especificados com configurações. |
dump |
Despeja o estado interno do processo do servidor bazel. |
fetch |
Busca repositórios externos que são pré-requisitos para os destinos. |
help |
Imprime ajuda para comandos ou o índice. |
info |
Mostra informações de tempo de execução sobre o servidor do Bazel. |
license |
Imprime a licença deste software. |
mobile-install |
Instalações segmentadas para dispositivos móveis. |
mod |
Consulta o gráfico de dependência externa do Bzlmod. |
print_action |
Imprime os argumentos da linha de comando para compilar um arquivo. |
query |
Executa uma consulta de gráfico de dependência. |
run |
Executa o destino especificado. |
shutdown |
Para o servidor do Bazel. |
test |
Cria e executa os destinos de teste especificados. |
vendor |
Busca repositórios externos em uma pasta especificada pela flag --vendor_dir. |
version |
Imprime informações da versão do bazel. |
Opções de startup
- Opções que aparecem antes do comando e são analisadas pelo cliente:
--[no]autodetect_server_javabasepadrão: "true"-
Quando --noautodetect_server_javabase é transmitido, o Bazel não volta para o JDK local para executar o servidor do Bazel e, em vez disso, sai.
--[no]batchpadrão: "false"-
Se definido, o Bazel será executado apenas como um processo de cliente sem um servidor, em vez do modo cliente/servidor padrão. Esse recurso está descontinuado e será removido. Se quiser evitar servidores persistentes, prefira desligar o servidor explicitamente.
Tags:
loses_incremental_state,bazel_internal_configuration,deprecated --[no]batch_cpu_schedulingpadrão: "false"-
Somente no Linux. Use o agendamento de CPU "em lote" para o Blaze. Essa política é útil para cargas de trabalho não interativas que não querem diminuir o valor nice. Consulte "man 2 sched_setscheduler". Se for "false", o Bazel não vai fazer uma chamada de sistema.
--bazelrc=<path>vários usos são acumulados-
O local do arquivo .bazelrc do usuário que contém os valores padrão das opções do Bazel. /dev/null indica que todos os
--bazelrcs futuros serão ignorados, o que é útil para desativar a pesquisa de um arquivo rc do usuário, por exemplo, em builds de lançamento. Essa opção também pode ser especificada várias vezes. Por exemplo, com--bazelrc=x.rc --bazelrc=y.rc --bazelrc=/dev/null --bazelrc=z.rc,- x.rc e y.rc são lidos.
- z.rc é ignorado devido ao /dev/null anterior. Se não for especificado, o Bazel usará o primeiro arquivo .bazelrc encontrado nos seguintes locais: o diretório do espaço de trabalho e o diretório inicial do usuário. Observação: as opções de linha de comando sempre substituem qualquer opção em bazelrc.
Tags:
changes_inputs --[no]block_for_lockpadrão: "true"-
Quando --noblock_for_lock é transmitido, o Bazel não aguarda a conclusão de um comando em execução, mas sai imediatamente.
Tags:
eagerness_to_exit --[no]client_debugpadrão: "false"-
Se verdadeiro, registra informações de depuração do cliente em stderr. Mudar essa opção não vai reiniciar o servidor.
Tags:
affects_outputs,bazel_monitoring --connect_timeout_secs=<an integer>padrão: "30"-
O tempo que o cliente espera em cada tentativa de conexão com o servidor
--digest_function=<hash function>padrão: consulte a descrição-
A função de hash a ser usada ao calcular resumos de arquivos.
--experimental_cgroup_parent=<path>padrão: consulte a descrição-
O cgroup em que o servidor bazel será iniciado como um caminho absoluto. O processo do servidor será iniciado no cgroup especificado para cada controlador compatível. Por exemplo, se o valor dessa flag for /build/bazel e os controladores de CPU e memória estiverem montados respectivamente em /sys/fs/cgroup/cpu e /sys/fs/cgroup/memory, o servidor será iniciado nos cgroups /sys/fs/cgroup/cpu/build/bazel e /sys/fs/cgroup/memory/build/bazel.Não é um erro se o cgroup especificado não puder ser gravado para um ou mais controladores. Essa opção não tem efeito em plataformas que não oferecem suporte a cgroups.
Tags:
bazel_monitoring,execution --[no]experimental_run_in_user_cgrouppadrão: "false"-
Se for verdadeiro, o servidor Bazel será executado com systemd-run, e o usuário será o proprietário do cgroup. Essa flag só tem efeito no Linux.
Tags:
bazel_monitoring,execution --failure_detail_out=<path>padrão: consulte a descrição-
Se definido, especifica um local para gravar uma mensagem protobuf failure_detail se o servidor apresentar uma falha e não puder informar isso via gRPC, como de costume. Caso contrário, o local será ${OUTPUT_BASE}/failure_detail.rawproto.
--[no]home_rcpadrão: "true"-
Se é necessário procurar o arquivo bazelrc inicial em $HOME/.bazelrc.
Tags:
changes_inputs --[no]idle_server_taskspadrão: "true"-
Executar System.gc() quando o servidor estiver inativo
Tags:
loses_incremental_state,host_machine_resource_optimizations --[no]ignore_all_rc_filespadrão: "false"-
Desativa todos os arquivos rc, independente dos valores de outras flags que modificam o rc, mesmo que essas flags apareçam depois na lista de opções de inicialização.
Tags:
changes_inputs --io_nice_level={-1,0,1,2,3,4,5,6,7}padrão: "-1"-
Apenas no Linux. Defina um nível de 0 a 7 para o melhor esforço de programação de E/S usando a chamada de sistema sys_ioprio_set. 0 é a prioridade mais alta, e 7 é a mais baixa. O programador antecipado só pode honrar até a prioridade 4. Se definido como um valor negativo, o Bazel não vai realizar uma chamada de sistema.
- Padrão de
--local_startup_timeout_secs=<an integer>: "120" -
O tempo máximo que o cliente espera para se conectar ao servidor.
--macos_qos_class=<a string>padrão: "default"-
Define a classe de serviço de QoS do servidor bazel ao executar no macOS. Essa flag não tem efeito em todas as outras plataformas, mas é compatível para garantir que os arquivos rc possam ser compartilhados entre elas sem mudanças. Os valores possíveis são: user-interactive, user-initiated, default, utility e background.
--max_idle_secs=<integer>padrão: "10800"-
O número de segundos que o servidor de build vai aguardar em inatividade antes de ser desligado. Zero significa que o servidor nunca será desligado. Essa opção só é lida na inicialização do servidor. Mudar essa opção não vai reiniciar o servidor.
--output_base=<path>padrão: consulte a descrição-
Se definido, especifica o local de saída em que toda a saída do build será gravada. Caso contrário, o local será ${OUTPUT_ROOT}/blaze${USER}/${MD5_OF_WORKSPACE_ROOT}. Observação: se você especificar uma opção diferente de uma invocação do Bazel para a próxima, provavelmente vai iniciar um novo servidor do Bazel adicional. O Bazel inicia exatamente um servidor por base de saída especificada. Normalmente, há uma base de saída por espaço de trabalho. No entanto, com essa opção, é possível ter várias bases de saída por espaço de trabalho e, assim, executar várias builds para o mesmo cliente na mesma máquina simultaneamente. Consulte "bazel help shutdown" para saber como encerrar um servidor do Bazel.
--output_user_root=<path>padrão: consulte a descrição-
O diretório específico do usuário em que todas as saídas de build são gravadas. Por padrão, é uma função de $USER, mas, ao especificar uma constante, as saídas de build podem ser compartilhadas entre usuários colaboradores.
--[no]preemptiblepadrão: "false"-
Se for "true", o comando poderá ser substituído se outro comando for iniciado.
Tags:
eagerness_to_exit --[no]quietpadrão: "false"-
Se for "true", nenhuma mensagem informativa será emitida no console, apenas erros. Mudar essa opção não vai reiniciar o servidor.
Tags:
affects_outputs,bazel_monitoring --server_jvm_out=<path>padrão: consulte a descrição-
O local para gravar a saída da JVM do servidor. Se não estiver definido, o padrão será um local em output_base.
--[no]shutdown_on_low_sys_mempadrão: "false"-
Se max_idle_secs estiver definido e o servidor de build estiver ocioso há algum tempo, desligue o servidor quando o sistema estiver com pouca RAM livre. Apenas para Linux e macOS.
--[no]system_rcpadrão: "true"-
Indica se é necessário procurar o bazelrc em todo o sistema.
Tags:
changes_inputs --[no]unlimit_coredumpspadrão: "false"-
Aumenta o limite de soft coredump para o limite máximo, permitindo coredumps do servidor (incluindo a JVM) e do cliente em condições comuns. Coloque essa flag no seu bazelrc uma vez e esqueça dela para receber coredumps quando encontrar uma condição que os acione.
--[no]windows_enable_symlinkspadrão: "false"-
Se for "true", links simbólicos reais serão criados no Windows em vez de cópias de arquivos. É necessário ativar o modo de desenvolvedor do Windows e ter o Windows 10 versão 1703 ou mais recente.
--[no]workspace_rcpadrão: "true"-
Se é necessário procurar o arquivo bazelrc do espaço de trabalho em $workspace/.bazelrc
Tags:
changes_inputs
- Opções diversas, não categorizadas de outra forma:
--host_jvm_args=<jvm_arg>vários usos são acumulados-
Flags a serem transmitidas para a JVM que executa o Blaze.
--host_jvm_debug-
Opção conveniente para adicionar algumas flags de inicialização da JVM, que fazem com que a JVM aguarde durante a inicialização até que você se conecte de um depurador compatível com JDWP (como o Eclipse) à porta 5005.
Expande para:
--host_jvm_args=-agentlib:jdwp=transport=dt_socket,server=y,address=5005 --server_javabase=<jvm path>padrão: ""-
Caminho para a JVM usada para executar o próprio Bazel.
Opções comuns a todos os comandos
- Opções que aparecem antes do comando e são analisadas pelo cliente:
--distdir=<a path>vários usos são acumulados-
Outros lugares para procurar arquivos antes de acessar a rede para fazer o download.
--[no]experimental_repository_cache_hardlinkspadrão: "false"-
Se definido, o cache do repositório vai criar um hardlink do arquivo em caso de acerto de cache, em vez de copiar. Isso serve para economizar espaço em disco.
- Padrão de
--experimental_repository_downloader_retries=<an integer>: "5" -
O número máximo de tentativas para repetir um erro de download. Se definido como 0, as novas tentativas serão desativadas.
Tags:
experimental - Padrão de
--experimental_scale_timeouts=<a double>: "1.0" -
Escala todos os tempos limite nas regras do repositório Starlark por esse fator. Dessa forma, os repositórios externos podem funcionar em máquinas mais lentas do que o esperado pelo autor da regra, sem mudar o código-fonte.
- Padrão de
--http_connector_attempts=<an integer>: "8" -
O número máximo de tentativas para downloads HTTP.
--http_connector_retry_max_timeout=<An immutable length of time.>padrão: "0s"-
O tempo limite máximo para novas tentativas de download HTTP. Com um valor de 0, nenhum tempo limite máximo é definido.
- Padrão de
--http_max_parallel_downloads=<an integer>: "8" -
O número máximo de downloads HTTP paralelos.
- Padrão de
--http_timeout_scaling=<a double>: "1.0" -
Ajusta todos os tempos limite relacionados a downloads HTTP pelo fator especificado.
--repo_contents_cache=<a path>padrão: consulte a descrição-
Especifica o local do cache de conteúdo do repositório, que contém diretórios buscados compartilháveis entre espaços de trabalho. Uma string vazia como argumento solicita que o cache de conteúdo do repositório seja desativado. Caso contrário, o padrão "<--repository_cache>/contents" será usado. Isso significa que definir "--repository_cache=" desativa por padrão o cache de conteúdo do repositório, a menos que "--repo_contents_cache=<some_path>" também esteja definido.
--repo_contents_cache_gc_idle_delay=<An immutable length of time.>padrão: "5m"-
Especifica o tempo que o servidor precisa ficar inativo antes que a coleta de lixo aconteça no cache de conteúdo do repositório.
- Padrão de
--repo_contents_cache_gc_max_age=<An immutable length of time.>: "14d" -
Especifica o tempo que uma entrada no cache de conteúdo do repositório pode ficar sem uso antes de ser coletada como lixo. Se definido como zero, apenas entradas duplicadas serão coletadas como lixo.
--repository_cache=<a path>padrão: consulte a descrição-
Especifica o local do cache dos valores baixados obtidos durante a busca de repositórios externos. Uma string vazia como argumento solicita que o cache seja desativado. Caso contrário, o padrão "<--output_user_root>/cache/repos/v1" será usado.
--[no]repository_disable_downloadpadrão: "false"-
Se definido, o download usando ctx.download{,_and_extract} não será permitido durante a busca do repositório. O acesso à rede não é completamente desativado. ctx.execute ainda pode executar um executável arbitrário que acessa a Internet.
- Opções que controlam a execução do build:
--experimental_ui_max_stdouterr_bytes=<an integer in (-1)-1073741819 range>padrão: "1048576"-
O tamanho máximo dos arquivos stdout / stderr que serão impressos no console. -1 significa que não há limite.
Tags:
execution - Padrão de
--gc_churning_threshold=<an integer in 0-100 range>: "100" -
A qualquer momento depois que uma invocação estiver em execução por pelo menos um minuto, se o Blaze tiver gasto pelo menos essa porcentagem do tempo real da invocação fazendo GCs completos, ele vai desistir e falhar com um OOM. Um valor de 100 significa nunca desistir por esse motivo.
--gc_churning_threshold_if_multiple_top_level_targets=<an integer>padrão: "-1"-
Se definido como um valor em [0, 100] e for um comando que usa destinos de nível superior (por exemplo, build, mas não query) e houver vários destinos de nível superior, vai substituir --gc_churning_threshold. Útil para configurar um comportamento de OOMing mais agressivo (ou seja, um valor menor que --gc_churning_threshold) quando há vários destinos de nível superior. Assim, o invocador do Bazel pode dividir e tentar novamente, mas ainda ter um comportamento menos agressivo quando há um único destino de nível superior.
- Padrão de
--gc_thrashing_threshold=<an integer in 0-100 range>: "100" -
A porcentagem de espaço permanente ocupado (0 a 100) acima da qual o GcThrashingDetector considera eventos de pressão de memória em relação aos limites dele (--gc_thrashing_limits). Se definido como 100, o GcThrashingDetector será desativado.
- Opções que configuram o conjunto de ferramentas usado para a execução de ações:
--[no]incompatible_enable_proto_toolchain_resolutionpadrão: "false"-
Se for verdadeiro, as regras de linguagem proto vão definir toolchains do repositório protobuf.
- Opções que permitem ao usuário configurar a saída pretendida, afetando o valor dela, e não a existência:
--bep_maximum_open_remote_upload_files=<an integer>padrão: "-1"-
Número máximo de arquivos abertos permitidos durante o upload de artefatos do BEP.
Tags:
affects_outputs --remote_download_all-
Baixa todas as saídas remotas para a máquina local. Essa flag é um alias de --remote_download_outputs=all.
Expande para:
--remote_download_outputs=allTags:
affects_outputs --remote_download_minimal-
Não faz o download de nenhuma saída de build remoto para a máquina local. Essa flag é um alias para --remote_download_outputs=minimal.
Expande para:
--remote_download_outputs=minimalTags:
affects_outputs --remote_download_outputs=<all, minimal or toplevel>padrão: "toplevel"-
Se definido como "minimal", não faz o download de nenhuma saída de build remoto para a máquina local, exceto as necessárias para ações locais. Se definido como "toplevel", se comporta como "minimal", exceto que também baixa saídas de destinos de nível superior para a máquina local. As duas opções podem reduzir significativamente os tempos de build se a largura de banda da rede for um gargalo.
Tags:
affects_outputs --remote_download_symlink_template=<a string>padrão: ""-
Em vez de baixar saídas de build remoto para a máquina local, crie links simbólicos. O destino dos links simbólicos pode ser especificado na forma de uma string de modelo. Essa string de modelo pode conter {hash} e {size_bytes}, que são expandidos para o hash do objeto e o tamanho em bytes, respectivamente. Esses links simbólicos podem, por exemplo, apontar para um sistema de arquivos FUSE que carrega objetos do CAS sob demanda.
Tags:
affects_outputs --remote_download_toplevel-
Faz o download apenas das saídas remotas das metas de nível superior para a máquina local. Essa flag é um alias de --remote_download_outputs=toplevel.
Expande para:
--remote_download_outputs=toplevelTags:
affects_outputs --repo_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable>vários usos são acumulados-
Especifica variáveis de ambiente adicionais que estarão disponíveis apenas para regras de repositório. As regras do repositório veem o ambiente completo de qualquer maneira, mas, dessa forma, as variáveis podem ser definidas usando flags de linha de comando e entradas <code>.bazelrc</code>. A sintaxe especial <code>=NAME</code> pode ser usada para remover explicitamente uma variável.
Tags:
action_command_lines
- Opções que afetam a rigidez com que o Bazel aplica entradas de build válidas (definições de regras, combinações de flags etc.):
--[no]allow_experimental_loadspadrão: "false"-
Se ativada, emita apenas um aviso em vez de um erro para carregamentos de .bzls experimentais.
Tags:
build_file_semantics --[no]check_bzl_visibilitypadrão: "true"-
Se desativada, os erros de visibilidade de carga .bzl serão rebaixados para avisos.
Tags:
build_file_semantics --[no]incompatible_enforce_starlark_utf8padrão: "warning"-
Se ativada (ou definida como "error"), falhará se os arquivos Starlark não estiverem codificados em UTF-8. Se definido como "warning", emita um aviso. Se definido como "off", o Bazel vai presumir que os arquivos Starlark estão codificados em UTF-8, mas não vai verificar essa presunção. Arquivos Starlark que não estão codificados em UTF-8 podem fazer com que o Bazel se comporte de maneira inconsistente.
- Essa opção afeta a semântica da linguagem Starlark ou a API de build acessível a arquivos BUILD, .bzl ou WORKSPACE.:
--[no]experimental_bzl_visibilitypadrão: "true"-
Se ativada, adiciona uma função
visibility()que os arquivos .bzl podem chamar durante a avaliação de nível superior para definir a visibilidade deles com o objetivo de instruções load().Tags:
loading_and_analysis,experimental -
Se definido como "true", os atributos da regra e os métodos da API Starlark necessários para a regra "cc_shared_library" estarão disponíveis.
Tags:
build_file_semantics,loading_and_analysis,experimental --[no]experimental_disable_external_packagepadrão: "false"-
Se definido como "true", o pacote //external gerado automaticamente não estará mais disponível. O Bazel ainda não vai conseguir analisar o arquivo "external/BUILD", mas os globs que chegam a external/ do pacote sem nome vão funcionar.
Tags:
loading_and_analysis,loses_incremental_state,experimental --[no]experimental_dormant_depspadrão: "false"-
Se definido como verdadeiro, attr.label(materializer=), attr(for_dependency_resolution=), attr.dormant_label(), attr.dormant_label_list() e rule(for_dependency_resolution=) serão permitidos.
Tags:
build_file_semantics,experimental --[no]experimental_enable_android_migration_apispadrão: "false"-
Se definido como "true", ativa as APIs necessárias para oferecer suporte à migração do Android Starlark.
Tags:
build_file_semantics --[no]experimental_enable_first_class_macrospadrão: "true"-
Se definido como verdadeiro, ativa a construção
macro()para definir macros simbólicas.Tags:
build_file_semantics --[no]experimental_enable_scl_dialectpadrão: "true"-
Se definido como verdadeiro, os arquivos .scl poderão ser usados em instruções load().
Tags:
build_file_semantics --[no]experimental_enable_starlark_setpadrão: "true"-
Se for verdadeiro, vai ativar o tipo de dados set e o construtor set() no Starlark.
Tags:
build_file_semantics,experimental --[no]experimental_google_legacy_apipadrão: "false"-
Se definido como "true", expõe várias partes experimentais da API de build do Starlark relacionadas ao código legado do Google.
Tags:
loading_and_analysis,experimental --[no]experimental_isolated_extension_usagespadrão: "false"-
Se for "true", vai ativar o parâmetro <code>isolate</code> na função <a href="https://bazel.build/rules/lib/globals/module#use_extension"><code>use_extension</code></a>.
Tags:
loading_and_analysis --[no]experimental_platforms_apipadrão: "false"-
Se definido como "true", ativa várias APIs do Starlark relacionadas à plataforma, úteis para depuração.
Tags:
loading_and_analysis,experimental --[no]experimental_repo_remote_execpadrão: "false"-
Se definido como verdadeiro, repository_rule vai ganhar alguns recursos de execução remota.
Tags:
build_file_semantics,loading_and_analysis,experimental --[no]experimental_repository_ctx_execute_wasmpadrão: "false"-
Se for "true", vai ativar os métodos repository_ctx
load_wasmeexecute_wasm.Tags:
loading_and_analysis,experimental --[no]experimental_sibling_repository_layoutpadrão: "false"-
Se definido como "true", os repositórios não principais serão inseridos como symlinks no repositório principal na raiz de execução. Ou seja, todos os repositórios são filhos diretos do diretório $output_base/execution_root. Isso tem o efeito colateral de liberar $output_base/execution_root/main/external para o diretório "external" de nível superior real.
Tags:
action_command_lines,bazel_internal_configuration,loading_and_analysis,loses_incremental_state,experimental --[no]experimental_single_package_toolchain_bindingpadrão: "false"-
Se ativada, a função register_toolchain não poderá incluir padrões de destino que se referem a mais de um pacote.
--[no]experimental_starlark_typespadrão: "false"-
Ativa as anotações e a verificação de tipos. Os locais em que as anotações são permitidas são controlados por
--experimental_starlark_types_allowed_paths.Tags:
loading_and_analysis,experimental --experimental_starlark_types_allowed_paths=<comma-separated list of options>padrão: ""-
Lista de prefixos de rótulo canônicos em que as anotações de tipo Starlark são permitidas.
Tags:
loading_and_analysis,experimental -
Se definido como verdadeiro, as tags serão propagadas de um destino para os requisitos de execução das ações. Caso contrário, as tags não serão propagadas. Consulte https://github.com/bazelbuild/bazel/issues/8830 para mais detalhes.
Tags:
build_file_semantics,experimental --[no]incompatible_always_check_depset_elementspadrão: "true"-
Verifique a validade dos elementos adicionados aos depsets em todos os construtores. Os elementos precisam ser imutáveis, mas historicamente o construtor depset(direct=...) se esqueceu de verificar. Use tuplas em vez de listas nos elementos de depset. Consulte https://github.com/bazelbuild/bazel/issues/10313 para mais detalhes.
--incompatible_autoload_externally=<comma-separated set of options>padrão: "+@rules_cc"-
Uma lista separada por vírgulas de regras (ou outros símbolos) que faziam parte do Bazel e agora precisam ser recuperadas dos respectivos repositórios externos. Essa flag foi criada para facilitar a migração de regras do Bazel. Consulte também https://github.com/bazelbuild/bazel/issues/23043. Um símbolo que é carregado automaticamente em um arquivo se comporta como se a definição integrada ao Bazel fosse substituída pela nova definição canônica em um repositório externo. Para um arquivo BUILD, isso significa adicionar implicitamente uma instrução load(). Para um arquivo .bzl, é uma instrução load() ou uma mudança em um campo do objeto
native, dependendo se o símbolo carregado automaticamente é uma regra. O Bazel mantém uma lista codificada de todos os símbolos que podem ser carregados automaticamente. Somente esses símbolos podem aparecer nessa flag. Para cada símbolo, o Bazel sabe o novo local de definição em um repositório externo, bem como um conjunto de repositórios com tratamento especial que não podem ser carregados automaticamente para evitar a criação de ciclos. Um item de lista "+foo" nessa flag faz com que o símbolo foo seja carregado automaticamente, exceto nos repositórios isentos de foo, em que a versão definida pelo Bazel de foo ainda está disponível. Um item de lista "foo" aciona o carregamento automático como acima, mas a versão de foo definida pelo Bazel não é disponibilizada para os repositórios excluídos. Isso garante que o repositório externo de foo não dependa da implementação antiga do Bazel de foo. Um item de lista "-foo" não aciona nenhum carregamento automático, mas torna a versão de foo definida pelo Bazel inacessível em todo o espaço de trabalho. Usado para validar se o espaço de trabalho está pronto para que a definição de foo seja excluída do Bazel. Se um símbolo não for nomeado nessa flag, ele vai continuar funcionando normalmente. Nenhum carregamento automático será feito, nem a versão definida pelo Bazel será suprimida. Para configuração, consulte https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/packages/AutoloadSymbols.java. Como um atalho, todo o repositório também pode ser usado. Por exemplo, +@rules_python vai carregar automaticamente todas as regras do Python.Tags:
loses_incremental_state,build_file_semantics,incompatible_change --[no]incompatible_disable_autoloads_in_main_repopadrão: "true"-
Controla se os carregamentos automáticos (definidos por --incompatible_autoload_externally) estão ativados no repositório principal. Quando ativadas, as regras (ou outros símbolos) que faziam parte do Bazel precisam ter instruções de carregamento. Use o buildifier para adicioná-los.
--[no]incompatible_disable_objc_library_transitionpadrão: "true"-
Desative a transição personalizada de objc_library e herde do destino de nível superior (sem operação no Bazel).
--[no]incompatible_disable_starlark_host_transitionspadrão: "false"-
Se definido como verdadeiro, os atributos de regra não poderão definir "cfg = "host"". As regras precisam definir "cfg = "exec"".
--[no]incompatible_disable_target_default_provider_fieldspadrão: "false"-
Se definido como "true", desativa a capacidade de usar o provedor padrão pela sintaxe de campo. Use a sintaxe de chave do provedor. Por exemplo, em vez de usar
ctx.attr.dep.filespara acessarfiles, use "ctx.attr.dep[DefaultInfo].files". Consulte https://github.com/bazelbuild/bazel/issues/9014 para mais detalhes. --incompatible_disable_transitions_on=<comma-separated set of options>padrão: ""-
Uma lista separada por vírgulas de flags que não podem ser usadas em entradas ou saídas de transições.
Tags:
loading_and_analysis,incompatible_change,non_configurable --[no]incompatible_disallow_ctx_resolve_toolspadrão: "true"-
Se definido como "true", a chamada da API ctx.resolve_tools descontinuada sempre vai falhar. Os usos dessa API precisam ser substituídos por um argumento executável ou de ferramentas para ctx.actions.run ou ctx.actions.run_shell.
--[no]incompatible_disallow_empty_globpadrão: "true"-
Se definido como "true", o valor padrão do argumento
allow_emptyde glob() será "False". --[no]incompatible_enable_deprecated_label_apispadrão: "true"-
Se ativada, algumas APIs descontinuadas (native.repository_name, Label.workspace_name, Label.relative) poderão ser usadas.
Tags:
loading_and_analysis --[no]incompatible_fail_on_unknown_attributespadrão: "true"-
Se ativado, os destinos com atributos desconhecidos definidos como "None" vão falhar.
--[no]incompatible_fix_package_group_reporoot_syntaxpadrão: "true"-
No atributo
packagesde package_group, muda o significado do valor "//..." para se referir a todos os pacotes no repositório atual em vez de todos os pacotes em qualquer repositório. Você pode usar o valor especial "public" no lugar de "//..." para manter o comportamento antigo. Essa flag exige que --incompatible_package_group_has_public_syntax também esteja ativada. --[no]incompatible_locations_prefers_executablepadrão: "true"-
Se um destino que fornece um executável se expande para o executável em vez dos arquivos em <code>DefaultInfo.files</code> na expansão $(locations ...) se o número de arquivos não for 1.
--[no]incompatible_no_attr_licensepadrão: "true"-
Se definido como "true", desativa a função
attr.license. --[no]incompatible_no_implicit_file_exportpadrão: "false"-
Se definido, os arquivos de origem (usados) serão particulares do pacote, a menos que sejam exportados explicitamente. Consulte https://github.com/bazelbuild/proposals/blob/master/designs/2019-10-24-file-visibility.md
--[no]incompatible_no_implicit_watch_labelpadrão: "true"-
Se for "true", os métodos em <code>repository_ctx</code> que recebem um rótulo não vão mais monitorar automaticamente o arquivo com esse rótulo em busca de mudanças, mesmo que <code>watch = "no"</code>, e <code>repository_ctx.path</code> não vai mais fazer com que o caminho retornado seja monitorado. Use <code>repository_ctx.watch</code>.
--[no]incompatible_no_rule_outputs_parampadrão: "false"-
Se definido como verdadeiro, desativa o parâmetro
outputsda funçãorule()do Starlark. --[no]incompatible_package_group_has_public_syntaxpadrão: "true"-
No atributo
packagesde "package_group", permite escrever "public" ou "private" para se referir a todos os pacotes ou a nenhum pacote, respectivamente. --[no]incompatible_resolve_select_keys_eagerlypadrão: "false"-
Se ativadas, as chaves de string em dicts transmitidas para select() em arquivos .bzl serão resolvidas imediatamente para rótulos relativos ao arquivo, em vez de serem interpretadas em relação ao arquivo BUILD de onde são carregadas.
--[no]incompatible_run_shell_command_stringpadrão: "true"-
Se definido como "true", o parâmetro de comando de "actions.run_shell" aceitará apenas strings.
--[no]incompatible_simplify_unconditional_selects_in_rule_attrspadrão: "true"-
Se for verdadeiro, simplifique os atributos de regra configuráveis que contêm apenas seleções incondicionais. Por exemplo, se ["a"] + select("//conditions:default", ["b"]) for atribuído a um atributo de regra, ele será armazenado como ["a", "b"]. Essa opção não afeta os atributos de macros simbólicas nem os valores padrão de atributos.
--[no]incompatible_stop_exporting_build_file_pathpadrão: "false"-
Se definido como verdadeiro, o ctx.build_file_path descontinuado não estará disponível. Em vez disso, use ctx.label.package + '/BUILD'.
--[no]incompatible_stop_exporting_language_modulespadrão: "false"-
Se ativados, alguns módulos específicos de idioma (como
cc_common) não ficam disponíveis nos arquivos .bzl do usuário e só podem ser chamados dos respectivos repositórios de regras. --[no]incompatible_unambiguous_label_stringificationpadrão: "true"-
Quando for verdadeiro, o Bazel vai transformar a string do rótulo @//foo:bar em @//foo:bar, em vez de //foo:bar. Isso afeta apenas o comportamento de str(), o operador % e assim por diante. O comportamento de repr() não muda. Para mais informações, consulte https://github.com/bazelbuild/bazel/issues/15916.
--[no]incompatible_use_cc_configure_from_rules_ccpadrão: "false"-
Quando for verdadeiro, o Bazel não vai mais permitir o uso de cc_configure em @bazel_tools. Consulte https://github.com/bazelbuild/bazel/issues/10134 para mais detalhes e instruções de migração.
--max_computation_steps=<a long integer>padrão: "0"-
O número máximo de etapas de computação do Starlark que podem ser executadas por um arquivo BUILD (zero significa sem limite).
Tags:
build_file_semantics --nested_set_depth_limit=<an integer>padrão: "3500"-
A profundidade máxima do gráfico interno a um depset (também conhecido como NestedSet), acima da qual o construtor de depset() vai falhar.
Tags:
loading_and_analysis --repositories_without_autoloads=<comma-separated set of options>padrão: ""-
Uma lista de repositórios adicionais (além dos codificados que o Bazel conhece) em que os carregamentos automáticos não devem ser adicionados. Normalmente, ele contém repositórios que dependem transitivamente de um repositório que pode ser carregado automaticamente (e que, portanto, pode criar um ciclo).
Tags:
loses_incremental_state,build_file_semantics,incompatible_change
- Opções relacionadas à saída e à semântica do Bzlmod:
--allow_yanked_versions=<a string>vários usos são acumulados-
Especifica as versões do módulo no formato
<module1>@<version1>,<module2>@<version2>que serão permitidas no gráfico de dependência resolvido, mesmo que sejam declaradas como removidas no registro de origem (se não vierem de um NonRegistryOverride). Caso contrário, as versões removidas vão causar falha na resolução. Também é possível definir a versão removida permitida com a variável de ambienteBZLMOD_ALLOW_YANKED_VERSIONS. É possível desativar essa verificação usando a palavra-chave "all" (não recomendado).Tags:
loading_and_analysis --check_bazel_compatibility=<error, warning or off>padrão: "error"-
Verifique a compatibilidade da versão do Bazel com os módulos do Bazel. Os valores válidos são
errorpara aumentar a gravidade para uma falha de resolução,offpara desativar a verificação ouwarningpara imprimir um aviso quando uma incompatibilidade for detectada.Tags:
loading_and_analysis --check_direct_dependencies=<off, warning or error>padrão: "warning"-
Verifique se as dependências diretas
bazel_depdeclaradas no módulo raiz são as mesmas versões que você recebe no gráfico de dependência resolvido. Os valores válidos sãooffpara desativar a verificação,warningpara imprimir um aviso quando uma incompatibilidade for detectada ouerrorpara escalar o problema a uma falha de resolução.Tags:
loading_and_analysis --[no]ignore_dev_dependencypadrão: "false"-
Se for verdadeiro, o Bazel vai ignorar
bazel_depeuse_extensiondeclarados comodev_dependencyno MODULE.bazel do módulo raiz. Essas dependências de desenvolvimento são sempre ignoradas no MODULE.bazel se não for o módulo raiz, independente do valor dessa flag.Tags:
loading_and_analysis --lockfile_mode=<off, update, refresh or error>padrão: "update"-
Especifica como e se o arquivo de bloqueio deve ser usado. Os valores válidos são
updatepara usar o arquivo de bloqueio e atualizá-lo se houver mudanças,refreshpara atualizar também informações mutáveis (versões removidas e módulos ausentes) de registros remotos de tempos em tempos,errorpara usar o arquivo de bloqueio, mas gerar um erro se ele não estiver atualizado, ouoffpara não ler nem gravar no arquivo de bloqueio.Tags:
loading_and_analysis --module_mirrors=<comma-separated list of options>padrão: consulte a descrição-
Uma lista separada por vírgulas de URLs em que os URLs de origem dos módulos do Bazel podem ser encontrados, além de ter precedência sobre qualquer URL de espelho fornecido pelo registro. Defina como um valor vazio para desativar o uso de espelhos não especificados pelos registros. O conjunto padrão de espelhos pode mudar com o tempo, mas todos os downloads de espelhos são verificados por hashes armazenados no registro e, portanto, fixados pelo arquivo de bloqueio.
Tags:
loading_and_analysis --override_module=<an equals-separated mapping of module name to path>vários usos são acumulados-
Substitua um módulo com um caminho local no formato <nome do módulo>=<caminho>. Se o caminho fornecido for absoluto, ele será usado como está. Se for relativo, ele será relativo ao diretório de trabalho atual. Se o caminho fornecido começar com "%workspace%", ele será relativo à raiz do espaço de trabalho, que é a saída de
bazel info workspace. Se o caminho especificado estiver vazio, remova todas as substituições anteriores. --registry=<a string>vários usos são acumulados-
Especifica os registros a serem usados para localizar dependências de módulos do Bazel. A ordem é importante: os módulos serão pesquisados primeiro nos registros anteriores e só vão recorrer aos registros posteriores quando estiverem faltando nos anteriores.
Tags:
changes_inputs --vendor_dir=<a path>padrão: consulte a descrição-
Especifica o diretório que deve conter os repositórios externos no modo de fornecedor, seja para buscá-los ou usá-los durante a criação. O caminho pode ser especificado como absoluto ou relativo ao diretório do espaço de trabalho.
Tags:
loading_and_analysis
- Opções que acionam otimizações do tempo de build:
--gc_thrashing_limits=<comma separated pairs of <period>:<count>>padrão: "1s:2,20s:3,1m:5"-
Limites que, se atingidos, fazem com que o GcThrashingDetector falhe no Bazel com um OOM. Cada limite é especificado como <período>:<contagem>, em que "período" é uma duração e "contagem" é um número inteiro positivo. Se mais de --gc_thrashing_threshold por cento do espaço permanente (heap da geração antiga) permanecer ocupado após <count> coletas de lixo completas consecutivas em <period>, um OOM será acionado. É possível especificar vários limites separados por vírgulas.
--[no]heuristically_drop_nodespadrão: "false"-
Se for "true", o Blaze vai remover os nós FileState e DirectoryListingState depois que o nó File e DirectoryListing relacionado for concluído para economizar memória. Acreditamos que esses nós não serão mais necessários. Nesse caso, o programa vai reavaliá-los.
Tags:
loses_incremental_state --[no]incompatible_do_not_split_linking_cmdlinepadrão: "true"-
Quando é "true", o Bazel não modifica mais as flags de linha de comando usadas para vinculação e também não decide seletivamente quais flags vão para o arquivo de parâmetros e quais não vão. Consulte https://github.com/bazelbuild/bazel/issues/7670 para mais detalhes.
--[no]keep_state_after_buildpadrão: "true"-
Se for "false", o Blaze vai descartar o estado na memória desse build quando ele terminar. Os builds subsequentes não terão incrementalidade em relação a este.
Tags:
loses_incremental_state - Padrão de
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0>: "10" -
Flag para configuração avançada do mecanismo interno do Skyframe do Bazel. Se o Bazel detectar que o uso da porcentagem de heap retido excede o limite definido por --skyframe_high_water_mark_threshold, quando um evento de GC completo ocorrer, ele vai descartar o estado temporário desnecessário do Skyframe, até esse número de vezes por invocação. O valor padrão é 10. Zero significa que eventos de GC completo nunca vão acionar quedas. Se o limite for atingido, o estado do Skyframe não será mais descartado quando ocorrer um evento de GC completo e esse limite de porcentagem de heap retido for excedido.
- Padrão de
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0>: "10" -
Flag para configuração avançada do mecanismo interno do Skyframe do Bazel. Se o Bazel detectar que o uso percentual do heap retido excede o limite definido por --skyframe_high_water_mark_threshold, quando um evento de GC secundário ocorrer, ele vai descartar o estado temporário desnecessário do Skyframe até esse número de vezes por invocação. O valor padrão é 10. Zero significa que eventos de coleta de lixo secundários nunca vão acionar quedas. Se o limite for atingido, o estado do Skyframe não será mais descartado quando ocorrer um evento de GC secundário e esse limite de porcentagem de heap retido for excedido.
--skyframe_high_water_mark_threshold=<an integer>padrão: "85"-
Flag para configuração avançada do mecanismo interno do Skyframe do Bazel. Se o Bazel detectar que o uso da porcentagem de heap retido está pelo menos nesse limite, ele vai descartar o estado temporário desnecessário do Skyframe. Ajustar isso pode ajudar a reduzir o impacto do tempo real do thrashing do GC, quando ele é (i) causado pelo uso da memória desse estado temporário e (ii) mais caro do que reconstituir o estado quando necessário.
--[no]track_incremental_statepadrão: "true"-
Se for "false", o Blaze não vai manter os dados que permitem a invalidação e a reavaliação em builds incrementais para economizar memória nesse build. Os builds subsequentes não terão incrementalidade em relação a este. Normalmente, você especifica --batch ao definir isso como "false".
Tags:
loses_incremental_state
- Opções que afetam a verbosidade, o formato ou o local do registro em log:
--[no]announce_rcpadrão: "false"-
Se as opções de rc devem ser anunciadas.
Tags:
affects_outputs --[no]attempt_to_print_relative_pathspadrão: "false"-
Ao imprimir a parte de localização das mensagens, tente usar um caminho relativo ao diretório do espaço de trabalho ou um dos diretórios especificados por --package_path.
Tags:
terminal_output --bes_backend=<a string>padrão: ""-
Especifica o endpoint de back-end do serviço de eventos de build (BES, na sigla em inglês) no formato [SCHEME://]HOST[:PORT]. O padrão é desativar os uploads do BES. Os esquemas compatíveis são grpc e grpcs (grpc com TLS ativado). Se nenhum esquema for fornecido, o Bazel vai presumir grpcs.
Tags:
affects_outputs --[no]bes_check_preceding_lifecycle_eventspadrão: "false"-
Define o campo check_preceding_lifecycle_events_present em PublishBuildToolEventStreamRequest, que informa ao BES para verificar se ele recebeu anteriormente eventos InvocationAttemptStarted e BuildEnqueued correspondentes ao evento da ferramenta atual.
Tags:
affects_outputs --bes_header=<a 'name=value' assignment>vários usos são acumulados-
Especifique um cabeçalho no formato NAME=VALUE que será incluído nas solicitações do BES. É possível transmitir vários cabeçalhos especificando a flag várias vezes. Vários valores para o mesmo nome serão convertidos em uma lista separada por vírgulas.
Tags:
affects_outputs --bes_instance_name=<a string>padrão: consulte a descrição-
Especifica o nome da instância em que o BES vai manter o BEP enviado. O padrão é nulo.
Tags:
affects_outputs --bes_keywords=<comma-separated list of options>vários usos são acumulados-
Especifica uma lista de palavras-chave de notificação a serem adicionadas ao conjunto padrão de palavras-chave publicadas no BES ("command_name=<command_name> ", "protocol_name=BEP"). O padrão é "Nenhum".
Tags:
affects_outputs --[no]bes_lifecycle_eventspadrão: "true"-
Especifica se os eventos do ciclo de vida do BES serão publicados. O padrão é "true".
Tags:
affects_outputs - Padrão de
--bes_oom_finish_upload_timeout=<An immutable length of time.>: "10m" -
Especifica quanto tempo o Bazel deve esperar que o upload do BES/BEP seja concluído durante a falta de memória. Essa flag garante o encerramento quando a JVM está com thrashing de GC grave e não consegue progredir em nenhuma linha de execução do usuário.
Tags:
bazel_monitoring - Padrão de
--bes_outerr_buffer_size=<an integer>: "10240" -
Especifica o tamanho máximo de stdout ou stderr a ser armazenado em buffer no BEP antes de ser informado como um evento de progresso. As gravações individuais ainda são informadas em um único evento, mesmo que sejam maiores que o valor especificado até --bes_outerr_chunk_size.
Tags:
affects_outputs --bes_outerr_chunk_size=<an integer>padrão: "1048576"-
Especifica o tamanho máximo de stdout ou stderr a ser enviado ao BEP em uma única mensagem.
Tags:
affects_outputs --bes_proxy=<a string>padrão: consulte a descrição-
Conecte-se ao serviço de eventos de build por um proxy. No momento, essa flag só pode ser usada para configurar um soquete de domínio Unix (unix:/path/to/socket).
--bes_results_url=<a string>padrão: ""-
Especifica o URL base em que um usuário pode ver as informações transmitidas para o back-end do BES. O Bazel vai enviar o URL anexado pelo ID de invocação para o terminal.
Tags:
terminal_output --bes_system_keywords=<comma-separated list of options>vários usos são acumulados-
Especifica uma lista de palavras-chave de notificação a serem incluídas diretamente, sem o prefixo "user_keyword=" incluído para palavras-chave fornecidas via --bes_keywords. Destinado a operadores do serviço de build que definem --bes_lifecycle_events=false e incluem palavras-chave ao chamar PublishLifecycleEvent. Os operadores de serviço de build que usam essa flag precisam impedir que os usuários substituam o valor dela.
Tags:
affects_outputs --bes_timeout=<An immutable length of time.>padrão: "0s"-
Especifica por quanto tempo o Bazel deve aguardar a conclusão do upload do BES/BEP após a conclusão do build e dos testes. Um tempo limite válido é um número natural seguido por uma unidade: dias (d), horas (h), minutos (m), segundos (s) e milissegundos (ms). O valor padrão é "0", o que significa que não há tempo limite.
Tags:
affects_outputs --bes_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async>padrão: "wait_for_upload_complete"-
Especifica se o upload do serviço de eventos de build deve bloquear a conclusão do build ou encerrar a invocação imediatamente e concluir o upload em segundo plano.
wait_for_upload_complete: bloqueia no final da invocação atual até que todos os eventos (incluindo eventos de ciclo de vida, se aplicável) sejam enviados e confirmados pelo back-end.nowait_for_upload_complete: bloqueia no início da próxima invocação até que todos os eventos (incluindo eventos de ciclo de vida, se aplicável) sejam enviados e confirmados pelo back-end.fully_async: bloqueia no início da próxima invocação até que todos os eventos sejam enviados, mas não aguarda confirmações. Os eventos podem ser perdidos em caso de falhas (temporárias), e os back-ends podem informar fluxos como incompletos nesse modo. Não há garantia de que os eventos de ciclo de vidaFinishInvocationAttemptouFinishBuildsejam enviados.
Tags:
eagerness_to_exit --build_event_binary_file=<a string>padrão: ""-
Se não estiver vazio, grave uma representação binária delimitada por varint do protocolo de evento de build nesse arquivo. Essa opção implica --bes_upload_mode=wait_for_upload_complete.
Tags:
affects_outputs --[no]build_event_binary_file_path_conversionpadrão: "true"-
Converter caminhos na representação de arquivo binário do protocolo de evento de build em URIs mais válidos globalmente sempre que possível. Se desativado, o esquema de URI file:// será sempre usado.
Tags:
affects_outputs --build_event_binary_file_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async>padrão: "wait_for_upload_complete"-
Especifica se o upload do Build Event Service para --build_event_binary_file deve bloquear a conclusão do build ou encerrar a invocação imediatamente e concluir o upload em segundo plano. "wait_for_upload_complete" (padrão), "nowait_for_upload_complete" ou "fully_async".
Tags:
eagerness_to_exit --build_event_json_file=<a string>padrão: ""-
Se não estiver vazio, grave uma serialização JSON do protocolo de evento de build nesse arquivo. Essa opção implica --bes_upload_mode=wait_for_upload_complete.
Tags:
affects_outputs --[no]build_event_json_file_path_conversionpadrão: "true"-
Converter caminhos na representação do arquivo json do protocolo de evento de build em URIs mais válidos globalmente sempre que possível. Se desativado, o esquema de URI file:// será sempre usado.
Tags:
affects_outputs --build_event_json_file_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async>padrão: "wait_for_upload_complete"-
Especifica se o upload do Build Event Service para --build_event_json_file deve bloquear a conclusão do build ou encerrar a invocação imediatamente e concluir o upload em segundo plano. "wait_for_upload_complete" (padrão), "nowait_for_upload_complete" ou "fully_async".
Tags:
eagerness_to_exit - Padrão de
--build_event_max_named_set_of_file_entries=<an integer>: "5000" -
O número máximo de entradas para um único evento named_set_of_files. Valores menores que 2 são ignorados, e não é feita divisão de eventos. Isso limita o tamanho máximo do evento no protocolo de evento de build, embora não controle diretamente o tamanho do evento. O tamanho total do evento é uma função da estrutura do conjunto, bem como dos comprimentos do arquivo e do URI, que podem depender da função hash.
Tags:
affects_outputs --[no]build_event_publish_all_actionspadrão: "false"-
Se todas as ações devem ser publicadas.
Tags:
affects_outputs --build_event_text_file=<a string>padrão: ""-
Se não estiver vazio, grave uma representação textual do protocolo de evento de build nesse arquivo.
Tags:
affects_outputs --[no]build_event_text_file_path_conversionpadrão: "true"-
Converter caminhos na representação do arquivo de texto do protocolo de evento de build em URIs mais válidos globalmente sempre que possível. Se desativado, o esquema de URI file:// sempre será usado.
Tags:
affects_outputs --build_event_text_file_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async>padrão: "wait_for_upload_complete"-
Especifica se o upload do serviço de eventos de build para --build_event_text_file deve bloquear a conclusão do build ou encerrar a invocação imediatamente e concluir o upload em segundo plano. "wait_for_upload_complete" (padrão), "nowait_for_upload_complete" ou "fully_async".
Tags:
eagerness_to_exit --build_event_upload_max_retries=<an integer>padrão: "4"-
O número máximo de vezes que o Bazel deve tentar fazer upload de um evento de build.
--[no]experimental_bep_target_summarypadrão: "false"-
Se os eventos TargetSummary serão publicados.
--[no]experimental_build_event_expand_filesetspadrão: "false"-
Se for "true", expanda os conjuntos de arquivos no BEP ao apresentar arquivos de saída.
Tags:
affects_outputs --experimental_build_event_output_group_mode=<an output group name followed by an OutputGroupFileMode, e.g. default=both>vários usos são acumulados-
Especifique como os arquivos de um grupo de saída serão representados em eventos BEP TargetComplete/AspectComplete. Os valores são uma atribuição de um nome de grupo de saída a um de "NAMED_SET_OF_FILES_ONLY", "INLINE_ONLY" ou "BOTH". O valor padrão é "NAMED_SET_OF_FILES_ONLY". Se um grupo de saída for repetido, o valor final a aparecer será usado. O valor padrão define o modo para artefatos de cobertura como "BOTH": --experimental_build_event_output_group_mode=baseline.lcov=both
Tags:
affects_outputs - Padrão de
--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.>: "1s" -
Atraso inicial e mínimo para novas tentativas de espera exponencial quando o upload do BEP falha. (expoente: 1,6)
--experimental_build_event_upload_strategy=<a string>padrão: consulte a descrição-
Seleciona como fazer upload dos artefatos referenciados no protocolo de eventos de build. No Bazel, as opções válidas incluem "local" e "remote". O valor padrão é "local".
Tags:
affects_outputs --[no]experimental_collect_load_average_in_profilerpadrão: "true"-
Se ativado, o criador de perfil coleta a média geral de carga do sistema.
Tags:
bazel_monitoring --[no]experimental_collect_pressure_stall_indicatorspadrão: "false"-
Se ativado, o criador de perfis coleta os dados de PSI do Linux.
Tags:
bazel_monitoring --[no]experimental_collect_resource_estimationpadrão: "false"-
Se ativado, o criador de perfis coleta a estimativa de uso de CPU e memória para ações locais.
Tags:
bazel_monitoring --[no]experimental_collect_skyframe_counts_in_profilerpadrão: "false"-
Se ativado, o criador de perfil coleta contagens de SkyFunction no gráfico do Skyframe ao longo do tempo para tipos de funções principais, como destinos configurados e execuções de ações. Pode ter um impacto na performance, já que visita o gráfico INTEIRO do Skyframe em todas as unidades de tempo de criação de perfil. Não use essa flag com medições de desempenho crítico.
Tags:
bazel_monitoring --[no]experimental_collect_system_network_usagepadrão: "true"-
Se ativado, o criador de perfis coleta o uso da rede do sistema.
Tags:
bazel_monitoring --[no]experimental_collect_worker_data_in_profilerpadrão: "true"-
Se ativado, o criador de perfil coleta dados agregados de recursos do worker.
Tags:
bazel_monitoring --experimental_command_profile=<cpu, wall, alloc or lock>padrão: consulte a descrição-
Registra um perfil do Java Flight Recorder durante a execução do comando. Um dos tipos de eventos de criação de perfil compatíveis (cpu, wall, alloc ou lock) precisa ser fornecido como argumento. O perfil é gravado em um arquivo com o nome do tipo de evento no diretório base de saída. A sintaxe e a semântica dessa flag podem mudar no futuro para oferecer suporte a outros tipos de perfil ou formatos de saída. Use por sua conta e risco.
--experimental_profile_additional_tasks=<phase, action, discover_inputs, action_check, action_lock, action_update, action_complete, action_rewinding, bzlmod, info, create_package, remote_execution, local_execution, scanner, local_parse, upload_time, remote_process_time, remote_queue, remote_setup, fetch, local_process_time, vfs_stat, vfs_dir, vfs_readlink, vfs_md5, vfs_xattr, vfs_delete, vfs_open, vfs_read, vfs_write, vfs_glob, vfs_vmfs_stat, vfs_vmfs_dir, vfs_vmfs_read, wait, thread_name, thread_sort_index, skyframe_eval, skyfunction, critical_path, critical_path_component, handle_gc_notification, local_action_counts, starlark_parser, starlark_user_fn, starlark_builtin_fn, starlark_user_compiled_fn, starlark_repository_fn, action_fs_staging, remote_cache_check, remote_download, remote_network, filesystem_traversal, worker_execution, worker_setup, worker_borrow, worker_working, worker_copying_outputs, credential_helper, conflict_check, dynamic_lock, repository_fetch, repository_vendor, repo_cache_gc_wait, spawn_log, rpc, skycache, wasm_load, wasm_exec or unknown>vários usos são acumulados-
Especifica outras tarefas de perfil a serem incluídas no perfil.
Tags:
bazel_monitoring --[no]experimental_profile_include_primary_outputpadrão: "false"-
Inclui o atributo extra "out" em eventos de ação que contêm o caminho de execução para a saída principal da ação.
Tags:
bazel_monitoring --[no]experimental_profile_include_target_configurationpadrão: "false"-
Inclui o hash de configuração de destino nos dados de perfil JSON dos eventos de ação.
Tags:
bazel_monitoring --[no]experimental_profile_include_target_labelpadrão: "false"-
Inclui o rótulo de destino nos dados de perfil JSON dos eventos de ação.
Tags:
bazel_monitoring --[no]experimental_record_metrics_for_all_mnemonicspadrão: "false"-
Controla a saída de BEP ActionSummary e BuildGraphMetrics, limitando o número de mnemônicos em ActionData e o número de entradas informadas em BuildGraphMetrics.AspectCount/RuleClassCount. Por padrão, o número de tipos é limitado aos 20 principais, por número de ações executadas para ActionData e instâncias para RuleClass e Aspects. Definir essa opção grava estatísticas para todos os mnemônicos, classes de regras e aspectos.
--[no]experimental_record_skyframe_metricspadrão: "false"-
Controla a saída de BEP BuildGraphMetrics, incluindo métricas caras para computar skyframe sobre Skykeys, RuleClasses e Aspects.Com essa flag definida como "false", BuildGraphMetrics.rule_count e aspectfields não serão preenchidos no BEP.
--[no]experimental_run_bep_event_include_residuepadrão: "false"-
Incluir ou não o resíduo da linha de comando em eventos de build de execução que podem conter o resíduo. Por padrão, o resíduo não é incluído em eventos de build de comandos de execução que podem conter o resíduo.
Tags:
affects_outputs --[no]experimental_stream_log_file_uploadspadrão: "false"-
Fazer streaming dos uploads de arquivos de registro diretamente para o armazenamento remoto em vez de gravá-los no disco.
Tags:
affects_outputs --experimental_workspace_rules_log_file=<a path>padrão: consulte a descrição-
Registre determinados eventos das regras do Workspace nesse arquivo como protos WorkspaceEvent delimitados.
--[no]generate_json_trace_profilepadrão: "auto"-
Se ativado, o Bazel cria um perfil do build e grava um perfil no formato JSON em um arquivo na base de saída. Para ver o perfil, carregue em chrome://tracing. Por padrão, o Bazel grava o perfil para todos os comandos e consultas semelhantes a build.
Tags:
bazel_monitoring --[no]heap_dump_on_oompadrão: "false"-
Se uma saída manual de um despejo de heap deve ser gerada quando um OOM é gerado, incluindo OOMs manuais devido ao alcance de --gc_thrashing_limits. O despejo será gravado em <output_base>/<invocation_id>.heapdump.hprof. Essa opção substitui -XX:+HeapDumpOnOutOfMemoryError, que não tem efeito em OOMs manuais.
Tags:
bazel_monitoring --jvm_heap_histogram_internal_object_pattern=<a valid Java regular expression>padrão: "jdk\.internal\.vm\.Filler.+"-
Expressão regular para substituir a lógica de correspondência da coleta de memória de heap da JVM JDK21+. Estamos usando detalhes voláteis da implementação interna do G1 GC para receber uma métrica de memória limpa. Essa opção permite que nos adaptemos a mudanças nessa implementação interna sem precisar esperar por um lançamento binário. Transmitido para JDK Matcher.find()
--[no]legacy_important_outputspadrão: "false"-
Use isso para suprimir a geração do campo legado important_outputs no evento TargetComplete. important_outputs são necessários para a integração do Bazel com ResultStore/BTX.
Tags:
affects_outputs - Padrão de
--logging=<0 <= an integer <= 6>: "3" -
O nível de geração de registros.
Tags:
affects_outputs --memory_profile=<a path>padrão: consulte a descrição-
Se definido, grava dados de uso de memória no arquivo especificado no final das fases e heap estável no registro principal no final da build.
Tags:
bazel_monitoring - Padrão
--memory_profile_stable_heap_parameters=<integers, separated by a comma expected in pairs>: "1,0" -
Ajuste o cálculo do perfil de memória do heap estável no final da criação. Precisa ser um número par de números inteiros separados por vírgulas. Em cada par, o primeiro número inteiro é o número de GCs a serem realizados. O segundo número inteiro em cada par é o número de segundos a serem aguardados entre as GCs. Ex: 2,4,4,0 seriam 2 GCs com uma pausa de 4 segundos, seguidos por 4 GCs com pausa de zero segundo.
Tags:
bazel_monitoring --profile=<a path>padrão: consulte a descrição-
Se definido, cria um perfil do Bazel e grava dados no arquivo especificado. Consulte https://bazel.build/advanced/performance/json-trace-profile para mais informações.
Tags:
bazel_monitoring - Padrão de
--profiles_to_retain=<an integer>: "5" -
Número de perfis a serem mantidos na base de saída. Se houver mais perfis na base de saída, os mais antigos serão excluídos até que o total fique abaixo do limite.
Tags:
bazel_monitoring --[no]record_full_profiler_datapadrão: "false"-
Por padrão, o criador de perfil do Bazel registra apenas dados agregados para eventos rápidos, mas numerosos (como a estatística do arquivo). Se essa opção estiver ativada, o criador de perfil vai registrar cada evento, resultando em dados de criação de perfil mais precisos, mas com um GRANDE impacto na performance. A opção só tem efeito se "--profile" também for usada.
Tags:
bazel_monitoring --[no]redirect_local_instrumentation_output_writespadrão: "false"-
Se for "true" e compatível, a saída da instrumentação será redirecionada para ser gravada localmente em uma máquina diferente daquela em que o Bazel está sendo executado.
Tags:
bazel_monitoring - Padrão de
--remote_print_execution_messages=<failure, success or all>: "failure" -
Escolha quando imprimir mensagens de execução remota. Os valores válidos são
failure, para imprimir apenas em falhas,successpara imprimir apenas em sucessos eallpara imprimir sempre.Tags:
terminal_output --[no]slim_profilepadrão: "true"-
Reduz o tamanho do perfil JSON mesclando eventos se o perfil ficar muito grande.
Tags:
bazel_monitoring --starlark_cpu_profile=<a string>padrão: ""-
Grava no arquivo especificado um perfil pprof do uso da CPU por todas as linhas de execução do Starlark.
Tags:
bazel_monitoring --tool_tag=<a string>padrão: ""-
Um nome de ferramenta para atribuir essa invocação do Bazel.
Tags:
affects_outputs,bazel_monitoring --ui_event_filters=<Convert list of comma separated event kind to list of filters>vários usos são acumulados-
Especifica quais eventos mostrar na interface. É possível adicionar ou remover eventos dos padrões usando +/- no início ou substituir o conjunto padrão completamente com atribuição direta. O conjunto de tipos de eventos compatíveis inclui INFO, DEBUG, ERROR e muito mais.
Tags:
terminal_output --[no]write_command_logpadrão: "false"-
Se é necessário gravar o arquivo command.log
Tags:
bazel_monitoring
- Opções de execução e armazenamento em cache remoto:
--downloader_config=<a path>padrão: consulte a descrição-
Especifique um arquivo para configurar o downloader remoto. Esse arquivo consiste em linhas, cada uma delas começando com uma diretiva (
allow,blockourewrite) seguida por um nome de host (paraalloweblock) ou dois padrões, um para corresponder e outro para usar como um URL substituto, com referências anteriores começando em$1. É possível fornecer várias diretivasrewritepara o mesmo URL. Nesse caso, vários URLs serão retornados. --experimental_circuit_breaker_strategy=<failure>padrão: consulte a descrição-
Especifica a estratégia a ser usada pelo disjuntor. As estratégias disponíveis são "failure". Em um valor inválido para a opção, o comportamento é o mesmo que se a opção não estivesse definida.
Tags:
execution - Padrão de
--experimental_remote_cache_compression_threshold=<an integer>: "100" -
O tamanho mínimo do blob necessário para compactar/descompactar com zstd. Não tem efeito, a menos que --remote_cache_compression esteja definido.
--[no]experimental_remote_cache_lease_extensionpadrão: "false"-
Se definido como verdadeiro, o Bazel vai estender o lease para saídas de ações remotas durante o build enviando chamadas
FindMissingBlobsperiodicamente ao cache remoto. A frequência é baseada no valor de--experimental_remote_cache_ttl. - Padrão de
--experimental_remote_cache_ttl=<An immutable length of time.>: "3h" -
O TTL mínimo garantido de blobs no cache remoto depois que os resumos são referenciados recentemente, por exemplo, por um ActionResult ou FindMissingBlobs. O Bazel faz várias otimizações com base no TTL dos blobs. Por exemplo, ele não chama GetActionResult repetidamente em um build incremental. O valor precisa ser definido um pouco menor que o TTL real, já que há uma lacuna entre o momento em que o servidor retorna os resumos e quando o Bazel os recebe.
Tags:
execution --experimental_remote_capture_corrupted_outputs=<a path>padrão: consulte a descrição-
Um caminho para um diretório em que as saídas corrompidas serão capturadas.
--[no]experimental_remote_discard_merkle_treespadrão: "true"-
Se definido como "true", descarte as cópias na memória da árvore de Merkle da raiz de entrada e os mapeamentos de entrada associados durante as chamadas para GetActionResult() e Execute(). Isso reduz significativamente o uso da memória, mas exige que o Bazel recalcule esses dados em caso de falhas e novas tentativas de cache remoto.
--experimental_remote_downloader=<a string>padrão: consulte a descrição-
Um URI de endpoint da API Remote Asset, a ser usado como um proxy de download remoto. Os esquemas compatíveis são grpc, grpcs (grpc com TLS ativado) e unix (sockets UNIX locais). Se nenhum esquema for fornecido, o Bazel vai usar grpcs como padrão. Consulte: https://github.com/bazelbuild/remote-apis/blob/master/build/bazel/remote/asset/v1/remote_asset.proto
--[no]experimental_remote_downloader_local_fallbackpadrão: "false"-
Se é necessário voltar ao downloader local se o downloader remoto falhar.
--[no]experimental_remote_downloader_propagate_credentialspadrão: "false"-
Se as credenciais do netrc e do auxiliar de credenciais serão propagadas para o servidor de download remoto. A implementação do servidor precisa oferecer suporte ao novo qualificador
http_header_url:<url-index>:<header-key>, em que<url-index>é uma posição baseada em zero do URL no campourisde FetchBlobRequest. Os cabeçalhos específicos do URL têm precedência sobre os globais. --[no]experimental_remote_execution_keepalivepadrão: "false"-
Indica se o keepalive será usado para chamadas de execução remota.
- Padrão de
--experimental_remote_failure_rate_threshold=<an integer in 0-100 range>: "10" -
Define o número permitido de taxa de falha em porcentagem para um período específico após o qual ele para de chamar o cache/executor remoto. Por padrão, o valor é 10. Definir como 0 significa que não há limitação.
Tags:
execution - Padrão de
--experimental_remote_failure_window_interval=<An immutable length of time.>: "60s" -
O intervalo em que a taxa de falha das solicitações remotas é calculada. Em valor zero ou negativo, a duração da falha é calculada como toda a duração da execução.As seguintes unidades podem ser usadas: dias (d), horas (h), minutos (m), segundos (s) e milissegundos (ms). Se a unidade for omitida, o valor será interpretado como segundos.
Tags:
execution --[no]experimental_remote_mark_tool_inputspadrão: "false"-
Se definido como verdadeiro, o Bazel vai marcar as entradas como entradas de ferramentas para o executor remoto. Isso pode ser usado para implementar trabalhadores persistentes remotos.
--[no]experimental_remote_merkle_tree_cachepadrão: "false"-
Se definido como "true", os cálculos da árvore de Merkle serão memorizados para melhorar a velocidade de verificação de acertos do cache remoto. A pegada de memória do cache é controlada por --experimental_remote_merkle_tree_cache_size.
- Padrão de
--experimental_remote_merkle_tree_cache_size=<a long integer>: "1000" -
O número de árvores de Merkle a serem memorizadas para melhorar a velocidade de verificação de ocorrência em cache remoto. Embora o cache seja reduzido automaticamente de acordo com o processamento de referências leves do Java, erros de falta de memória podem ocorrer se o valor estiver muito alto. Se definido como 0, o tamanho do cache será ilimitado. O valor ideal varia de acordo com o tamanho do projeto. O padrão é 1.000.
--experimental_remote_output_service=<a string>padrão: consulte a descrição-
HOST ou HOST:PORT de um endpoint de serviço de saída remota. Os esquemas compatíveis são grpc, grpcs (grpc com TLS ativado) e unix (sockets UNIX locais). Se nenhum esquema for fornecido, o Bazel vai usar grpcs como padrão. Especifique o esquema grpc:// ou unix: para desativar o TLS.
--experimental_remote_output_service_output_path_prefix=<a string>padrão: ""-
O caminho em que o conteúdo dos diretórios de saída gerenciados pelo --experimental_remote_output_service é colocado. O diretório de saída real usado por um build será um descendente desse caminho e determinado pelo serviço de saída.
--[no]experimental_remote_require_cachedpadrão: "false"-
Se definido como "true", força o cache de todas as ações que podem ser executadas remotamente ou falha na build. Isso é útil para resolver problemas de não determinismo, porque permite verificar se as ações que devem ser armazenadas em cache são realmente armazenadas sem inserir novos resultados no cache.
--experimental_remote_scrubbing_config=<Converts to a Scrubber>padrão: consulte a descrição-
Ativa a limpeza remota de chaves de cache com o arquivo de configuração fornecido, que precisa ser um buffer de protocolo em formato de texto. Consulte src/main/protobuf/remote_scrubbing.proto.
O objetivo desse recurso é facilitar o compartilhamento de um cache remoto/de disco entre ações executadas em plataformas diferentes, mas segmentando a mesma plataforma. Ele precisa ser usado com muito cuidado, já que configurações inadequadas podem causar o compartilhamento acidental de entradas de cache e resultar em builds incorretos.
A limpeza não afeta a execução de uma ação, apenas como a chave de cache remoto/de disco dela é calculada para recuperar ou armazenar um resultado de ação. As ações de limpeza não são compatíveis com a execução remota e sempre serão executadas localmente.
Modificar a configuração de limpeza não invalida as saídas presentes no sistema de arquivos local ou nos caches internos. É necessário um build limpo para reexecutar as ações afetadas.
Para usar esse recurso, defina um --host_platform personalizado junto com --experimental_platform_in_output_dir (para normalizar prefixos de saída) e --incompatible_strict_action_env (para normalizar variáveis de ambiente).
--[no]guard_against_concurrent_changespadrão: "lite"-
Defina como "full" para ativar a verificação do ctime de todos os arquivos de entrada de uma ação antes de fazer upload para um cache remoto. Em alguns casos, o kernel do Linux atrasa a gravação de arquivos, o que pode causar falsos positivos. O padrão é "lite", que verifica apenas arquivos de origem no repositório principal. Definir como "off" desativa todas as verificações. Isso não é recomendado, porque o cache pode ser corrompido quando um arquivo de origem é alterado enquanto uma ação que o usa como entrada está sendo executada.
Tags:
execution --[no]remote_accept_cachedpadrão: "true"-
Se aceitar resultados de ações armazenados em cache remotamente.
--remote_build_event_upload=<all or minimal>padrão: "minimal"-
Se definido como "all", todas as saídas locais referenciadas pelo BEP serão enviadas por upload para o cache remoto. Se definido como "minimal", as saídas locais referenciadas pelo BEP não serão enviadas para o cache remoto, exceto arquivos importantes para os consumidores do BEP (por exemplo, registros de teste e perfil de tempo). O esquema bytestream:// é sempre usado para o URI dos arquivos, mesmo que eles estejam ausentes do cache remoto. O padrão é "minimal".
--remote_bytestream_uri_prefix=<a string>padrão: consulte a descrição-
O nome do host e da instância a serem usados em URIs bytestream:// gravados em fluxos de eventos de build. Essa opção pode ser definida quando os builds são realizados usando um proxy, o que faz com que os valores de --remote_executor e --remote_instance_name não correspondam mais ao nome canônico do serviço de execução remota. Quando não definido, o padrão é "${hostname}/${instance_name}".
--remote_cache=<a string>padrão: consulte a descrição-
Um URI de um endpoint de cache. Os esquemas compatíveis são http, https, grpc, grpcs (grpc com TLS ativado) e unix (sockets UNIX locais). Se nenhum esquema for fornecido, o Bazel vai usar grpcs como padrão. Especifique o esquema grpc://, http:// ou unix: para desativar o TLS. Consulte https://bazel.build/remote/caching
--[no]remote_cache_asyncpadrão: "true"-
Se for verdadeiro, o upload dos resultados da ação para um disco ou cache remoto vai acontecer em segundo plano, em vez de bloquear a conclusão de uma ação. Algumas ações são incompatíveis com uploads em segundo plano e ainda podem bloquear mesmo quando essa flag está definida.
--[no]remote_cache_compressionpadrão: "false"-
Se ativado, compacta/descompacta blobs de cache com zstd quando o tamanho deles for pelo menos --experimental_remote_cache_compression_threshold.
--remote_cache_header=<a 'name=value' assignment>vários usos são acumulados-
Especifique um cabeçalho que será incluído nas solicitações de cache: --remote_cache_header=Name=Value. É possível transmitir vários cabeçalhos especificando a flag várias vezes. Vários valores para o mesmo nome serão convertidos em uma lista separada por vírgulas.
--remote_default_exec_properties=<a 'name=value' assignment>vários usos são acumulados-
Defina as propriedades de execução padrão a serem usadas como a plataforma de execução remota se uma plataforma de execução ainda não tiver definido exec_properties.
Tags:
affects_outputs --remote_default_platform_properties=<a string>padrão: ""-
Defina as propriedades de plataforma padrão para serem definidas para a API de execução remota, caso a plataforma de execução ainda não tenha definido remote_execution_properties. Esse valor também será usado se a plataforma host for selecionada como a plataforma de execução para execução remota.
--remote_download_regex=<a valid Java regular expression>vários usos são acumulados-
Força o download de saídas de build remoto cujo caminho corresponda a esse padrão, independente de --remote_download_outputs. É possível especificar vários padrões repetindo essa flag.
Tags:
affects_outputs --remote_downloader_header=<a 'name=value' assignment>vários usos são acumulados-
Especifique um cabeçalho que será incluído nas solicitações do downloader remoto: --remote_downloader_header=Name=Value. É possível transmitir vários cabeçalhos especificando a flag várias vezes. Vários valores para o mesmo nome serão convertidos em uma lista separada por vírgulas.
--remote_exec_header=<a 'name=value' assignment>vários usos são acumulados-
Especifique um cabeçalho que será incluído nas solicitações de execução: --remote_exec_header=Name=Value. É possível transmitir vários cabeçalhos especificando a flag várias vezes. Vários valores para o mesmo nome serão convertidos em uma lista separada por vírgulas.
--remote_execution_priority=<an integer>padrão: "0"-
A prioridade relativa das ações a serem executadas remotamente. A semântica dos valores de prioridade específicos depende do servidor.
--remote_executor=<a string>padrão: consulte a descrição-
HOST ou HOST:PORT de um endpoint de execução remota. Os esquemas compatíveis são grpc, grpcs (grpc com TLS ativado) e unix (sockets UNIX locais). Se nenhum esquema for fornecido, o Bazel vai usar grpcs como padrão. Especifique o esquema grpc:// ou unix: para desativar o TLS.
--remote_grpc_log=<a path>padrão: consulte a descrição-
Se especificado, um caminho para um arquivo para registrar detalhes relacionados à chamada gRPC. Esse registro consiste em uma sequência de protobufs com.google.devtools.build.lib.remote.logging.RemoteExecutionLog.LogEntry serializados. Cada mensagem tem um prefixo de varint que indica o tamanho da mensagem protobuf serializada a seguir, conforme realizado pelo método LogEntry.writeDelimitedTo(OutputStream).
--remote_header=<a 'name=value' assignment>vários usos são acumulados-
Especifique um cabeçalho que será incluído nas solicitações: --remote_header=Name=Value. É possível transmitir vários cabeçalhos especificando a flag várias vezes. Vários valores para o mesmo nome serão convertidos em uma lista separada por vírgulas.
--remote_instance_name=<a string>padrão: ""-
Valor a ser transmitido como "instance_name" na API de execução remota.
--[no]remote_local_fallbackpadrão: "false"-
Se é necessário voltar para a estratégia de execução local independente se a execução remota falhar.
--remote_local_fallback_strategy=<a string>padrão: "local"-
Obsoleto. Consulte https://github.com/bazelbuild/bazel/issues/7480 para mais detalhes.
- Padrão de
--remote_max_connections=<an integer>: "100" -
Limite o número máximo de conexões simultâneas com o cache/executor remoto. Por padrão, o valor é 100. Definir como 0 significa que não há limitação. Para o cache remoto HTTP, uma conexão TCP pode processar uma solicitação por vez. Assim, o Bazel pode fazer até --remote_max_connections solicitações simultâneas. Para o cache/executor remoto do gRPC, um canal do gRPC geralmente pode processar mais de 100 solicitações simultâneas. Assim, o Bazel pode fazer cerca de
--remote_max_connections * 100solicitações simultâneas. --remote_proxy=<a string>padrão: consulte a descrição-
Conecte-se ao cache remoto por um proxy. No momento, essa flag só pode ser usada para configurar um soquete de domínio Unix (unix:/path/to/socket).
--remote_result_cache_priority=<an integer>padrão: "0"-
A prioridade relativa das ações remotas a serem armazenadas no cache remoto. A semântica dos valores de prioridade específicos depende do servidor.
- Padrão de
--remote_retries=<an integer>: "5" -
O número máximo de tentativas para repetir um erro temporário. Se definido como 0, as novas tentativas serão desativadas.
- Padrão de
--remote_retry_max_delay=<An immutable length of time.>: "5s" -
O atraso máximo de espera entre tentativas remotas. As seguintes unidades podem ser usadas: dias (d), horas (h), minutos (m), segundos (s) e milissegundos (ms). Se a unidade for omitida, o valor será interpretado como segundos.
- Padrão de
--remote_timeout=<An immutable length of time.>: "60s" -
O tempo máximo de espera para execução remota e chamadas de cache. Para o cache REST, esse é o tempo limite de conexão e de leitura. As seguintes unidades podem ser usadas: dias (d), horas (h), minutos (m), segundos (s) e milissegundos (ms). Se a unidade for omitida, o valor será interpretado como segundos.
--[no]remote_upload_local_resultspadrão: "true"-
Se os resultados de ações executadas localmente devem ser enviados por upload para o cache remoto, caso ele seja compatível e o usuário tenha autorização para isso.
--[no]remote_verify_downloadspadrão: "true"-
Se definido como "true", o Bazel vai calcular a soma de hash de todos os downloads remotos e descartar os valores armazenados em cache remotamente se eles não corresponderem ao valor esperado.
- Opções diversas, não categorizadas de outra forma:
--build_metadata=<a 'name=value' assignment>vários usos são acumulados-
Pares de string de chave-valor personalizados a serem fornecidos em um evento de build.
Tags:
terminal_output --color=<yes, no or auto>padrão: "auto"-
Use controles de terminal para colorir a saída.
--config=<a string>vários usos são acumulados-
Seleciona seções de configuração adicionais dos arquivos rc. Para cada <command>, também extrai as opções de <command>:<config> se essa seção existir. Se essa seção não existir em nenhum arquivo .rc, o Blaze vai falhar com um erro. As seções de configuração e as combinações de flags equivalentes estão localizadas nos arquivos de configuração tools/*.blazerc.
--credential_helper=<Path to a credential helper. It may be absolute, relative to the PATH environment variable, or %workspace%-relative. The path be optionally prefixed by a scope followed by an '='. The scope is a domain name, optionally with a single leading '*' wildcard component. A helper applies to URIs matching its scope, with more specific scopes preferred. If a helper has no scope, it applies to every URI.>vários usos são acumulados-
Configura um auxiliar de credenciais de acordo com a <a href="https://github.com/EngFlow/credential-helper-spec">especificação de auxiliar de credenciais</a> (link em inglês) para usar na recuperação de credenciais de autorização para busca, execução e armazenamento em cache remoto de repositórios, além do serviço de eventos de build.
As credenciais fornecidas por um assistente têm precedência sobre as credenciais fornecidas por
--google_default_credentials,--google_credentials, um arquivo.netrcou o parâmetro auth pararepository_ctx.download()erepository_ctx.download_and_extract().Pode ser especificado várias vezes para configurar vários helpers.
Consulte https://blog.engflow.com/2023/10/09/configuring-bazels-credential-helper/ para ver instruções.
- Padrão de
--credential_helper_cache_duration=<An immutable length of time.>: "30m" -
Por quanto tempo armazenar credenciais em cache se o assistente de credenciais não retornar um prazo de validade. Mudar o valor dessa flag limpa o cache.
- Padrão de
--credential_helper_timeout=<An immutable length of time.>: "10s" -
Configura o tempo limite de um assistente de credencial.
Se os ajudantes de credenciais não responderem dentro desse período, a invocação vai falhar.
--curses=<yes, no or auto>padrão: "auto"-
Use controles de cursor do terminal para minimizar a saída de rolagem.
--disk_cache=<a path>padrão: consulte a descrição-
Um caminho para um diretório em que o Bazel pode ler e gravar ações e saídas de ações. Se o diretório não existir, ele será criado.
--[no]enable_platform_specific_configpadrão: "true"-
Se for "true", o Bazel vai coletar linhas de configuração específicas do SO do host em arquivos bazelrc. Por exemplo, se o SO host for Linux e você executar "bazel build", o Bazel vai coletar linhas que começam com "build:linux". Os identificadores de SO compatíveis são linux, macos, windows, freebsd e openbsd. Ativar essa flag é equivalente a usar --config=linux no Linux, --config=windows no Windows etc.
--experimental_action_cache_gc_idle_delay=<An immutable length of time.>padrão: "5m"-
Por quanto tempo o servidor precisa ficar inativo antes de uma coleta de lixo do cache de ações ser tentada. Ineficaz, a menos que --experimental_action_cache_gc_max_age seja diferente de zero.
--experimental_action_cache_gc_max_age=<An immutable length of time.>padrão: "0"-
Se definido como um valor diferente de zero, o cache de ações será coletado periodicamente para remover entradas mais antigas que essa idade. A coleta de lixo ocorre em segundo plano quando o servidor fica inativo, conforme determinado pelas flags --experimental_action_cache_gc_idle_delay e --experimental_action_cache_gc_threshold.
- Padrão de
--experimental_action_cache_gc_threshold=<an integer in 0-100 range>: "10" -
A porcentagem de entradas de cache de ações desatualizadas necessárias para que a coleta de lixo seja acionada. Ineficaz, a menos que --experimental_action_cache_gc_max_age seja diferente de zero.
--experimental_disk_cache_gc_idle_delay=<An immutable length of time.>padrão: "5m"-
Por quanto tempo o servidor precisa ficar inativo antes que uma coleta de lixo do cache de disco ocorra. Para especificar a política de coleta de lixo, defina --experimental_disk_cache_gc_max_size e/ou --experimental_disk_cache_gc_max_age.
--experimental_disk_cache_gc_max_age=<An immutable length of time.>padrão: "0"-
Se definido como um valor positivo, o cache de disco será coletado periodicamente como lixo para remover entradas mais antigas do que essa idade. Se definido em conjunto com --experimental_disk_cache_gc_max_size, os dois critérios serão aplicados. A coleta de lixo ocorre em segundo plano quando o servidor fica inativo, conforme determinado pela flag --experimental_disk_cache_gc_idle_delay.
--experimental_disk_cache_gc_max_size=<a size in bytes, optionally followed by a K, M, G or T multiplier>padrão: "0"-
Se definido como um valor positivo, o cache de disco será coletado periodicamente para ficar abaixo desse tamanho. Se definido em conjunto com --experimental_disk_cache_gc_max_age, os dois critérios serão aplicados. A coleta de lixo ocorre em segundo plano quando o servidor fica inativo, conforme determinado pela flag --experimental_disk_cache_gc_idle_delay.
--[no]experimental_enable_thread_dumppadrão: "false"-
Define se os despejos de encadeamento serão ativados. Se for verdadeiro, o Bazel vai despejar o estado de todas as linhas de execução (incluindo as virtuais) em um arquivo a cada --experimental_thread_dump_interval ou após a execução da ação ficar inativa por --experimental_thread_dump_action_execution_inactivity_duration. Os despejos serão gravados no diretório <output_base>/server/thread_dumps/.
Tags:
bazel_monitoring - Padrão de
--experimental_install_base_gc_max_age=<An immutable length of time.>: "30d" -
Quanto tempo uma base instalada precisa ficar sem uso antes de se qualificar para a coleta de lixo. Se for diferente de zero, o servidor tentará coletar lixo de outras bases de instalação quando estiver inativo.
--[no]experimental_rule_extension_apipadrão: "true"-
Ativar a API experimental de extensão de regra e as APIs de subregras
Tags:
loading_and_analysis,experimental --experimental_thread_dump_action_execution_inactivity_duration=<An immutable length of time.>padrão: "0"-
Despeje as linhas de execução quando a execução da ação estiver inativa por esse período. Se for zero, nenhum despejo de encadeamento será gravado para a execução de ações inativas.
Tags:
bazel_monitoring --experimental_thread_dump_interval=<An immutable length of time.>padrão: "0"-
Com que frequência fazer o despejo das linhas de execução periodicamente. Se for zero, nenhum despejo de encadeamento será gravado periodicamente.
Tags:
bazel_monitoring --[no]experimental_windows_watchfspadrão: "false"-
Se for "true", a compatibilidade experimental com Windows para --watchfs será ativada. Caso contrário, --watchfs é uma operação nula no Windows. Não se esqueça de ativar --watchfs.
--google_auth_scopes=<comma-separated list of options>padrão: "https://www.googleapis.com/auth/cloud-platform"-
Uma lista separada por vírgulas de escopos de autenticação do Google Cloud.
--google_credentials=<a string>padrão: consulte a descrição-
Especifica o arquivo de onde as credenciais de autenticação serão extraídas. Consulte https://cloud.google.com/docs/authentication para mais detalhes.
--[no]google_default_credentialspadrão: "false"-
Se é necessário usar as "Credenciais padrão do aplicativo do Google" para autenticação. Consulte https://cloud.google.com/docs/authentication para mais detalhes. Essa configuração está desativada por padrão.
--grpc_keepalive_time=<An immutable length of time.>padrão: consulte a descrição-
Configura pings de manutenção de atividade para conexões gRPC de saída. Se definido, o Bazel envia pings após esse período sem operações de leitura na conexão, mas apenas se houver pelo menos uma chamada gRPC pendente. Os horários são tratados como granularidade de segundo. É um erro definir um valor menor que um segundo. Por padrão, os pings de manutenção de atividade estão desativados. Coordene com o proprietário do serviço antes de ativar essa configuração. Por exemplo, para definir um valor de 30 segundos para essa flag, faça o seguinte: --grpc_keepalive_time=30s
- Padrão de
--grpc_keepalive_timeout=<An immutable length of time.>: "20s" -
Configura um tempo limite de keep-alive para conexões gRPC de saída. Se os pings de atividade em tempo real estiverem ativados com --grpc_keepalive_time, o Bazel vai atingir o tempo limite de uma conexão se não receber uma resposta de ping após esse período. Os horários são tratados como granularidade de segundo. É um erro definir um valor menor que um segundo. Se os pings de manutenção de atividade estiverem desativados, essa configuração será ignorada.
--[no]incompatible_disable_non_executable_java_binarypadrão: "false"-
Se for verdadeiro, java_binary sempre será executável. O atributo create_executable será removido.
--[no]incompatible_repo_env_ignores_action_envpadrão: "true"-
Se for verdadeiro, <code>--action_env=NAME=VALUE</code> não vai mais afetar os ambientes de regra do repositório e de extensão do módulo.
--inject_repository=<an equals-separated mapping of repository name to path>vários usos são acumulados-
Adiciona um novo repositório com um caminho local no formato <nome do repositório>=<caminho>. Isso só entra em vigor com --enable_bzlmod e é equivalente a adicionar um
local_repositorycorrespondente ao arquivo MODULE.bazel do módulo raiz viause_repo_rule. Se o caminho fornecido for absoluto, ele será usado como está. Se for relativo, ele será relativo ao diretório de trabalho atual. Se o caminho fornecido começar com "%workspace%", ele será relativo à raiz do espaço de trabalho, que é a saída debazel info workspace. Se o caminho fornecido estiver vazio, remova todas as injeções anteriores. --invocation_id=<a UUID>padrão: ""-
Identificador exclusivo, no formato UUID, do comando em execução. Se especificado explicitamente, a exclusividade precisa ser garantida pelo caller. O UUID é impresso em stderr, no BEP e no protocolo de execução remota.
--override_repository=<an equals-separated mapping of repository name to path>vários usos são acumulados-
Substitua um repositório por um caminho local no formato <nome do repositório>=<caminho>. Se o caminho fornecido for absoluto, ele será usado como está. Se for relativo, ele será relativo ao diretório de trabalho atual. Se o caminho fornecido começar com "%workspace%", ele será relativo à raiz do espaço de trabalho, que é a saída de
bazel info workspace. Se o caminho especificado estiver vazio, remova todas as substituições anteriores. --[no]progress_in_terminal_titlepadrão: "false"-
Mostrar o progresso do comando no título do terminal. Útil para ver o que o Bazel está fazendo quando há várias guias de terminal.
--[no]show_progresspadrão: "true"-
Mostrar mensagens de progresso durante um build.
--show_progress_rate_limit=<a double>padrão: "0.2"-
Número mínimo de segundos entre as mensagens de progresso na saída.
--[no]show_timestampspadrão: "false"-
Incluir carimbos de data/hora nas mensagens
--tls_certificate=<a string>padrão: consulte a descrição-
Especifique um caminho para um certificado TLS confiável para assinar certificados de servidor.
--tls_client_certificate=<a string>padrão: consulte a descrição-
Especifique o certificado TLS do cliente a ser usado. Também é necessário fornecer uma chave do cliente para ativar a autenticação do cliente.
--tls_client_key=<a string>padrão: consulte a descrição-
Especifique a chave do cliente TLS a ser usada. Também é necessário fornecer um certificado do cliente para ativar a autenticação do cliente.
- Padrão de
--ui_actions_shown=<an integer>: "8" -
Número de ações simultâneas mostradas na barra de progresso detalhada. Cada ação aparece em uma linha separada. A barra de progresso sempre mostra pelo menos um, e todos os números menores que 1 são mapeados para 1.
Tags:
terminal_output --[no]watchfspadrão: "false"-
No Linux/macOS: se for "true", o Bazel tentará usar o serviço de observação de arquivos do sistema operacional para mudanças locais em vez de verificar todos os arquivos em busca de uma mudança. No Windows, essa flag não faz nada, mas pode ser ativada junto com --experimental_windows_watchfs. Em qualquer SO: o comportamento é indefinido se o espaço de trabalho estiver em um sistema de arquivos de rede e os arquivos forem editados em uma máquina remota.
Opções de Aquery
Herda todas as opções de build.
- Opções relacionadas à saída e à semântica da consulta:
--aspect_deps=<off, conservative or precise>padrão: "conservative"-
Como resolver dependências de aspectos quando o formato de saída é um dos seguintes: {xml,proto,record}. "off" significa que nenhuma dependência de aspecto é resolvida. "conservative" (o padrão) significa que todas as dependências de aspecto declaradas são adicionadas, independente de terem recebido a classe de regra de dependências diretas. "precise" significa que apenas os aspectos possivelmente ativos são adicionados, considerando a classe de regra das dependências diretas. O modo preciso exige o carregamento de outros pacotes para avaliar uma única meta, o que o torna mais lento do que os outros modos. Além disso, mesmo o modo preciso não é completamente preciso: a decisão de calcular um aspecto é tomada na fase de análise, que não é executada durante "bazel query".
Tags:
build_file_semantics --[no]consistent_labelspadrão: "false"-
Se ativado, todo comando de consulta vai emitir rótulos como se a função <code>str</code> do Starlark fosse aplicada a uma instância <code>Label</code>. Isso é útil para ferramentas que precisam corresponder à saída de diferentes comandos de consulta e/ou rótulos emitidos por regras. Se não estiver ativado, os formatadores de saída poderão emitir nomes de repositórios aparentes (em relação ao repositório principal) para tornar a saída mais legível.
Tags:
terminal_output --[no]experimental_explicit_aspectspadrão: "false"-
aquery, cquery: se as ações geradas por aspectos devem ser incluídas na saída. query: no-op (os aspectos são sempre seguidos).
Tags:
terminal_output --[no]graph:factoredpadrão: "true"-
Se for "verdadeiro", o gráfico será emitido "fatorado", ou seja, nós topologicamente equivalentes serão mesclados e os rótulos concatenados. Essa opção só é aplicável a --output=graph.
Tags:
terminal_output --graph:node_limit=<an integer>padrão: "512"-
O comprimento máximo da string de rótulo para um nó de gráfico na saída. Rótulos mais longos serão truncados. -1 significa que não haverá truncamento. Essa opção só é aplicável a --output=graph.
Tags:
terminal_output --[no]implicit_depspadrão: "true"-
Se ativadas, as dependências implícitas serão incluídas no gráfico de dependências em que a consulta opera. Uma dependência implícita é aquela que não é especificada explicitamente no arquivo BUILD, mas é adicionada pelo Bazel. Para cquery, essa opção controla a filtragem de toolchains resolvidas.
Tags:
build_file_semantics --[no]include_artifactspadrão: "true"-
Inclui nomes das entradas e saídas de ação na saída (potencialmente grande).
Tags:
terminal_output --[no]include_aspectspadrão: "true"-
aquery, cquery: se as ações geradas por aspectos devem ser incluídas na saída. query: no-op (os aspectos são sempre seguidos).
Tags:
terminal_output --[no]include_commandlinepadrão: "true"-
Inclui o conteúdo das linhas de comando de ação na saída (potencialmente grande).
Tags:
terminal_output --[no]include_file_write_contentspadrão: "false"-
Inclua o conteúdo do arquivo para as ações FileWrite, SourceSymlinkManifest e RepoMappingManifest (potencialmente grandes).
Tags:
terminal_output --[no]include_param_filespadrão: "false"-
Inclua o conteúdo dos arquivos de parâmetros usados no comando (potencialmente grandes). Observação: ativar essa flag também ativa automaticamente a flag --include_commandline.
Tags:
terminal_output --[no]include_pruned_inputspadrão: "true"-
Inclui entradas de ação que foram removidas durante a execução da ação. Afeta apenas ações que descobrem entradas e foram executadas em uma invocação anterior. Só entra em vigor se --include_artifacts também estiver definido.
Tags:
terminal_output --[no]incompatible_package_group_includes_double_slashpadrão: "true"-
Se ativado, ao gerar o atributo
packagesde package_group, o//inicial não será omitido. --[no]infer_universe_scopepadrão: "false"-
Se definido e --universe_scope não estiver definido, um valor de --universe_scope será inferido como a lista de padrões de destino exclusivos na expressão de consulta. O valor --universe_scope inferido para uma expressão de consulta que usa funções com escopo de universo (por exemplo,
allrdeps) pode não ser o que você quer. Portanto, use essa opção apenas se souber o que está fazendo. Acesse https://bazel.build/reference/query#sky-query para ver detalhes e exemplos. Se --universe_scope estiver definido, o valor dessa opção será ignorado. Observação: essa opção se aplica apenas aquery(ou seja, nãocquery).Tags:
loading_and_analysis --[no]line_terminator_nullpadrão: "false"-
Se cada formato é encerrado com \0 em vez de uma nova linha.
Tags:
terminal_output --[no]nodep_depspadrão: "true"-
Se ativada, as dependências dos atributos "nodep" serão incluídas no gráfico de dependências em que a consulta opera. Um exemplo comum de atributo "nodep" é "visibility". Execute e analise a saída de
info build-languagepara saber mais sobre todos os atributos "nodep" na linguagem de build.Tags:
build_file_semantics --output=<a string>padrão: "text"-
O formato em que os resultados da aquery serão impressos. Os valores permitidos para aquery são: text, textproto, proto, streamed_proto, jsonproto.
Tags:
terminal_output --output_file=<a string>padrão: ""-
Quando especificado, os resultados da consulta são gravados diretamente nesse arquivo, e nada é impresso no stream de saída padrão (stdout) do Bazel. Em comparativos, isso geralmente é mais rápido do que <code>bazel query > file</code>.
Tags:
terminal_output --[no]proto:default_valuespadrão: "true"-
Se for "true", os atributos cujo valor não for especificado explicitamente no arquivo BUILD serão incluídos. Caso contrário, eles serão omitidos. Essa opção é válida para --output=proto
Tags:
terminal_output --[no]proto:definition_stackpadrão: "false"-
Preencha o campo proto definition_stack, que registra para cada instância de regra a pilha de chamadas do Starlark no momento em que a classe da regra foi definida.
Tags:
terminal_output --[no]proto:flatten_selectspadrão: "true"-
Se ativado, os atributos configuráveis criados por select() serão simplificados. Para tipos de lista, a representação simplificada é uma lista que contém cada valor do mapa de seleção exatamente uma vez. Os tipos escalares são nivelados como nulos.
Tags:
build_file_semantics --[no]proto:include_attribute_source_aspectspadrão: "false"-
Preencha o campo proto source_aspect_name de cada atributo com o aspecto de origem de onde ele veio (string vazia se não veio de nenhum).
Tags:
terminal_output --[no]proto:include_starlark_rule_envpadrão: "true"-
Use o ambiente starlark no valor do atributo $internal_attr_hash gerado. Isso garante que a definição da regra do Starlark (e as importações transitivas dela) façam parte desse identificador.
Tags:
terminal_output --[no]proto:include_synthetic_attribute_hashpadrão: "false"-
Se o atributo $internal_attr_hash deve ser calculado e preenchido.
Tags:
terminal_output --[no]proto:instantiation_stackpadrão: "false"-
Preencha a pilha de chamadas de instanciação de cada regra. Isso exige que a pilha esteja presente
Tags:
terminal_output --[no]proto:locationspadrão: "true"-
Determina se as informações de local devem ser geradas na saída proto.
Tags:
terminal_output - Padrão de
--proto:output_rule_attrs=<comma-separated list of options>: "all" -
Lista separada por vírgulas de atributos a serem incluídos na saída. O padrão é todos os atributos. Defina como uma string vazia para não gerar nenhum atributo. Essa opção é válida para --output=proto.
Tags:
terminal_output --[no]proto:rule_classespadrão: "false"-
Preencha o campo "rule_class_key" de cada regra e, para a primeira regra com um determinado "rule_class_key", preencha também o campo proto "rule_class_info". O campo "rule_class_key" identifica exclusivamente uma classe de regra, e o campo "rule_class_info" é uma definição de API de classe de regra no formato Stardoc.
Tags:
terminal_output --[no]proto:rule_inputs_and_outputspadrão: "true"-
Se os campos "rule_input" e "rule_output" devem ser preenchidos.
Tags:
terminal_output --query_file=<a string>padrão: ""-
Se definido, a consulta vai ler o arquivo nomeado aqui, em vez da linha de comando. É um erro especificar um arquivo aqui e uma consulta de linha de comando.
Tags:
changes_inputs --[no]relative_locationspadrão: "false"-
Se for "true", o local dos arquivos BUILD nas saídas XML e proto será relativo. Por padrão, a saída de local é um caminho absoluto e não é consistente em todas as máquinas. Defina essa opção como "true" para ter um resultado consistente em todas as máquinas.
Tags:
terminal_output --[no]skyframe_statepadrão: "false"-
Sem realizar análises extras, despeje o gráfico de ações atual do Skyframe. Observação: no momento, não é possível especificar uma meta com --skyframe_state. Essa flag só está disponível com --output=proto ou --output=textproto.
Tags:
terminal_output --[no]tool_depspadrão: "true"-
Consulta: se desativado, as dependências da "configuração de execução" não serão incluídas no gráfico de dependências em que a consulta opera. Uma aresta de dependência de "configuração de execução", como a de qualquer regra "proto_library" para o compilador de protocolo, geralmente aponta para uma ferramenta executada durante a build, em vez de uma parte do mesmo programa "target". Cquery: se desativado, filtra todos os destinos configurados que cruzam uma transição de execução do destino de nível superior que descobriu esse destino configurado. Isso significa que, se o destino de nível superior estiver na configuração de destino, somente os destinos configurados que também estiverem na configuração de destino serão retornados. Se o destino de nível superior estiver na configuração de execução, somente os destinos configurados para execução serão retornados. Essa opção NÃO exclui toolchains resolvidas.
Tags:
build_file_semantics --universe_scope=<comma-separated list of options>padrão: ""-
Um conjunto de padrões de destino separados por vírgulas (aditivos e subtrativos). A consulta pode ser realizada no universo definido pelo fechamento transitivo das metas especificadas. Essa opção é usada para os comandos "query" e "cquery". Para cquery, a entrada dessa opção são os destinos em que todas as respostas são criadas. Portanto, essa opção pode afetar configurações e transições. Se essa opção não for especificada, os destinos de nível superior serão considerados os destinos analisados da expressão de consulta. Observação: para cquery, não especificar essa opção pode fazer com que o build seja interrompido se os destinos analisados da expressão de consulta não puderem ser criados com opções de nível superior.
Tags:
loading_and_analysis
- Opções que controlam a execução do build:
--[no]experimental_persistent_aar_extractorpadrão: "false"-
Ative o extrator aar permanente usando workers.
Tags:
execution,experimental --[no]experimental_remotable_source_manifestspadrão: "false"-
Se as ações do manifesto de origem podem ser executadas remotamente
--[no]experimental_split_coverage_postprocessingpadrão: "false"-
Se for verdadeiro, o Bazel vai executar o pós-processamento de cobertura para o teste em uma nova geração.
Tags:
execution,experimental --[no]experimental_strict_fileset_outputpadrão: "false"-
Se essa opção estiver ativada, os conjuntos de arquivos vão tratar todos os artefatos de saída como arquivos regulares. Eles não vão percorrer diretórios nem serão sensíveis a symlinks.
Tags:
execution,experimental --[no]incompatible_modify_execution_info_additivepadrão: "true"-
Quando ativada, a transmissão de várias flags --modify_execution_info é cumulativa. Quando desativada, apenas a última flag é considerada.
Tags:
execution,affects_outputs,loading_and_analysis,incompatible_change --modify_execution_info=<regex=[+-]key,regex=[+-]key,...>vários usos são acumulados-
Adicione ou remova chaves das informações de execução de uma ação com base no mnemônico dela. Aplicável apenas a ações que oferecem suporte a informações de execução. Muitas ações comuns oferecem suporte a informações de execução, por exemplo, Genrule, CppCompile, Javac, StarlarkAction e TestRunner. Ao especificar vários valores, a ordem é importante porque muitas expressões regulares podem ser aplicadas ao mesmo mnemônico.
Sintaxe: "regex=[+-]key,regex=[+-]key,...".
Exemplos: '.=+x,.=-y,.=+z' adiciona "x" e "z" e remove "y" das informações de execução de todas as ações. "Genrule=+requires-x" adiciona "requires-x" às informações de execução de todas as ações Genrule. '(?!Genrule).=-requires-x' remove 'requires-x' das informações de execução de todas as ações que não são Genrule.
--persistent_android_dex_desugar-
Ative ações persistentes de dex e dessugar do Android usando workers.
Expande para:
--internal_persistent_android_dex_desugar
--strategy=Desugar=worker
--strategy=DexBuilder=worker --persistent_android_resource_processor-
Ative o processador de recursos persistentes do Android usando workers.
Expande para:
--internal_persistent_busybox_tools
--strategy=AaptPackage=worker
--strategy=AndroidResourceParser=worker
--strategy=AndroidResourceValidator=worker
--strategy=AndroidResourceCompiler=worker
--strategy=RClassGenerator=worker
--strategy=AndroidResourceLink=worker
--strategy=AndroidAapt2=worker
--strategy=AndroidAssetMerger=worker
--strategy=AndroidResourceMerger=worker
--strategy=AndroidCompiledResourceMerger=worker
--strategy=ManifestMerger=worker
--strategy=AndroidManifestMerger=worker
--strategy=Aapt2Optimize=worker
--strategy=AARGenerator=worker
--strategy=ProcessDatabinding=worker
--strategy=GenerateDataBindingBaseClasses=worker --persistent_multiplex_android_dex_desugar-
Ative ações persistentes e multiplexadas de dex e dessugar do Android usando workers.
Expande para:
--persistent_android_dex_desugar
--internal_persistent_multiplex_android_dex_desugar --persistent_multiplex_android_resource_processor-
Ative o processador de recursos do Android multiplexado persistente usando workers.
Expande para:
--persistent_android_resource_processor
--modify_execution_info=AaptPackage=+supports-multiplex-workers
--modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
--modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
--modify_execution_info=RClassGenerator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
--modify_execution_info=AndroidAapt2=+supports-multiplex-workers
--modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
--modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
--modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
--modify_execution_info=ManifestMerger=+supports-multiplex-workers
--modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
--modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
--modify_execution_info=AARGenerator=+supports-multiplex-workers --persistent_multiplex_android_tools-
Ativar ferramentas Android persistentes e multiplexadas (dexing, desugaring, processamento de recursos).
Expande para:
--internal_persistent_multiplex_busybox_tools
--persistent_multiplex_android_resource_processor
--persistent_multiplex_android_dex_desugar --[no]use_target_platform_for_testspadrão: "false"-
Se for "true", use a plataforma de destino para executar testes em vez do grupo de execução de teste.
Tags:
execution
- Opções que configuram o conjunto de ferramentas usado para a execução de ações:
--android_compiler=<a string>padrão: consulte a descrição-
O compilador de destino do Android.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state --android_manifest_merger=<legacy, android or force_android>padrão: "android"-
Seleciona o combinador de manifestos a ser usado para regras android_binary. Flag para ajudar na transição do combinador legado para o combinador do manifesto do Android.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state --android_platforms=<a build target label>padrão: ""-
Define as plataformas usadas pelas segmentações android_binary. Se várias plataformas forem especificadas, o binário será um APK fat, que contém binários nativos para cada plataforma de destino especificada.
Tags:
changes_inputs,loading_and_analysis,loses_incremental_state --cc_output_directory_tag=<a string>padrão: ""-
Especifica um sufixo a ser adicionado ao diretório de configuração.
Tags:
affects_outputs --compiler=<a string>padrão: consulte a descrição-
O compilador C++ a ser usado para compilar o destino.
Tags:
loading_and_analysis,execution --coverage_output_generator=<a build target label>default: "@bazel_tools//tools/test:lcov_merger"-
Local do binário usado para pós-processar relatórios de cobertura bruta. Precisa ser uma meta binária. O padrão é "//tools/test:lcov_merger".
--coverage_report_generator=<a build target label>default: "@bazel_tools//tools/test:coverage_report_generator"-
Local do binário usado para gerar relatórios de cobertura. Precisa ser uma meta binária. O padrão é "//tools/test:coverage_report_generator".
--coverage_support=<a build target label>default: "@bazel_tools//tools/test:coverage_support"-
Localização dos arquivos de suporte necessários nas entradas de todas as ações de teste que coletam cobertura de código. O padrão é "//tools/test:coverage_support".
--custom_malloc=<a build target label>padrão: consulte a descrição-
Especifica uma implementação de malloc personalizada. Essa configuração substitui os atributos malloc nas regras de build.
Tags:
changes_inputs,affects_outputs --[no]experimental_include_xcode_execution_requirementspadrão: "false"-
Se definido, adicione um requisito de execução "requires-xcode:{version}" a todas as ações do Xcode. Se a versão do Xcode tiver um rótulo hifenizado, adicione também um requisito de execução "requires-xcode-label:{version_label}".
Tags:
loses_incremental_state,loading_and_analysis,execution,experimental --[no]experimental_prefer_mutual_xcodepadrão: "true"-
Se for "true", use o Xcode mais recente disponível local e remotamente. Se for "false" ou se não houver versões disponíveis em comum, use a versão local do Xcode selecionada com xcode-select.
--extra_execution_platforms=<comma-separated list of options>padrão: ""-
As plataformas disponíveis como plataformas de execução para realizar ações. As plataformas podem ser especificadas por segmentação exata ou como um padrão de segmentação. Essas plataformas serão consideradas antes daquelas declaradas no arquivo WORKSPACE por register_execution_platforms(). Essa opção só pode ser definida uma vez. Instâncias posteriores vão substituir as configurações de flag anteriores.
Tags:
execution --extra_toolchains=<comma-separated list of options>vários usos são acumulados-
As regras da cadeia de ferramentas a serem consideradas durante a resolução da cadeia de ferramentas. As toolchains podem ser especificadas por destino exato ou como um padrão de destino. Esses conjuntos de ferramentas serão considerados antes daqueles declarados no arquivo WORKSPACE por register_toolchains().
--grte_top=<a label>padrão: consulte a descrição-
Um rótulo para uma biblioteca libc registrada. O valor padrão é selecionado pela cadeia de ferramentas crosstool, e quase nunca é necessário substituir esse valor.
--host_compiler=<a string>padrão: consulte a descrição-
Flag de nenhuma operação. Será removido em uma versão futura.
Tags:
loading_and_analysis,execution --host_grte_top=<a label>padrão: consulte a descrição-
Se especificada, essa configuração vai substituir o diretório de nível superior da libc (--grte_top) para a configuração de execução.
--host_platform=<a build target label>default: "@bazel_tools//tools:host_platform"-
O rótulo de uma regra de plataforma que descreve o sistema host.
--[no]incompatible_bazel_test_exec_run_underpadrão: "true"-
Se ativado, "bazel test --run_under=//:runner" vai criar "//:runner" na configuração de execução. Se estiver desativado, ele vai criar "//:runner" na configuração de destino. O Bazel executa testes em máquinas de execução, então o primeiro é mais correto. Isso não afeta "bazel run", que sempre cria "`--run_under=//foo" na configuração de destino.
--[no]incompatible_builtin_objc_strip_actionpadrão: "true"-
Se uma ação de remoção deve ser emitida como parte da vinculação objc.
--[no]incompatible_dont_enable_host_nonhost_crosstool_featurespadrão: "true"-
Se for "true", o Bazel não vai ativar os recursos "host" e "nonhost" na cadeia de ferramentas do C++ (consulte https://github.com/bazelbuild/bazel/issues/7407 para mais informações).
--[no]incompatible_enable_apple_toolchain_resolutionpadrão: "false"-
Use a resolução da cadeia de ferramentas para selecionar o SDK da Apple para regras da Apple (Starlark e nativas).
--[no]incompatible_remove_legacy_whole_archivepadrão: "true"-
Se for "true", o Bazel não vai vincular dependências de biblioteca como um arquivo inteiro por padrão. Consulte https://github.com/bazelbuild/bazel/issues/7362 para instruções de migração.
--[no]incompatible_strip_executable_safelypadrão: "false"-
Se for verdadeiro, a ação de remoção para executáveis usará a flag -x, que não interrompe a resolução dinâmica de símbolos.
-
Use objetos compartilhados de interface se forem compatíveis com o conjunto de ferramentas. Todas as toolchains ELF são compatíveis com essa configuração.
Tags:
loading_and_analysis,affects_outputs,affects_outputs --ios_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Especifica a versão do SDK para iOS a ser usada para criar aplicativos iOS. Se não for especificado, usará a versão padrão do SDK para iOS de "xcode_version".
Tags:
loses_incremental_state --macos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Especifica a versão do SDK do macOS a ser usada para criar aplicativos desse sistema operacional. Se não for especificado, usará a versão padrão do SDK do macOS de "xcode_version".
Tags:
loses_incremental_state --minimum_os_version=<a string>padrão: consulte a descrição-
A versão mínima do SO que sua compilação segmenta.
--platform_mappings=<a main workspace-relative path>padrão: ""-
O local de um arquivo de mapeamento que descreve qual plataforma usar se nenhuma estiver definida ou quais flags definir quando uma plataforma já existir. Precisa ser relativo à raiz do espaço de trabalho principal. O padrão é "platform_mappings", um arquivo diretamente na raiz do espaço de trabalho.
Tags:
affects_outputs,changes_inputs,loading_and_analysis,non_configurable --platforms=<a build target label>padrão: ""-
Os rótulos das regras de plataforma que descrevem as plataformas de destino para o comando atual.
--python_path=<a string>padrão: consulte a descrição-
O caminho absoluto do interpretador Python invocado para executar destinos Python na plataforma de destino. Obsoleto. Desativado por --incompatible_use_python_toolchains.
--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Especifica a versão do SDK do tvOS a ser usada para criar aplicativos desse sistema operacional. Se não for especificado, usará a versão padrão do SDK do tvOS de "xcode_version".
Tags:
loses_incremental_state --[no]use_platforms_in_apple_crosstool_transitionpadrão: "false"-
Faz com que apple_crosstool_transition volte a usar o valor da flag
--platformsem vez do--cpulegado quando necessário.Tags:
loading_and_analysis --watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Especifica a versão do SDK do watchOS a ser usada para criar aplicativos do watchOS. Se não for especificado, usará a versão padrão do SDK do watchOS de "xcode_version".
Tags:
loses_incremental_state --xcode_version=<a string>padrão: consulte a descrição-
Se especificado, usa o Xcode da versão fornecida para ações de build relevantes. Se não for especificado, vai usar a versão padrão do executor do Xcode.
Tags:
loses_incremental_state --xcode_version_config=<a build target label>default: "@bazel_tools//tools/cpp:host_xcodes"-
O rótulo da regra xcode_config a ser usada para selecionar a versão do Xcode na configuração de build.
- Opções que controlam a saída do comando:
--[no]apple_generate_dsympadrão: "false"-
Se é necessário gerar arquivos de símbolos de depuração (.dSYM).
--[no]build_runfile_linkspadrão: "true"-
Se for verdadeiro, vai criar florestas de symlink de runfiles para todos os destinos. Se for "false", grave-os apenas quando exigido por uma ação, teste ou comando de execução local.
Tags:
affects_outputs --[no]build_runfile_manifestspadrão: "true"-
Se verdadeiro, grava manifestos de runfiles para todos os destinos. Se for "false", omita-os. Os testes locais não serão executados quando for "false".
Tags:
affects_outputs --[no]build_test_dwppadrão: "false"-
Se ativado, ao criar testes em C++ de forma estática e com fusão, o arquivo .dwp do binário de teste também será criado automaticamente.
--cc_proto_library_header_suffixes=<comma-separated set of options>padrão: ".pb.h"-
Define os sufixos dos arquivos de cabeçalho que uma cc_proto_library cria.
- Padrão de
--cc_proto_library_source_suffixes=<comma-separated set of options>: ".pb.cc" -
Define os sufixos dos arquivos de origem que uma cc_proto_library cria.
--[no]experimental_proto_descriptor_sets_include_source_infopadrão: "false"-
Executa ações extras para versões alternativas da API Java em uma proto_library.
--[no]experimental_save_feature_statepadrão: "false"-
Salve o estado dos recursos ativados e solicitados como uma saída da compilação.
Tags:
affects_outputs,experimental --fission=<a set of compilation modes>padrão: "no"-
Especifica quais modos de compilação usam a fissão para compilações e vinculações em C++. Pode ser qualquer combinação de {'fastbuild', 'dbg', 'opt'} ou os valores especiais 'yes' para ativar todos os modos e 'no' para desativar todos os modos.
Tags:
loading_and_analysis,action_command_lines,affects_outputs --[no]incompatible_always_include_files_in_datapadrão: "true"-
Se for verdadeiro, as regras nativas vão adicionar <code>DefaultInfo.files</code> de dependências de dados aos runfiles, o que corresponde ao comportamento recomendado para regras do Starlark (https://bazel.build/extending/rules#runfiles_features_to_avoid).
--[no]incompatible_compact_repo_mapping_manifestpadrão: "false"-
Se ativado, o arquivo <binary>.repo_mapping vai emitir o mapeamento de repositório de uma extensão de módulo apenas uma vez, em vez de uma vez para cada repositório gerado pela extensão que contribui com runfiles.
--incompatible_disable_select_on=<comma-separated set of options>padrão: ""-
Lista de flags para as quais o uso em select() está desativado.
Tags:
loading_and_analysis,incompatible_change,non_configurable --[no]incompatible_filegroup_runfiles_for_datapadrão: "true"-
Se for verdadeiro, os runfiles dos destinos listados no atributo "srcs" estarão disponíveis para os destinos que consomem o filegroup como uma dependência de dados.
Tags:
incompatible_change --[no]objc_generate_linkmappadrão: "false"-
Especifica se um arquivo linkmap será gerado.
Tags:
affects_outputs --[no]save_tempspadrão: "false"-
Se definido, as saídas temporárias do gcc serão salvas. Eles incluem arquivos .s (código de assembler), .i (C pré-processado) e .ii (C++ pré-processado).
Tags:
affects_outputs
- Opções que permitem ao usuário configurar a saída pretendida, afetando o valor dela, e não a existência:
--action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable>vários usos são acumulados-
Especifica o conjunto de variáveis de ambiente disponíveis para ações com configuração de destino. As variáveis podem ser especificadas por <code>name</code>, em que o valor é extraído do ambiente de invocação, pelo par <code>name=value</code>, que define o valor independente do ambiente de invocação, ou por <code>=name</code>, que desativa a variável com esse nome. Essa opção pode ser usada várias vezes. Para opções fornecidas para a mesma variável, a mais recente vence. Para variáveis diferentes, as opções são acumuladas. <br> A menos que <code>--incompatible_repo_env_ignores_action_env</code> seja verdadeiro, todos os pares <code>name=value</code> estarão disponíveis para as regras do repositório.
Tags:
action_command_lines --allowed_cpu_values=<comma-separated set of options>padrão: ""-
Valores permitidos para a flag "--cpu".
Tags:
changes_inputs,affects_outputs --[no]android_databinding_use_androidxpadrão: "true"-
Gere arquivos de vinculação de dados compatíveis com o AndroidX. Isso só é usado com a vinculação de dados v2. Essa flag não faz nada.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --[no]android_databinding_use_v3_4_argspadrão: "true"-
Use a vinculação de dados do Android v2 com o argumento 3.4.0. Essa flag não faz nada.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --android_dynamic_mode=<off, default or fully>padrão: "off"-
Determina se as dependências C++ das regras do Android serão vinculadas dinamicamente quando um cc_binary não criar explicitamente uma biblioteca compartilhada. "default" significa que o bazel vai escolher se a vinculação será dinâmica. "Totalmente" significa que todas as bibliotecas serão vinculadas dinamicamente. "off" significa que todas as bibliotecas serão vinculadas principalmente no modo estático.
- Padrão de
--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency>: "alphabetical" -
Define a ordem dos manifestos transmitidos à ferramenta de mescla de manifestos para binários do Android. ALPHABETICAL significa que os manifestos são classificados por caminho em relação ao execroot. ALPHABETICAL_BY_CONFIGURATION significa que os manifestos são classificados por caminhos relativos ao diretório de configuração no diretório de saída. DEPENDENCY significa que os manifestos são ordenados com o manifesto de cada biblioteca antes dos manifestos das dependências dela.
Tags:
action_command_lines,execution --[no]android_resource_shrinkingpadrão: "false"-
Ativa a redução de recursos para APKs android_binary que usam o ProGuard.
--[no]build_python_zippadrão: "auto"-
Criar zip executável do Python; ativado no Windows, desativado em outras plataformas
Tags:
affects_outputs --catalyst_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar binários do Apple Catalyst.
--[no]collect_code_coveragepadrão: "false"-
Se especificado, o Bazel vai instrumentar o código (usando instrumentação off-line sempre que possível) e coletar informações de cobertura durante os testes. Apenas os destinos que correspondem a --instrumentation_filter serão afetados. Normalmente, essa opção não deve ser especificada diretamente. Em vez disso, use o comando "bazel coverage".
Tags:
affects_outputs --compilation_mode=<fastbuild, dbg or opt>[-c] padrão: "fastbuild"-
Especifique o modo em que o binário será criado. Valores: "fastbuild", "dbg", "opt".
--conlyopt=<a string>vários usos são acumulados-
Opção adicional para transmitir ao gcc ao compilar arquivos de origem C.
--copt=<a string>vários usos são acumulados-
Outras opções para transmitir ao gcc.
--cpu=<a string>padrão: ""-
Descontinuada: essa flag não é usada internamente pelo Blaze, embora haja mapeamentos de plataforma legados para permitir a compatibilidade com versões anteriores. Não use essa flag. Em vez disso, use --platforms com uma definição de plataforma adequada.
Tags:
changes_inputs,affects_outputs --cs_fdo_absolute_path=<a string>padrão: consulte a descrição-
Use informações de perfil do CSFDO para otimizar a compilação. Especifique o nome do caminho absoluto do arquivo ZIP que contém o arquivo de perfil, um arquivo de perfil LLVM bruto ou indexado.
Tags:
affects_outputs --cs_fdo_instrument=<a string>padrão: consulte a descrição-
Gere binários com instrumentação FDO sensível ao contexto. Com o compilador Clang/LLVM, ele também aceita o nome do diretório em que os arquivos de perfil brutos serão despejados durante a execução.
Tags:
affects_outputs --cs_fdo_profile=<a build target label>padrão: consulte a descrição-
O cs_fdo_profile que representa o perfil sensível ao contexto a ser usado para otimização.
Tags:
affects_outputs --cxxopt=<a string>vários usos são acumulados-
Opção extra para transmitir ao gcc ao compilar arquivos de origem C++.
--define=<a 'name=value' assignment>vários usos são acumulados-
Cada opção "--define" especifica uma atribuição para uma variável de build. Em caso de vários valores para uma variável, o último vence.
Tags:
changes_inputs,affects_outputs --dynamic_mode=<off, default or fully>padrão: "default"-
Determina se os binários C++ serão vinculados dinamicamente. "default" significa que o Bazel vai escolher se a vinculação será dinâmica. "Totalmente" significa que todas as bibliotecas serão vinculadas dinamicamente. "off" significa que todas as bibliotecas serão vinculadas principalmente no modo estático.
--[no]enable_propeller_optimize_absolute_pathspadrão: "true"-
Se definido, qualquer uso de caminhos absolutos para a otimização do Propeller vai gerar um erro.
Tags:
affects_outputs --[no]enable_remaining_fdo_absolute_pathspadrão: "true"-
Se definido, qualquer uso de caminhos absolutos para FDO vai gerar um erro.
Tags:
affects_outputs --[no]enable_runfilespadrão: "auto"-
Ative a árvore de symlink de runfiles. Por padrão, ela fica desativada no Windows e ativada em outras plataformas.
Tags:
affects_outputs --exec_aspects=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de aspectos a serem aplicados a destinos configurados por execução, sejam eles de nível superior ou não. Este é um recurso experimental e está sujeito a mudanças.
Tags:
loading_and_analysis --experimental_action_listener=<a build target label>vários usos são acumulados-
Obsoleto, substituído por "aspectos". Use action_listener para anexar uma extra_action a ações de build atuais.
Tags:
execution,experimental --[no]experimental_android_compress_java_resourcespadrão: "false"-
Compactar recursos Java em APKs
--[no]experimental_android_databinding_v2padrão: "true"-
Use a vinculação de dados do Android v2. Essa flag não faz nada.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --[no]experimental_android_resource_shrinkingpadrão: "false"-
Ativa a redução de recursos para APKs android_binary que usam o ProGuard.
--[no]experimental_android_rewrite_dexes_with_rexpadrão: "false"-
usar a ferramenta rex para reescrever arquivos dex
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --[no]experimental_collect_code_coverage_for_generated_filespadrão: "false"-
Se especificado, o Bazel também vai gerar informações de cobertura de coleta para arquivos gerados.
Tags:
affects_outputs,experimental --experimental_objc_fastbuild_options=<comma-separated list of options>padrão: "-O0,-DDEBUG=1"-
Usa essas strings como opções do compilador objc fastbuild.
Tags:
action_command_lines --[no]experimental_omitfppadrão: "false"-
Se for verdadeiro, use libunwind para desenrolar a pilha e compile com -fomit-frame-pointer e -fasynchronous-unwind-tables.
--experimental_output_paths=<off or strip>padrão: "off"-
Qual modelo usar para onde as regras da árvore de saída gravam as saídas, principalmente para builds multiplataforma / multiconfiguração. Esse recurso é altamente experimental. Consulte https://github.com/bazelbuild/bazel/issues/6526 para mais detalhes. As ações do Starlark podem ativar o mapeamento de caminhos adicionando a chave "supports-path-mapping" ao dicionário "execution_requirements".
Tags:
loses_incremental_state,bazel_internal_configuration,affects_outputs,execution --experimental_override_platform_cpu_name=<a 'label=value' assignment>vários usos são acumulados-
Cada entrada precisa estar no formato "label=value", em que "label" se refere a uma plataforma e "value" é o nome abreviado desejado para substituir o nome da CPU da plataforma na variável de make $(TARGET_CPU) e no caminho de saída. Usado somente quando --experimental_platform_in_output_dir, --incompatible_target_cpu_from_platform ou --incompatible_bep_cpu_from_platform é verdadeiro. Tem a maior prioridade de nomenclatura.
Tags:
affects_outputs,experimental --[no]experimental_platform_in_output_dirpadrão: "false"-
Se for "true", um nome abreviado para a plataforma de destino será usado no nome do diretório de saída em vez da CPU. Se for "auto", isso só será aplicado à configuração de execução. O esquema exato é experimental e está sujeito a mudanças. Primeiro, no caso raro em que a opção "--platforms" não tem exatamente um valor, um hash da opção "platforms" é usado. Em seguida, se um nome abreviado para a plataforma atual foi registrado por --experimental_override_name_platform_in_output_dir, esse nome abreviado será usado. Em seguida, se --experimental_use_platforms_in_output_dir_legacy_heuristic estiver definido, use um nome abreviado com base no rótulo da plataforma atual. Por fim, um hash da opção de plataforma é usado como último recurso.
Tags:
affects_outputs,experimental --[no]experimental_py_binaries_include_labelpadrão: "false"-
Os destinos py_binary incluem o rótulo mesmo quando a inclusão de carimbos está desativada.
Tags:
affects_outputs,experimental --[no]experimental_use_llvm_covmappadrão: "false"-
Se especificado, o Bazel vai gerar informações de mapa de cobertura llvm-cov em vez de gcov quando collect_code_coverage estiver ativado.
Tags:
changes_inputs,affects_outputs,loading_and_analysis,experimental --[no]experimental_use_platforms_in_output_dir_legacy_heuristicpadrão: "true"-
Use essa flag apenas como parte de uma estratégia de migração ou teste sugerida. A heurística tem deficiências conhecidas. Por isso, recomendamos migrar para usar apenas --experimental_override_name_platform_in_output_dir.
Tags:
affects_outputs,experimental --fdo_instrument=<a string>padrão: consulte a descrição-
Gere binários com instrumentação FDO. Com o compilador Clang/LLVM, ele também aceita o nome do diretório em que os arquivos de perfil brutos serão despejados durante a execução.
Tags:
affects_outputs --fdo_optimize=<a string>padrão: consulte a descrição-
Use informações de perfil da FDO para otimizar a compilação. Especifique o nome de um arquivo zip que contenha uma árvore de arquivos .gcda, um arquivo afdo com um perfil automático ou um arquivo de perfil LLVM. Essa flag também aceita arquivos especificados como rótulos (por exemplo,
//foo/bar:file.afdo. Talvez seja necessário adicionar uma diretivaexports_filesao pacote correspondente) e rótulos que apontam para destinosfdo_profile. Essa flag será substituída pela regrafdo_profile.Tags:
affects_outputs --fdo_prefetch_hints=<a build target label>padrão: consulte a descrição-
Use dicas de pré-busca de cache.
Tags:
affects_outputs --fdo_profile=<a build target label>padrão: consulte a descrição-
O fdo_profile que representa o perfil a ser usado para otimização.
Tags:
affects_outputs --features=<a string>vários usos são acumulados-
Os recursos especificados serão ativados ou desativados por padrão para destinos criados na configuração de destino. Especificar -<recurso> desativa o recurso. Recursos negativos sempre substituem os positivos. Consulte também --host_features
Tags:
changes_inputs,affects_outputs --[no]force_picpadrão: "false"-
Se ativada, todas as compilações em C++ produzem código independente de posição ("-fPIC"), as vinculações preferem bibliotecas pré-criadas PIC em vez de bibliotecas não PIC, e as vinculações produzem executáveis independentes de posição ("-pie").
--host_action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable>vários usos são acumulados-
Especifica o conjunto de variáveis de ambiente disponíveis para ações com configurações de execução. As variáveis podem ser especificadas por nome, caso em que o valor será extraído do ambiente de invocação, pelo par nome=valor, que define o valor independente do ambiente de invocação, ou por <code>=name</code>, que desativa a variável desse nome. Essa opção pode ser usada várias vezes. Para opções fornecidas para a mesma variável, a mais recente vence. Para variáveis diferentes, as opções são acumuladas.
Tags:
action_command_lines --host_compilation_mode=<fastbuild, dbg or opt>padrão: "opt"-
Especifique o modo em que as ferramentas usadas durante a criação serão criadas. Valores: "fastbuild", "dbg", "opt".
--host_conlyopt=<a string>vários usos são acumulados-
Opção extra para transmitir ao compilador C ao compilar arquivos de origem C (mas não C++) nas configurações de execução.
--host_copt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas ao compilador C para ferramentas criadas nas configurações de execução.
--host_cpu=<a string>padrão: ""-
A CPU do host.
Tags:
changes_inputs,affects_outputs --host_cxxopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas ao compilador C++ para ferramentas criadas nas configurações de execução.
--host_features=<a string>vários usos são acumulados-
Os recursos especificados serão ativados ou desativados por padrão para destinos criados na configuração de execução. Especificar -<recurso> desativa o recurso. Recursos negativos sempre substituem os positivos.
Tags:
changes_inputs,affects_outputs --host_linkopt=<a string>vários usos são acumulados-
Opção extra para transmitir ao vinculador ao vincular ferramentas nas configurações de execução.
--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do macOS para destinos de host. Se não for especificado, usará "macos_sdk_version".
Tags:
loses_incremental_state --host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>vários usos são acumulados-
Outras opções para transmitir seletivamente ao compilador C/C++ ao compilar determinados arquivos nas configurações de execução. Essa opção pode ser transmitida várias vezes. Sintaxe: regex_filter@option_1,option_2,...,option_n. Em que regex_filter representa uma lista de padrões de expressões regulares de inclusão e exclusão (consulte também --instrumentation_filter). option_1 a option_n representam opções arbitrárias de linha de comando. Se uma opção tiver uma vírgula, ela precisa ser colocada entre aspas com uma barra invertida. As opções podem conter @. Somente o primeiro @ é usado para dividir a string. Exemplo: --host_per_file_copt=//foo/.*.cc,-//foo/bar.cc@-O0 adiciona a opção de linha de comando -O0 à linha de comando do gcc de todos os arquivos cc em //foo/, exceto bar.cc.
--[no]incompatible_auto_exec_groupspadrão: "false"-
Quando ativado, um grupo de execução é criado automaticamente para cada cadeia de ferramentas usada por uma regra. Para que isso funcione, a regra precisa especificar o parâmetro
toolchainnas ações dela. Para mais informações, consulte https://github.com/bazelbuild/bazel/issues/17134. --[no]incompatible_merge_genfiles_directorypadrão: "true"-
Se for verdadeiro, o diretório "genfiles" será incorporado ao diretório "bin".
--[no]incompatible_target_cpu_from_platformpadrão: "true"-
Se especificado, o valor da restrição de CPU (@platforms//cpu:cpu) da plataforma de destino será usado para definir a variável de criação $(TARGET_CPU).
--[no]instrument_test_targetspadrão: "false"-
Quando a cobertura está ativada, especifica se as regras de teste de instrumentação devem ser consideradas. Quando definido, as regras de teste incluídas por --instrumentation_filter são instrumentadas. Caso contrário, as regras de teste são sempre excluídas da instrumentação de cobertura.
Tags:
affects_outputs --instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>padrão: "-/javatests[/:],-/test/java[/:]"-
Quando a cobertura está ativada, apenas as regras com nomes incluídos pelo filtro especificado baseado em regex são instrumentadas. As regras com o prefixo "-" são excluídas. Somente regras que não são de teste são instrumentadas, a menos que a flag --instrument_test_targets esteja ativada.
Tags:
affects_outputs --ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do iOS para simuladores e dispositivos de destino. Se não for especificado, usará "ios_sdk_version".
Tags:
loses_incremental_state --ios_multi_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar um ios_application. O resultado é um binário universal que contém todas as arquiteturas especificadas.
--[no]legacy_whole_archivepadrão: "true"-
Obsoleto, substituído por --incompatible_remove_legacy_whole_archive. Consulte https://github.com/bazelbuild/bazel/issues/7362 para mais detalhes. Quando ativada, use --whole-archive para regras cc_binary que tenham linkshared=True e linkstatic=True ou "-static" em linkopts. Isso é apenas para compatibilidade com versões anteriores. Uma alternativa melhor é usar alwayslink=1 quando necessário.
--linkopt=<a string>vários usos são acumulados-
Opção extra a ser transmitida para o gcc ao vincular.
--ltobackendopt=<a string>vários usos são acumulados-
Opção adicional para transmitir à etapa de back-end do LTO (em --features=thin_lto).
--ltoindexopt=<a string>vários usos são acumulados-
Opção adicional para transmitir à etapa de indexação do LTO (em --features=thin_lto).
--macos_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para as quais criar binários do Apple macOS.
--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do macOS para destinos. Se não for especificado, usará "macos_sdk_version".
Tags:
loses_incremental_state --memprof_profile=<a build target label>padrão: consulte a descrição-
Usar o perfil memprof.
Tags:
affects_outputs --[no]objc_debug_with_GLIBCXXpadrão: "false"-
Se definido e o modo de compilação for "dbg", defina GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC e GLIBCPP_CONCEPT_CHECKS.
Tags:
action_command_lines --[no]objc_enable_binary_strippingpadrão: "false"-
Se é necessário realizar remoções de símbolos e código morto em binários vinculados. A remoção de binários será realizada se esta flag e --compilation_mode=opt forem especificadas.
Tags:
action_command_lines --objccopt=<a string>vários usos são acumulados-
Opções extras a serem transmitidas para o gcc ao compilar arquivos de origem Objective-C/C++.
Tags:
action_command_lines --per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>vários usos são acumulados-
Outras opções para transmitir seletivamente ao gcc ao compilar determinados arquivos. Essa opção pode ser transmitida várias vezes. Sintaxe: regex_filter@option_1,option_2,...,option_n. Em que regex_filter representa uma lista de padrões de expressões regulares de inclusão e exclusão (consulte também --instrumentation_filter). option_1 a option_n representam opções arbitrárias de linha de comando. Se uma opção tiver uma vírgula, ela precisa ser colocada entre aspas com uma barra invertida. As opções podem conter @. Somente o primeiro @ é usado para dividir a string. Exemplo: --per_file_copt=//foo/.*.cc,-//foo/bar.cc@-O0 adiciona a opção de linha de comando -O0 à linha de comando gcc de todos os arquivos cc em //foo/, exceto bar.cc.
--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>vários usos são acumulados-
Outras opções para transmitir seletivamente ao back-end do LTO (em --features=thin_lto) ao compilar determinados objetos de back-end. Essa opção pode ser transmitida várias vezes. Sintaxe: regex_filter@option_1,option_2,...,option_n. Em que regex_filter representa uma lista de padrões de expressão regular de inclusão e exclusão, e option_1 a option_n representam opções arbitrárias de linha de comando. Se uma opção tiver uma vírgula, ela precisa ser colocada entre aspas com uma barra invertida. As opções podem conter @. Somente o primeiro @ é usado para dividir a string. Exemplo: --per_file_ltobackendopt=//foo/.*.o,-//foo/bar.o@-O0 adiciona a opção de linha de comando -O0 à linha de comando do back-end LTO de todos os arquivos o em //foo/, exceto bar.o.
--platform_suffix=<a string>padrão: consulte a descrição-
Especifica um sufixo a ser adicionado ao diretório de configuração.
Tags:
loses_incremental_state,affects_outputs,loading_and_analysis --propeller_optimize=<a build target label>padrão: consulte a descrição-
Use as informações do perfil do Propeller para otimizar o destino do build.Um perfil do Propeller precisa consistir em pelo menos um de dois arquivos: um perfil cc e um perfil ld. Essa flag aceita um rótulo de build que precisa se referir aos arquivos de entrada do perfil do Propeller. Por exemplo, o arquivo BUILD que define o rótulo, em a/b/BUILD:propeller_optimize( name = "propeller_profile", cc_profile = "propeller_cc_profile.txt", ld_profile = "propeller_ld_profile.txt",)Talvez seja necessário adicionar uma diretiva exports_files ao pacote correspondente para tornar esses arquivos visíveis ao Bazel. A opção precisa ser usada como: --propeller_optimize=//a/b:propeller_profile
--propeller_optimize_absolute_cc_profile=<a string>padrão: consulte a descrição-
Nome do caminho absoluto do arquivo cc_profile para builds otimizados do Propeller.
Tags:
affects_outputs --propeller_optimize_absolute_ld_profile=<a string>padrão: consulte a descrição-
Nome do caminho absoluto do arquivo ld_profile para builds otimizados do Propeller.
Tags:
affects_outputs --run_under=<a prefix in front of command>padrão: consulte a descrição-
Prefixo a ser inserido antes dos executáveis dos comandos "test" e "run". Se o valor for "foo -bar" e a linha de comando de execução for "test_binary -baz", a linha de comando final será "foo -bar test_binary -baz".Isso também pode ser um rótulo para um destino executável. Alguns exemplos são: "valgrind", "strace", "strace -c", "valgrind --quiet --num-callers=20", "//package:target", "//package:target --options".
Tags:
action_command_lines -
Se for "true", as bibliotecas nativas com funcionalidade idêntica serão compartilhadas entre diferentes destinos.
--[no]stamppadrão: "false"-
Adicionar carimbo aos binários com a data, o nome de usuário, o nome do host, as informações do espaço de trabalho etc.
Tags:
affects_outputs - Padrão de
--strip=<always, sometimes or never>: "sometimes" -
Especifica se os binários e as bibliotecas compartilhadas devem ser removidos (usando "-Wl,--strip-debug"). O valor padrão "sometimes" significa remover se --compilation_mode=fastbuild.
Tags:
affects_outputs --stripopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas para a remoção ao gerar um binário "<name>.stripped".
--tvos_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar binários do Apple tvOS.
--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do tvOS para simuladores e dispositivos de destino. Se não for especificado, usará "tvos_sdk_version".
Tags:
loses_incremental_state --visionos_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar binários do Apple visionOS.
--watchos_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar binários do Apple watchOS.
--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do watchOS para simuladores e dispositivos de destino. Se não for especificado, usará "watchos_sdk_version".
Tags:
loses_incremental_state --xbinary_fdo=<a build target label>padrão: consulte a descrição-
Use informações de perfil do XbinaryFDO para otimizar a compilação. Especifique o nome do perfil binário cruzado padrão. Quando a opção é usada com --fdo_instrument/--fdo_optimize/--fdo_profile, essas opções sempre prevalecem como se xbinary_fdo nunca fosse especificado.
Tags:
affects_outputs
- Opções que afetam a rigidez com que o Bazel aplica entradas de build válidas (definições de regras, combinações de flags etc.):
--[no]check_visibilitypadrão: "true"-
Se desativado, os erros de visibilidade nas dependências de destino serão rebaixados para avisos.
--[no]desugar_for_androidpadrão: "true"-
Define se o bytecode Java 8 deve ser simplificado antes da conversão para DEX.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state --[no]desugar_java8_libspadrão: "false"-
Se as bibliotecas Java 8 compatíveis devem ser incluídas em apps para dispositivos legados.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --[no]enforce_constraintspadrão: "true"-
Verifica os ambientes com que cada destino é compatível e informa erros se algum destino tiver dependências que não oferecem suporte aos mesmos ambientes.
Tags:
build_file_semantics --[no]experimental_check_desugar_depspadrão: "true"-
Se é necessário verificar novamente a dessugarização correta no nível binário do Android.
--[no]experimental_enforce_transitive_visibilitypadrão: "false"-
Se verdadeiro, permite que package()s definam o atributo transitive_visibility para restringir quais pacotes podem depender deles.
Tags:
build_file_semantics,experimental --experimental_one_version_enforcement=<off, warning or error>padrão: "OFF"-
Quando ativada, essa opção exige que uma regra java_binary não contenha mais de uma versão do mesmo arquivo de classe no classpath. Essa aplicação pode interromper o build ou apenas resultar em avisos.
Tags:
loading_and_analysis --experimental_strict_java_deps=<off, warn, error, strict or default>padrão: "default"-
Se for verdadeiro, verifica se um destino Java declara explicitamente todos os destinos usados diretamente como dependências.
--[no]incompatible_check_testonly_for_output_filespadrão: "false"-
Se ativado, verifique testonly para destinos de pré-requisito que são arquivos de saída pesquisando o testonly da regra geradora. Isso corresponde à verificação de visibilidade.
--[no]incompatible_disable_native_android_rulespadrão: "false"-
Se ativada, o uso direto das regras nativas do Android será desativado. Use as regras do Starlark Android em https://github.com/bazelbuild/rules_android
--[no]incompatible_disable_native_apple_binary_rulepadrão: "false"-
Não faz nada. Mantido aqui para compatibilidade com versões anteriores.
--[no]one_version_enforcement_on_java_testspadrão: "true"-
Quando ativada e com experimental_one_version_enforcement definido como um valor diferente de NONE, impõe uma versão em destinos java_test. Essa flag pode ser desativada para melhorar a performance do teste incremental, mas isso pode fazer com que possíveis violações de uma versão sejam perdidas.
Tags:
loading_and_analysis --python_native_rules_allowlist=<a build target label>padrão: consulte a descrição-
Uma lista de permissões (destino package_group) a ser usada ao aplicar --incompatible_python_disallow_native_rules.
Tags:
loading_and_analysis --[no]strict_filesetspadrão: "false"-
Se essa opção estiver ativada, os conjuntos de arquivos que cruzam os limites do pacote serão informados como erros.
--strict_proto_deps=<off, warn, error, strict or default>padrão: "error"-
A menos que esteja OFF, verifica se um destino proto_library declara explicitamente todos os destinos usados diretamente como dependências.
Tags:
build_file_semantics,eagerness_to_exit,incompatible_change --strict_public_imports=<off, warn, error, strict or default>padrão: "off"-
A menos que esteja OFF, verifica se um destino proto_library declara explicitamente como exportados todos os destinos usados em "import public".
Tags:
build_file_semantics,eagerness_to_exit,incompatible_change --[no]strict_system_includespadrão: "false"-
Se for "true", os cabeçalhos encontrados por caminhos de inclusão do sistema (-isystem) também precisarão ser declarados.
--target_environment=<a build target label>vários usos são acumulados-
Declara o ambiente de destino deste build. Precisa ser uma referência de rótulo a uma regra de "ambiente". Se especificado, todos os destinos de nível superior precisam ser compatíveis com esse ambiente.
Tags:
changes_inputs
- Opções que afetam as saídas de assinatura de um build:
--apk_signing_method=<v1, v2, v1_v2 or v4>padrão: "v1_v2"-
Implementação a ser usada para assinar APKs
Tags:
action_command_lines,affects_outputs,loading_and_analysis --[no]device_debug_entitlementspadrão: "true"-
Se definido e o modo de compilação não for "opt", os apps objc vão incluir direitos de depuração ao assinar.
Tags:
changes_inputs --ios_signing_cert_name=<a string>padrão: consulte a descrição-
Nome do certificado a ser usado para assinatura do iOS. Se não for definido, vai voltar ao perfil de provisionamento. Pode ser a preferência de identidade do chaveiro do certificado ou (substring) do nome comum do certificado, conforme a página de manual do codesign (IDENTIDADES DE ASSINATURA).
Tags:
action_command_lines
- Essa opção afeta a semântica da linguagem Starlark ou a API de build acessível a arquivos BUILD, .bzl ou WORKSPACE.:
--[no]incompatible_disallow_sdk_frameworks_attributespadrão: "false"-
Se for "true", não permita os atributos sdk_frameworks e weak_sdk_frameworks em objc_library e objc_import.
--[no]incompatible_objc_alwayslink_by_defaultpadrão: "false"-
Se for verdadeiro, defina o valor padrão como verdadeiro para atributos alwayslink em objc_library e objc_import.
--[no]incompatible_python_disallow_native_rulespadrão: "false"-
Quando verdadeiro, um erro ocorre ao usar as regras py_* integradas. Em vez disso, as regras rule_python devem ser usadas. Consulte https://github.com/bazelbuild/bazel/issues/17773 para mais informações e instruções de migração.
- Opções que regem o comportamento do ambiente de teste ou do executor de testes:
--[no]allow_analysis_failurespadrão: "false"-
Se for "true", uma falha na análise de um destino de regra vai resultar na propagação de uma instância de "AnalysisFailureInfo" contendo a descrição do erro, em vez de resultar em uma falha de build.
Tags:
loading_and_analysis,experimental - Padrão de
--analysis_testing_deps_limit=<an integer>: "2000" -
Define o número máximo de dependências transitivas usando um atributo de regra com uma transição de configuração for_analysis_testing. Exceder esse limite vai resultar em um erro de regra.
Tags:
loading_and_analysis --[no]break_build_on_parallel_dex2oat_failurepadrão: "false"-
Se for "true", as falhas na ação dex2oat vão interromper o build em vez de executar dex2oat durante o tempo de execução do teste.
Tags:
loading_and_analysis,experimental --default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100>vários usos são acumulados-
Substitua a quantidade padrão de recursos para testes. O formato esperado é <resource>=<value>. Se um único número positivo for especificado como <value>, ele vai substituir os recursos padrão para todos os tamanhos de teste. Se quatro números separados por vírgulas forem especificados, eles vão substituir a quantidade de recursos para os tamanhos de teste pequeno, médio, grande e enorme, respectivamente. Os valores também podem ser HOST_RAM/HOST_CPU, seguidos opcionalmente por [-|]<float> (por exemplo, memory=HOST_RAM.1,HOST_RAM*.2,HOST_RAM*.3,HOST_RAM*.4). Os recursos de teste padrão especificados por essa flag são substituídos por recursos explícitos especificados em tags.
--[no]experimental_android_use_parallel_dex2oatpadrão: "false"-
Use dex2oat em paralelo para acelerar o android_test.
Tags:
loading_and_analysis,host_machine_resource_optimizations,experimental --[no]ios_memleakspadrão: "false"-
Ativa a verificação de vazamentos de memória em destinos ios_test.
Tags:
action_command_lines --ios_simulator_device=<a string>padrão: consulte a descrição-
O dispositivo a ser simulado ao executar um aplicativo iOS no simulador, por exemplo, "iPhone 6". Para conferir uma lista de dispositivos, execute "xcrun simctl list devicetypes" na máquina em que o simulador será executado.
Tags:
test_runner --ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
A versão do iOS a ser executada no simulador durante a execução ou o teste. Isso é ignorado para regras ios_test se um dispositivo de destino for especificado na regra.
Tags:
test_runner --runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once>vários usos são acumulados-
Especifica o número de vezes que cada teste será executado. Se alguma dessas tentativas falhar por qualquer motivo, todo o teste será considerado falho. Normalmente, o valor especificado é apenas um número inteiro. Exemplo: --runs_per_test=3 vai executar todos os testes três vezes. Sintaxe alternativa: regex_filter@runs_per_test. Em que runs_per_test representa um valor inteiro e regex_filter representa uma lista de padrões de expressões regulares de inclusão e exclusão (consulte também --instrumentation_filter). Exemplo: --runs_per_test=//foo/.,-//foo/bar/.@3 executa todos os testes em //foo/, exceto aqueles em foo/bar, três vezes. Essa opção pode ser transmitida várias vezes. O argumento transmitido mais recentemente que corresponde tem precedência. Se nada corresponder, o teste será executado apenas uma vez.
--test_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable>vários usos são acumulados-
Especifica variáveis de ambiente adicionais a serem injetadas no ambiente do executor de testes. As variáveis podem ser especificadas por <code>name</code>, nesse caso, o valor será lido do ambiente do cliente Bazel, ou pelo par <code>name=value</code>. As variáveis definidas anteriormente podem ser desdefinidas usando <code>=name</code>. Essa opção pode ser usada várias vezes para especificar várias variáveis. Usado apenas pelo comando "bazel test".
Tags:
test_runner --test_timeout=<a single integer or comma-separated list of 4 integers>padrão: "-1"-
Substitui os valores padrão de tempo limite de teste para tempos limite de teste (em segundos). Se um único valor inteiro positivo for especificado, ele vai substituir todas as categorias. Se quatro números inteiros separados por vírgulas forem especificados, eles vão substituir os tempos limite para curto, moderado, longo e eterno (nessa ordem). Em qualquer uma das formas, um valor de -1 informa ao Blaze para usar os tempos limite padrão para essa categoria.
--[no]zip_undeclared_test_outputspadrão: "false"-
Se for "true", as saídas de teste não declaradas serão arquivadas em um arquivo ZIP.
Tags:
test_runner
- Opções que acionam otimizações do tempo de build:
--[no]experimental_filter_library_jar_with_program_jarpadrão: "false"-
Filtre o ProGuard ProgramJar para remover todas as classes também presentes no LibraryJar.
Tags:
action_command_lines,experimental --[no]experimental_inmemory_dotd_filespadrão: "true"-
Se ativada, os arquivos .d do C++ serão transmitidos na memória diretamente dos nós de build remoto em vez de serem gravados em disco.
Tags:
loading_and_analysis,execution,affects_outputs,experimental --[no]experimental_inmemory_jdeps_filespadrão: "true"-
Se ativada, os arquivos de dependência (.jdeps) gerados de compilações Java serão transmitidos na memória diretamente dos nós de build remoto em vez de serem gravados no disco.
Tags:
loading_and_analysis,execution,affects_outputs,experimental --[no]experimental_retain_test_configuration_across_testonlypadrão: "false"-
Quando ativada, a flag --trim_test_configuration não vai remover a configuração de teste para regras marcadas como testonly=1. Isso reduz problemas de conflito de ações quando regras que não são de teste dependem de regras cc_test. Não tem efeito se "--trim_test_configuration" for "false".
Tags:
loading_and_analysis,loses_incremental_state,experimental --[no]experimental_unsupported_and_brittle_include_scanningpadrão: "false"-
Indica se é necessário restringir as entradas à compilação em C/C++ analisando as linhas #include dos arquivos de entrada. Isso pode melhorar a performance e a incrementalidade, diminuindo o tamanho das árvores de entrada de compilação. No entanto, ele também pode interromper builds porque o scanner de inclusão não implementa totalmente a semântica do pré-processador C. Em particular, ele não entende diretivas #include dinâmicas e ignora a lógica condicional do pré-processador. Use por sua conta e risco. Todos os problemas relacionados a essa denúncia que forem enviados serão encerrados.
Tags:
loading_and_analysis,execution,changes_inputs,experimental --[no]incremental_dexingpadrão: "true"-
Faz a maior parte do trabalho de dexing separadamente para cada arquivo Jar.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state --[no]objc_use_dotd_pruningpadrão: "true"-
Se definido, os arquivos .d emitidos pelo clang serão usados para remover o conjunto de entradas transmitidas para compilações objc.
--[no]process_headers_in_dependenciespadrão: "false"-
Ao criar um destino //a:a, processe os cabeçalhos em todos os destinos de que //a:a depende (se o processamento de cabeçalho estiver ativado para a cadeia de ferramentas).
Tags:
execution --[no]trim_test_configurationpadrão: "true"-
Quando ativada, as opções relacionadas a testes serão limpas abaixo do nível superior do build. Quando essa flag está ativa, os testes não podem ser criados como dependências de regras que não são de teste, mas as mudanças nas opções relacionadas a testes não fazem com que as regras que não são de teste sejam analisadas novamente.
- Opções que afetam a verbosidade, o formato ou o local do registro em log:
- Padrão de
--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>: "-.*" -
Imprime informações de depuração durante a resolução da cadeia de ferramentas. A flag usa uma regex, que é verificada em relação a tipos de cadeia de ferramentas e destinos específicos para ver qual depurar. É possível separar várias expressões regulares com vírgulas, e cada uma delas é verificada separadamente. Observação: a saída dessa flag é muito complexa e provavelmente só será útil para especialistas em resolução de toolchain.
Tags:
terminal_output --[no]verbose_visibility_errorspadrão: "false"-
Se ativados, os erros de visibilidade incluem mais informações de diagnóstico.
- Opções que especificam ou alteram uma entrada genérica para um comando do Bazel que não se enquadra em outras categorias:
--flag_alias=<a 'name=value' flag alias>vários usos são acumulados-
Define um nome abreviado para uma flag do Starlark. Ele usa um único par de chave-valor no formato "<chave>=<valor>" como argumento.
Tags:
changes_inputs,non_configurable --[no]incompatible_default_to_explicit_init_pypadrão: "false"-
Essa flag muda o comportamento padrão para que os arquivos init.py não sejam mais criados automaticamente nos arquivos de execução de destinos Python. Precisamente, quando um destino py_binary ou py_test tem legacy_create_init definido como "auto" (o padrão), ele é tratado como falso se e somente se essa flag estiver definida. Consulte https://github.com/bazelbuild/bazel/issues/10076.
- Opções diversas, não categorizadas de outra forma:
--[no]cache_test_results[-t] padrão: "auto"-
Se definido como "auto", o Bazel vai executar novamente um teste somente se: (1) o Bazel detectar mudanças no teste ou nas dependências dele, (2) o teste for marcado como externo, (3) várias execuções de teste forem solicitadas com --runs_per_test ou(4) o teste falhou anteriormente. Se definido como "yes", o Bazel armazena em cache todos os resultados de testes, exceto aqueles marcados como externos. Se definido como "no", o Bazel não armazena em cache nenhum resultado de teste.
- Padrão de
--[no]experimental_cancel_concurrent_tests: "never" -
Se for "on_failed" ou "on_passed", o Blaze vai cancelar os testes em execução simultânea na primeira execução com esse resultado. Isso só é útil em combinação com --runs_per_test_detects_flakes.
--[no]experimental_fetch_all_coverage_outputspadrão: "false"-
Se for verdadeiro, o Bazel vai buscar todo o diretório de dados de cobertura para cada teste durante uma execução de cobertura.
--[no]experimental_generate_llvm_lcovpadrão: "false"-
Se for verdadeiro, a cobertura do clang vai gerar um relatório LCOV.
- Padrão de
--experimental_java_classpath=<off, javabuilder, bazel or bazel_no_fallback>: "bazel" -
Ativa caminhos de classe reduzidos para compilações Java.
--[no]experimental_run_android_lint_on_java_rulespadrão: "false"-
Se as fontes java_* precisam ser validadas.
Tags:
affects_outputs,experimental --[no]explicit_java_test_depspadrão: "false"-
Especifique explicitamente uma dependência do JUnit ou do Hamcrest em um java_test em vez de obter acidentalmente das dependências do TestRunner. No momento, só funciona para bazel.
--host_java_launcher=<a build target label>padrão: consulte a descrição-
O iniciador Java usado por ferramentas executadas durante um build.
--host_javacopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas para o javac ao criar ferramentas executadas durante um build.
--host_jvmopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas para a VM Java ao criar ferramentas executadas durante o build. Essas opções serão adicionadas às opções de inicialização da VM de cada destino java_binary.
--[no]incompatible_check_sharding_supportpadrão: "true"-
Se for verdadeiro, o Bazel vai falhar em um teste fragmentado se o executor de testes não indicar que oferece suporte à fragmentação ao tocar no arquivo no caminho em TEST_SHARD_STATUS_FILE. Se for "false", um executor de testes que não oferece suporte a fragmentação vai fazer com que todos os testes sejam executados em cada fragmento.
Tags:
incompatible_change --[no]incompatible_exclusive_test_sandboxedpadrão: "true"-
Se for verdadeiro, os testes exclusivos serão executados com a estratégia em sandbox. Adicione a tag "local" para forçar uma execução de teste exclusiva localmente
Tags:
incompatible_change --[no]incompatible_strict_action_envpadrão: "false"-
Se for "true", o Bazel usará um ambiente com um valor estático para PATH e não vai herdar LD_LIBRARY_PATH. Use --action_env=ENV_VARIABLE se quiser herdar variáveis de ambiente específicas do cliente, mas observe que isso pode impedir o armazenamento em cache entre usuários se um cache compartilhado for usado.
--j2objc_translation_flags=<comma-separated list of options>vários usos são acumulados-
Outras opções a serem transmitidas para a ferramenta J2ObjC.
--java_debug-
Faz com que a máquina virtual Java de um teste Java aguarde uma conexão de um depurador compatível com JDWP (como jdb) antes de iniciar o teste. Implica -test_output=streamed.
Expande para:
--test_arg=--wrapper_script_flag=--debug
--test_output=streamed
--test_strategy=exclusive
--test_timeout=9999
--nocache_test_results --[no]java_depspadrão: "true"-
Gere informações de dependência (por enquanto, classpath de tempo de compilação) por destino Java.
--[no]java_header_compilationpadrão: "true"-
Compile ijars diretamente da origem.
--java_language_version=<a string>padrão: ""-
A versão da linguagem Java
--java_launcher=<a build target label>padrão: consulte a descrição-
O inicializador Java a ser usado ao criar binários Java. Se essa flag for definida como uma string vazia, o iniciador do JDK será usado. O atributo "launcher" substitui essa flag.
- Padrão de
--java_runtime_version=<a string>: "local_jdk" -
A versão do ambiente de execução do Java
--javacopt=<a string>vários usos são acumulados-
Outras opções para transmitir ao javac.
--jvmopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas para a VM Java. Essas opções serão adicionadas às opções de inicialização da VM de cada destino java_binary.
--legacy_main_dex_list_generator=<a build target label>padrão: consulte a descrição-
Especifica um binário a ser usado para gerar a lista de classes que precisam estar no dex principal ao compilar o multidex legado.
--optimizing_dexer=<a build target label>padrão: consulte a descrição-
Especifica um binário a ser usado para fazer dexing sem sharding.
--plugin=<a build target label>vários usos são acumulados-
Plug-ins a serem usados no build. No momento, funciona com java_plugin.
--proguard_top=<a build target label>padrão: consulte a descrição-
Especifica qual versão do ProGuard usar para remoção de código ao criar um binário Java.
--proto_compiler=<a build target label>default: "@bazel_tools//tools/proto:protoc"-
O rótulo do proto-compilador.
--[no]proto_profilepadrão: "true"-
Se o profile_path será transmitido ao compilador proto.
--proto_profile_path=<a build target label>padrão: consulte a descrição-
O perfil a ser transmitido ao compilador proto como profile_path. Se não for definido, mas --proto_profile for verdadeiro (o padrão), vai inferir o caminho de --fdo_optimize.
--proto_toolchain_for_cc=<a build target label>default: "@bazel_tools//tools/proto:cc_toolchain"-
Rótulo de proto_lang_toolchain() que descreve como compilar protos C++
--proto_toolchain_for_j2objc=<a build target label>padrão: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain"-
Rótulo de proto_lang_toolchain() que descreve como compilar protos j2objc.
--proto_toolchain_for_java=<a build target label>default: "@bazel_tools//tools/proto:java_toolchain"-
Rótulo de proto_lang_toolchain() que descreve como compilar protos Java.
--proto_toolchain_for_javalite=<a build target label>default: "@bazel_tools//tools/proto:javalite_toolchain"-
Rótulo de proto_lang_toolchain() que descreve como compilar protos do JavaLite.
--protocopt=<a string>vários usos são acumulados-
Outras opções para transmitir ao compilador protobuf.
Tags:
affects_outputs --[no]runs_per_test_detects_flakespadrão: "false"-
Se for "true", qualquer fragmento em que pelo menos uma execução/tentativa seja aprovada e pelo menos uma execução/tentativa falhe vai receber o status "FLAKY".
--shell_executable=<a path>padrão: consulte a descrição-
Caminho absoluto para o executável do shell que o Bazel vai usar. Se não estiver definido, mas a variável de ambiente BAZEL_SH estiver definida na primeira invocação do Bazel (que inicia um servidor do Bazel), o Bazel vai usar essa variável. Se nenhum dos dois estiver definido, o Bazel usará um caminho padrão codificado, dependendo do sistema operacional em que ele é executado (Windows: c:/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, todos os outros: /bin/bash). Usar um shell incompatível com bash pode causar falhas de build ou de tempo de execução dos binários gerados.
Tags:
loading_and_analysis --test_arg=<a string>vários usos são acumulados-
Especifica outras opções e argumentos que devem ser transmitidos para o executável de teste. Pode ser usado várias vezes para especificar vários argumentos. Se vários testes forem executados, cada um deles vai receber argumentos idênticos. Usado apenas pelo comando "bazel test".
--test_filter=<a string>padrão: consulte a descrição-
Especifica um filtro para encaminhar ao framework de teste. Usado para limitar os testes executados. Isso não afeta quais destinos são criados.
--test_result_expiration=<an integer>padrão: "-1"-
Essa opção foi descontinuada e não tem efeito.
--[no]test_runner_fail_fastpadrão: "false"-
Encaminha a opção de falha rápida para o executor de testes. O executor de testes precisa interromper a execução na primeira falha.
--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce>padrão: "explicit"-
Especifique a estratégia para o sharding de teste: "explicit" para usar o sharding somente se o atributo "shard_count" BUILD estiver presente. "disabled" para nunca usar o sharding de teste. "forced=k" para forçar "k" fragmentos para teste, independente do atributo "shard_count" BUILD.
--tool_java_language_version=<a string>padrão: ""-
A versão da linguagem Java usada para executar as ferramentas necessárias durante um build.
--tool_java_runtime_version=<a string>padrão: "remotejdk_11"-
A versão do ambiente de execução Java usada para executar ferramentas durante o build.
--[no]use_ijarspadrão: "true"-
Se ativada, essa opção faz com que a compilação Java use jars de interface. Isso resulta em uma compilação incremental mais rápida, mas as mensagens de erro podem ser diferentes.
Opções de build
- Opções que controlam a execução do build:
-
Se definido, permite que pelo menos uma ação seja executada mesmo que o recurso seja insuficiente ou esteja indisponível.
Tags:
execution --[no]check_up_to_datepadrão: "false"-
Não execute o build, apenas verifique se ele está atualizado. Se todas as metas estiverem atualizadas, a build será concluída. Se alguma etapa precisar ser executada, um erro será informado e o build vai falhar.
Tags:
execution - Padrão de
--dynamic_local_execution_delay=<an integer>: "1000" -
Quantos milissegundos a execução local deve ser atrasada se a execução remota foi mais rápida durante uma build pelo menos uma vez?
--dynamic_local_strategy=<a '[name=]value1[,..,valueN]' assignment>vários usos são acumulados-
As estratégias locais, em ordem, a serem usadas para o mnemônico especificado. A primeira estratégia aplicável é usada. Por exemplo,
worker,sandboxedexecuta ações que oferecem suporte a workers persistentes usando a estratégia de worker e todas as outras usando a estratégia em sandbox. Se nenhum mnemônico for fornecido, a lista de estratégias será usada como substituta para todos os mnemônicos. A lista de substituição padrão éworker,sandboxedouworker,sandboxed,standaloneseexperimental_local_lockfree_outputestiver definido. Usa [mnemonic=]local_strategy[,local_strategy,...] --dynamic_remote_strategy=<a '[name=]value1[,..,valueN]' assignment>vários usos são acumulados-
As estratégias remotas, em ordem, a serem usadas para o mnemônico especificado. A primeira estratégia aplicável é usada. Se nenhum mnemônico for fornecido, a lista de estratégias será usada como substituta para todos os mnemônicos. A lista de substituição padrão é
remote, então essa flag geralmente não precisa ser definida explicitamente. Usa [mnemonic=]remote_strategy[,remote_strategy,...] --[no]experimental_async_executionpadrão: "false"-
Se definido como "true", o Bazel poderá executar a ação em uma linha de execução virtual. O número de ações em andamento ainda é limitado com --jobs.
Tags:
host_machine_resource_optimizations,execution,incompatible_change - Padrão de
--experimental_async_execution_max_concurrent_actions=<an integer>: "5000" -
O número máximo de ações simultâneas a serem executadas com execução assíncrona. Se o valor for menor que --jobs, ele será ajustado para --jobs.
--experimental_docker_image=<a string>padrão: ""-
Especifique um nome de imagem do Docker (por exemplo, "ubuntu:latest") que será usado para executar uma ação em sandbox ao usar a estratégia do Docker, e a ação em si ainda não tem um atributo container-image nas remote_execution_properties na descrição da plataforma. O valor dessa flag é transmitido literalmente para "docker run", então ele é compatível com a mesma sintaxe e os mesmos mecanismos do Docker.
Tags:
execution --[no]experimental_docker_use_customized_imagespadrão: "true"-
Se ativada, injeta o uid e o gid do usuário atual na imagem do Docker antes de usá-la. Isso é necessário se sua build / testes dependem de o usuário ter um nome e um diretório inicial dentro do contêiner. Ele fica ativado por padrão, mas pode ser desativado caso a personalização automática de imagens não funcione para você ou se você não precisar dela.
Tags:
execution --[no]experimental_dynamic_exclude_toolspadrão: "true"-
Quando definido, os destinos criados "para a ferramenta" não estão sujeitos à execução dinâmica. É extremamente improvável que esses destinos sejam criados de forma incremental e, portanto, não vale a pena gastar ciclos locais neles.
--experimental_dynamic_local_load_factor=<a double>padrão: "0"-
Controla a quantidade de carga da execução dinâmica a ser colocada na máquina local. Essa flag ajusta quantas ações na execução dinâmica serão programadas simultaneamente. Ele se baseia no número de CPUs que o Blaze considera disponíveis, o que pode ser controlado com a flag --local_resources=cpu=. Se essa flag for 0, todas as ações serão programadas localmente imediatamente. Se for > 0, a quantidade de ações agendadas localmente será limitada pelo número de CPUs disponíveis. Se for < 1, o fator de carga será usado para reduzir o número de ações programadas localmente quando o número de ações aguardando programação for alto. Isso reduz a carga na máquina local no caso de uma build limpa, em que a máquina local não contribui muito.
--experimental_dynamic_slow_remote_time=<An immutable length of time.>padrão: "0"-
Se for >0, o tempo que uma ação executada dinamicamente precisa ser executada apenas remotamente antes de priorizarmos a execução local dela para evitar tempos limite remotos. Isso pode ocultar alguns problemas no sistema de execução remota. Não ative essa opção sem monitorar problemas de execução remota.
--[no]experimental_enable_docker_sandboxpadrão: "false"-
Ative o sandbox baseado em Docker. Essa opção não tem efeito se o Docker não estiver instalado.
Tags:
execution --[no]experimental_inmemory_sandbox_stashespadrão: "false"-
Se definido como verdadeiro, o conteúdo das caixas de areia armazenadas para reuse_sandbox_directories será rastreado na memória. Isso reduz a quantidade de E/S necessária durante a reutilização. Dependendo do build, essa flag pode melhorar o tempo real. Dependendo do build, essa flag pode usar uma quantidade significativa de memória extra.
--experimental_sandbox_async_tree_delete_idle_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">padrão: "4"-
Se for 0, os sandbox serão excluídos assim que as ações forem concluídas, bloqueando a conclusão da ação. Se for maior que 0, os sandbox serão excluídos de forma assíncrona em segundo plano sem bloquear a conclusão da ação. A exclusão assíncrona usa uma única linha de execução enquanto um comando está em execução, mas aumenta para tantas linhas de execução quanto o valor dessa flag quando o servidor fica ocioso. Defina como
autopara usar o mesmo número de threads e CPUs. O encerramento de um servidor bloqueia exclusões assíncronas pendentes. --experimental_sandbox_enforce_resources_regexp=<a valid Java regular expression>padrão: ""-
Se for verdadeiro, as ações cujo mnemônico corresponder à regex de entrada terão a solicitação de recursos aplicada como limites, substituindo o valor de --experimental_sandbox_limits, se o tipo de recurso for compatível. Por exemplo, um teste que declara cpu:3 e resources:memory:10 será executado com no máximo 3 CPUs e 10 megabytes de memória.
Tags:
execution --experimental_sandbox_limits=<a named double, 'name=value', where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">vários usos são acumulados-
Se for > 0, cada sandbox do Linux será limitado à quantidade especificada para o recurso indicado. Requer --incompatible_use_new_cgroup_implementation e substitui --experimental_sandbox_memory_limit_mb. Requer cgroups v1 ou v2 e permissões para os usuários no diretório cgroups.
Tags:
execution --experimental_sandbox_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.>padrão: "0"-
Se for > 0, cada sandbox do Linux será limitado à quantidade de memória especificada (em MB). Requer cgroups v1 ou v2 e permissões para os usuários no diretório cgroups.
Tags:
execution --[no]experimental_shrink_worker_poolpadrão: "false"-
Se ativada, pode reduzir o pool de workers se a pressão da memória do worker for alta. Essa flag só funciona quando a flag experimental_total_worker_memory_limit_mb está ativada.
--experimental_total_worker_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.>padrão: "0"-
Se esse limite for maior que zero, os workers inativos poderão ser encerrados se o uso total de memória de todos os workers exceder o limite.
--[no]experimental_use_hermetic_linux_sandboxpadrão: "false"-
Se definido como verdadeiro, não ative a raiz, apenas o que é fornecido com sandbox_add_mount_pair. Os arquivos de entrada serão vinculados fisicamente ao sandbox, em vez de serem vinculados simbolicamente a partir dele. Se os arquivos de entrada de ação estiverem em um sistema de arquivos diferente do sandbox, eles serão copiados.
Tags:
execution --[no]experimental_use_windows_sandboxpadrão: "false"-
Use o sandbox do Windows para executar ações. Se a resposta for "sim", o binário fornecido por --experimental_windows_sandbox_path precisa ser válido e corresponder a uma versão compatível do sandboxfs. Se for "auto", o binário pode estar faltando ou não ser compatível.
Tags:
execution --experimental_windows_sandbox_path=<a string>padrão: "BazelSandbox.exe"-
Caminho para o binário do sandbox do Windows a ser usado quando --experimental_use_windows_sandbox for verdadeiro. Se for um nome simples, use o primeiro binário desse nome encontrado no PATH.
Tags:
execution --experimental_worker_allowlist=<comma-separated set of options>padrão: consulte a descrição-
Se não estiver vazio, só permita o uso de workers persistentes com o mnemônico de chave de worker especificado.
--[no]experimental_worker_cancellationpadrão: "false"-
Se ativado, o Bazel poderá enviar solicitações de cancelamento para workers que oferecem suporte a elas.
Tags:
execution --experimental_worker_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.>padrão: "0"-
Se esse limite for maior que zero, os workers poderão ser encerrados se o uso de memória exceder o limite. Se não for usado com a execução dinâmica e
--experimental_dynamic_ignore_local_signals=9, isso poderá causar falha na sua build. - Padrão de
--experimental_worker_metrics_poll_interval=<An immutable length of time.>: "5s" -
O intervalo entre a coleta de métricas do worker e a possível tentativa de remoção. Não pode ser efetivamente menor que 1 segundo por motivos de desempenho.
--[no]experimental_worker_multiplex_sandboxingpadrão: "false"-
Se ativados, os trabalhadores de multiplex com um requisito de execução "supports-multiplex-sandboxing" serão executados em um ambiente isolado, usando um diretório de sandbox separado por solicitação de trabalho. Os workers de multiplex com o requisito de execução são sempre isolados em sandbox quando executados na estratégia de execução dinâmica, independente dessa flag.
Tags:
execution --[no]experimental_worker_sandbox_hardeningpadrão: "false"-
Se ativado, os workers serão executados em uma sandbox reforçada, se a implementação permitir. Se a proteção estiver ativada, os diretórios tmp serão distintos para diferentes workers.
Tags:
execution --experimental_worker_sandbox_inmemory_tracking=<a string>vários usos são acumulados-
Um mnemônico de chave de worker para o qual o conteúdo do diretório sandbox é rastreado na memória. Isso pode melhorar o desempenho do build ao custo de uso adicional de memória. Isso afeta apenas os workers em sandbox. Pode ser especificado várias vezes para diferentes mnemônicos.
Tags:
execution --[no]experimental_worker_strict_flagfilespadrão: "false"-
Se ativado, os argumentos de ações para workers que não seguem a especificação do worker vão causar um erro. Os argumentos do worker precisam ter exatamente um argumento @flagfile como o último da lista.
Tags:
execution --genrule_strategy=<comma-separated list of options>padrão: ""-
Especifique como executar genrules. Essa flag será descontinuada. Em vez disso, use --spawn_strategy=<value> para controlar todas as ações ou --strategy=Genrule=<value> para controlar apenas as genrules.
Tags:
execution --[no]incompatible_use_new_cgroup_implementationpadrão: "true"-
Se for verdadeiro, use a nova implementação para cgroups. A implementação antiga só é compatível com o controlador de memória e ignora o valor de --experimental_sandbox_limits.
Tags:
execution --[no]internal_spawn_schedulerpadrão: "true"-
Opção de marcador de posição para que possamos saber no Blaze se o programador de geração foi ativado.
--jobs=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">[-j] padrão: "auto"-
O número de jobs simultâneos a serem executados. Aceita um número inteiro ou uma palavra-chave ("auto", "HOST_CPUS", "HOST_RAM"), seguida opcionalmente por uma operação ([-|]<float>), por exemplo, "auto", "HOST_CPUS.5". Os valores precisam estar entre 1 e 5.000. Valores acima de 2.500 podem causar problemas de memória. "auto" calcula um padrão razoável com base nos recursos do host.
--[no]keep_going[-k] padrão: "false"-
Continue o máximo possível após um erro. Embora o destino com falha e aqueles que dependem dele não possam ser analisados, outros pré-requisitos desses destinos podem ser.
Tags:
eagerness_to_exit --loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">padrão: "auto"-
Número de linhas de execução paralelas a serem usadas na fase de carregamento/análise. Recebe um número inteiro ou uma palavra-chave ("auto", "HOST_CPUS", "HOST_RAM"), opcionalmente seguida por uma operação ([-|]<float>), por exemplo, "auto", "HOST_CPUS.5". "auto" define um padrão razoável com base nos recursos do host. Precisa ser pelo menos 1.
--[no]reuse_sandbox_directoriespadrão: "true"-
Se definido como verdadeiro, os diretórios usados pela execução não worker em sandbox poderão ser reutilizados para evitar custos de configuração desnecessários.
--sandbox_base=<a string>padrão: ""-
Permite que o sandbox crie diretórios abaixo desse caminho. Especifique um caminho em tmpfs (como /run/shm) para melhorar muito o desempenho quando seu build / testes tiverem muitos arquivos de entrada. Observação: é necessário ter RAM e espaço livre suficientes no tmpfs para armazenar arquivos intermediários e de saída gerados pela execução de ações.
--[no]sandbox_enable_loopback_devicepadrão: "true"-
Se for verdadeiro, um dispositivo de loopback será configurado no namespace de rede linux-sandbox para ações locais.
Tags:
execution --[no]sandbox_explicit_pseudoterminalpadrão: "false"-
Ative explicitamente a criação de pseudoterminais para ações em sandbox. Algumas distribuições do Linux exigem a definição do ID do grupo do processo como "tty" dentro do sandbox para que os pseudoterminais funcionem. Se isso estiver causando problemas, a flag poderá ser desativada para permitir o uso de outros grupos.
Tags:
execution --sandbox_tmpfs_path=<an absolute path>vários usos são acumulados-
Para ações em sandbox, monte um diretório vazio e gravável nesse caminho absoluto (se compatível com a implementação de sandbox; caso contrário, será ignorado).
--[no]skip_incompatible_explicit_targetspadrão: "false"-
Ignora destinos incompatíveis que estão explicitamente listados na linha de comando. Por padrão, a criação desses destinos resulta em um erro, mas eles são ignorados silenciosamente quando essa opção está ativada. Consulte: https://bazel.build/extending/platforms#skipping-incompatible-targets
Tags:
loading_and_analysis --spawn_strategy=<comma-separated list of options>padrão: ""-
Especifica como as ações de geração são executadas por padrão. Aceita uma lista separada por vírgulas de estratégias da prioridade mais alta para a mais baixa. Para cada ação, o Bazel escolhe a estratégia com a maior prioridade que pode executar a ação. O valor padrão é "remote,worker,sandboxed,local". Consulte https://blog.bazel.build/2019/06/19/list-strategy.html para mais detalhes.
Tags:
execution --strategy=<a '[name=]value1[,..,valueN]' assignment>vários usos são acumulados-
Especifique como distribuir a compilação de outras ações de geração. Aceita uma lista separada por vírgulas de estratégias da prioridade mais alta para a mais baixa. Para cada ação, o Bazel escolhe a estratégia com a maior prioridade que pode executar a ação. O valor padrão é "remote,worker,sandboxed,local". Essa flag substitui os valores definidos por --spawn_strategy (e --genrule_strategy se usada com o mnemônico Genrule). Consulte https://blog.bazel.build/2019/06/19/list-strategy.html para mais detalhes.
Tags:
execution --strategy_regexp=<a '<RegexFilter>=value[,value]' assignment>vários usos são acumulados-
Substitui a estratégia de geração que deve ser usada para executar ações de geração com descrições que correspondem a um determinado regex_filter. Consulte --per_file_copt para mais detalhes sobre a correspondência de regex_filter. 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 a estratégia local se as descrições corresponderem a //foo..cc, mas não a //foo/bar. Exemplo: --strategy_regexp='Compiling.*/bar=local --strategy_regexp=Compiling=sandboxed vai executar 'Compiling //foo/bar/baz' com a estratégia 'local', mas inverter a ordem vai executar com 'sandboxed'.
Tags:
execution --worker_extra_flag=<a 'name=value' assignment>vários usos são acumulados-
Flags de comando extras que serão transmitidas aos processos de worker além de --persistent_worker, com chave por mnemônico (por exemplo, --worker_extra_flag=Javac=--debug.
--worker_max_instances=<[name=]value, where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">vários usos são acumulados-
Quantas instâncias de cada tipo de worker persistente podem ser iniciadas se você usar a estratégia "worker". Pode ser especificado como [name=value] para dar um valor diferente por mnemônico. O limite é baseado em chaves de worker, que são diferenciadas com base no mnemônico, mas também em flags de inicialização e ambiente. Portanto, em alguns casos, pode haver mais workers por mnemônico do que o especificado por essa flag. Aceita um número inteiro ou uma palavra-chave ("auto", "HOST_CPUS", "HOST_RAM"), seguida opcionalmente por uma operação ([-|]<float>), por exemplo, "auto", "HOST_CPUS.5". "auto" calcula um padrão razoável com base na capacidade da máquina. "=value" define um padrão para mnemônicos não especificados.
--worker_max_multiplex_instances=<[name=]value, where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">vários usos são acumulados-
Quantos WorkRequests um processo de worker multiplex pode receber em paralelo se você usar a estratégia "worker" com --worker_multiplex. Pode ser especificado como [name=value] para dar um valor diferente por mnemônico. O limite é baseado em chaves de worker, que são diferenciadas com base no mnemônico, mas também em flags de inicialização e ambiente. Portanto, em alguns casos, pode haver mais workers por mnemônico do que o especificado por essa flag. Aceita um número inteiro ou uma palavra-chave ("auto", "HOST_CPUS", "HOST_RAM"), seguida opcionalmente por uma operação ([-|]<float>), por exemplo, "auto", "HOST_CPUS.5". "auto" calcula um padrão razoável com base na capacidade da máquina. "=value" define um padrão para mnemônicos não especificados.
--[no]worker_multiplexpadrão: "true"-
Se ativado, os workers vão usar multiplexação se ela for compatível.
--[no]worker_quit_after_buildpadrão: "false"-
Se ativado, todos os workers serão encerrados após a conclusão de um build.
--[no]worker_sandboxingpadrão: "false"-
Se ativados, os workers singleplex serão executados em um ambiente em sandbox. Os workers Singleplex sempre são isolados em sandbox quando executados com a estratégia de execução dinâmica, independente dessa flag.
Tags:
execution --[no]worker_verbosepadrão: "false"-
Se ativado, imprime mensagens detalhadas quando os workers são iniciados, desligados etc.
- Opções que controlam a saída do comando:
--[no]buildpadrão: "true"-
Execute o build. Esse é o comportamento normal. Especificar --nobuild faz com que a build pare antes de executar as ações de build, retornando zero se as fases de carregamento e análise de pacotes forem concluídas com êxito. Esse modo é útil para testar essas fases.
Tags:
execution,affects_outputs --[no]experimental_use_validation_aspectpadrão: "false"-
Se as ações de validação devem ser executadas usando o aspecto (para paralelismo com testes).
Tags:
execution,affects_outputs --output_groups=<comma-separated list of options>vários usos são acumulados-
Uma lista de nomes de grupos de saída separados por vírgulas, cada um deles prefixado opcionalmente por um + ou um -. Um grupo prefixado por + é adicionado ao conjunto padrão de grupos de saída, enquanto um grupo prefixado por - é removido do conjunto padrão. Se pelo menos um grupo não tiver prefixo, o conjunto padrão de grupos de saída será omitido. Por exemplo, "--output_groups=+foo,+bar" cria a união do conjunto padrão, foo e bar, enquanto "--output_groups=foo,bar" substitui o conjunto padrão para que apenas foo e bar sejam criados.
Tags:
execution,affects_outputs --[no]run_validationspadrão: "true"-
Se as ações de validação devem ser executadas como parte do build. Consulte https://bazel.build/extending/rules#validation_actions
Tags:
execution,affects_outputs --serialized_frontier_profile=<a string>padrão: ""-
Despeja um perfil de bytes de fronteira serializados. Especifica o caminho de saída.
Tags:
bazel_monitoring
- Opções que permitem ao usuário configurar a saída pretendida, afetando o valor dela, e não a existência:
--aspects=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de aspectos a serem aplicados a metas de nível superior. Na lista, se o aspecto "some_aspect" especificar provedores de aspecto obrigatórios usando "required_aspect_providers", "some_aspect" será executado após cada aspecto mencionado antes dele na lista de aspectos cujos provedores anunciados atendem aos provedores de aspecto obrigatórios de "some_aspect". Além disso, "some_aspect" será executado depois de todos os aspectos obrigatórios especificados pelo atributo "requires". Assim, "some_aspect" terá acesso aos valores dos provedores desses aspectos. <bzl-file-label>%<aspect_name>, por exemplo, "//tools:my_def.bzl%my_aspect", em que "my_aspect" é um valor de nível superior de um arquivo tools/my_def.bzl
--bep_maximum_open_remote_upload_files=<an integer>padrão: "-1"-
Número máximo de arquivos abertos permitidos durante o upload de artefatos do BEP.
Tags:
affects_outputs - Padrão de
--[no]experimental_convenience_symlinks: "normal" -
Esta flag controla como os symlinks de conveniência (os symlinks que aparecem no espaço de trabalho após o build) serão gerenciados. Valores possíveis: normal (padrão): cada tipo de link simbólico de conveniência será criado ou excluído, conforme determinado pelo build. clean: todos os links simbólicos serão excluídos incondicionalmente. ignore: os links simbólicos não serão criados nem limpos. log_only: gera mensagens de registro como se "normal" fosse transmitido, mas não realiza nenhuma operação do sistema de arquivos (útil para ferramentas). Somente os symlinks cujos nomes são gerados pelo valor atual de --symlink_prefix podem ser afetados. Se o prefixo mudar, os symlinks preexistentes não serão alterados.
Tags:
affects_outputs --[no]experimental_convenience_symlinks_bep_eventpadrão: "true"-
Essa flag controla se vamos postar o build eventConvenienceSymlinksIdentified no BuildEventProtocol. Se o valor for "true", o BuildEventProtocol terá uma entrada para "convenienceSymlinksIdentified", listando todos os symlinks de conveniência criados no seu espaço de trabalho. Se for "false", a entrada "convenienceSymlinksIdentified" em "BuildEventProtocol" vai ficar vazia.
Tags:
affects_outputs --remote_download_all-
Baixa todas as saídas remotas para a máquina local. Essa flag é um alias de --remote_download_outputs=all.
Expande para:
--remote_download_outputs=allTags:
affects_outputs --remote_download_minimal-
Não faz o download de nenhuma saída de build remoto para a máquina local. Essa flag é um alias para --remote_download_outputs=minimal.
Expande para:
--remote_download_outputs=minimalTags:
affects_outputs --remote_download_outputs=<all, minimal or toplevel>padrão: "toplevel"-
Se definido como "minimal", não faz o download de nenhuma saída de build remoto para a máquina local, exceto as necessárias para ações locais. Se definido como "toplevel", se comporta como "minimal", exceto que também baixa saídas de destinos de nível superior para a máquina local. As duas opções podem reduzir significativamente os tempos de build se a largura de banda da rede for um gargalo.
Tags:
affects_outputs --remote_download_symlink_template=<a string>padrão: ""-
Em vez de baixar saídas de build remoto para a máquina local, crie links simbólicos. O destino dos links simbólicos pode ser especificado na forma de uma string de modelo. Essa string de modelo pode conter {hash} e {size_bytes}, que são expandidos para o hash do objeto e o tamanho em bytes, respectivamente. Esses links simbólicos podem, por exemplo, apontar para um sistema de arquivos FUSE que carrega objetos do CAS sob demanda.
Tags:
affects_outputs --remote_download_toplevel-
Faz o download apenas das saídas remotas das metas de nível superior para a máquina local. Essa flag é um alias de --remote_download_outputs=toplevel.
Expande para:
--remote_download_outputs=toplevelTags:
affects_outputs --symlink_prefix=<a string>padrão: consulte a descrição-
O prefixo que é adicionado a qualquer um dos symlinks de conveniência criados após um build. Se omitido, o valor padrão será o nome da ferramenta de build seguido por um hífen. Se "/" for transmitido, nenhum link simbólico será criado e nenhum aviso será emitido. Aviso: a funcionalidade especial para "/" será descontinuada em breve. Use --experimental_convenience_symlinks=ignore.
Tags:
affects_outputs
- Opções que afetam a rigidez com que o Bazel aplica entradas de build válidas (definições de regras, combinações de flags etc.):
--[no]experimental_docker_privilegedpadrão: "false"-
Se ativado, o Bazel vai transmitir a flag "--privileged" para "docker run" ao executar ações. Isso pode ser exigido pelo build, mas também pode resultar em hermeticidade reduzida.
Tags:
execution --[no]experimental_sandboxfs_map_symlink_targetspadrão: "false"-
Nenhuma operação
--sandbox_add_mount_pair=<a single path or a 'source:target' pair>vários usos são acumulados-
Adicione outro par de caminhos para montar na sandbox.
Tags:
execution --sandbox_block_path=<a string>vários usos são acumulados-
Para ações em sandbox, não permita o acesso a esse caminho.
Tags:
execution --[no]sandbox_default_allow_networkpadrão: "true"-
Permitir o acesso à rede por padrão para ações. Isso pode não funcionar com todas as implementações de sandbox.
Tags:
execution --[no]sandbox_fake_hostnamepadrão: "false"-
Mude o nome do host atual para "localhost" em ações em sandbox.
Tags:
execution --[no]sandbox_fake_usernamepadrão: "false"-
Mude o nome de usuário atual para "nobody" em ações em sandbox.
Tags:
execution --sandbox_writable_path=<a string>vários usos são acumulados-
Para ações em sandbox, torne um diretório gravável na sandbox (se compatível com a implementação de sandbox, caso contrário, será ignorado).
Tags:
execution
- Essa opção afeta a semântica da linguagem Starlark ou a API de build acessível a arquivos BUILD, .bzl ou WORKSPACE.:
--[no]incompatible_config_setting_private_default_visibilitypadrão: "false"-
Se "incompatible_enforce_config_setting_visibility=false", isso não terá efeito. Caso contrário, se essa flag for "false", qualquer config_setting sem um atributo de visibilidade explícito será //visibility:public. Se essa flag for "true", "config_setting" vai seguir a mesma lógica de visibilidade de todas as outras regras. Consulte https://github.com/bazelbuild/bazel/issues/12933.
--[no]incompatible_enforce_config_setting_visibilitypadrão: "true"-
Se for "true", aplique as restrições de visibilidade de "config_setting". Se for "false", todas as config_setting serão visíveis para todos os destinos. Consulte https://github.com/bazelbuild/bazel/issues/12932.
- Opções que regem o comportamento do ambiente de teste ou do executor de testes:
--[no]check_tests_up_to_datepadrão: "false"-
Não execute testes, apenas verifique se eles estão atualizados. Se todos os resultados de teste estiverem atualizados, o teste será concluído com êxito. Se algum teste precisar ser criado ou executado, um erro será informado e o teste vai falhar. Essa opção implica o comportamento --check_up_to_date.
Tags:
execution --flaky_test_attempts=<a positive integer, the string "default", or test_regex@attempts. This flag may be passed more than once>vários usos são acumulados-
Cada teste será repetido até o número especificado de vezes em caso de falha. Os testes que exigiram mais de uma tentativa para serem aprovados são marcados como "IRREGULAR" no resumo do teste. Normalmente, o valor especificado é apenas um número inteiro ou a string "default". Se for um número inteiro, todos os testes serão executados até N vezes. Se for "default", apenas uma tentativa de teste será feita para testes regulares e três para testes marcados explicitamente como instáveis pela regra (atributo flaky=1). Sintaxe alternativa: regex_filter@flaky_test_attempts. Em que flaky_test_attempts é como acima e regex_filter representa uma lista de padrões de expressões regulares de inclusão e exclusão. Consulte também --runs_per_test. Exemplo: --flaky_test_attempts=//foo/.,-//foo/bar/.@3 remove a irregularidade de todos os testes em //foo/, exceto aqueles em foo/bar, três vezes. Essa opção pode ser transmitida várias vezes. O argumento transmitido mais recentemente que corresponde tem precedência. Se nada corresponder, o comportamento será como o "padrão" acima.
Tags:
execution --local_test_jobs=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">padrão: "auto"-
O número máximo de jobs de teste local a serem executados simultaneamente. Aceita um número inteiro ou uma palavra-chave ("auto", "HOST_CPUS", "HOST_RAM"), seguida opcionalmente por uma operação ([-|]<float>), por exemplo, "auto", "HOST_CPUS.5". 0 significa que os recursos locais vão limitar o número de jobs de teste local a serem executados simultaneamente. Definir um valor maior que o de --jobs não tem efeito.
Tags:
execution --[no]test_keep_goingpadrão: "true"-
Quando desativada, qualquer teste reprovado interrompe todo o build. Por padrão, todos os testes são executados, mesmo que alguns não sejam aprovados.
Tags:
execution --test_strategy=<a string>padrão: ""-
Especifica qual estratégia usar ao executar testes.
Tags:
execution --test_tmpdir=<a path>padrão: consulte a descrição-
Especifica o diretório temporário base que o "bazel test" vai usar.
- Opções que acionam otimizações do tempo de build:
--cache_computed_file_digests=<a long integer>padrão: "50000"-
Se for maior que 0, configura o Bazel para armazenar em cache os resumos de arquivos na memória com base nos metadados deles, em vez de recalcular os resumos do disco sempre que eles forem necessários. Definir como 0 garante a correção, porque nem todas as mudanças de arquivo podem ser observadas nos metadados. Quando não é 0, o número indica o tamanho do cache como o número de resumos de arquivos a serem armazenados em cache.
--experimental_active_directories=<comma-separated list of options>padrão: ""-
Diretórios ativos para Skyfocus e armazenamento em cache de análise remota. Especifique como caminhos separados por vírgulas relativos à raiz do espaço de trabalho. Essa é uma flag com estado. A definição de um conjunto o mantém para invocações subsequentes até que ele seja redefinido com um novo conjunto.
--[no]experimental_cpu_load_schedulingpadrão: "false"-
Ativa o agendamento experimental de execução local com base na carga da CPU, não na estimativa de ações individuais. O agendamento experimental mostrou o grande benefício em builds locais grandes em máquinas potentes com um grande número de núcleos. Recomendado para uso com --local_resources=cpu=HOST_CPUS
Tags:
execution --experimental_dynamic_ignore_local_signals=<a comma-separated list of signal numbers>padrão: consulte a descrição-
Usa uma lista de números de indicadores do SO. Se uma ramificação local da execução dinâmica for encerrada com qualquer um desses sinais, a ramificação remota poderá ser concluída. Para workers persistentes, isso afeta apenas os sinais que encerram o processo do worker.
Tags:
execution --[no]experimental_enable_skyfocuspadrão: "false"-
Se verdadeiro, ative o uso de --experimental_active_directories para reduzir a ocupação de memória do Bazel em builds incrementais. Esse recurso é conhecido como Skyfocus.
--local_cpu_resources=<an integer, or "HOST_CPUS", optionally followed by [-|*]<float>.>padrão: "HOST_CPUS"-
Defina explicitamente o número total de núcleos de CPU locais disponíveis para o Bazel gastar em ações de build executadas localmente. Aceita um número inteiro ou "HOST_CPUS", opcionalmente seguido por [-|]<float> (por exemplo, HOST_CPUS.5 para usar metade dos núcleos de CPU disponíveis). Por padrão ("HOST_CPUS"), o Bazel consulta a configuração do sistema para estimar o número de núcleos de CPU disponíveis.
--local_extra_resources=<a named float, 'name=value'>vários usos são acumulados-
Defina o número de recursos extras disponíveis para o Bazel. Recebe um par string-float. Pode ser usado várias vezes para especificar vários tipos de recursos extras. O Bazel limita as ações em execução simultânea com base nos recursos extras disponíveis e nos recursos extras necessários. Os testes podem declarar a quantidade de recursos extras de que precisam usando uma tag no formato "resources:<resoucename>:<amount>". A CPU, a RAM e os recursos disponíveis não podem ser definidos com essa flag.
--local_ram_resources=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.>padrão: "HOST_RAM*.67"-
Defina explicitamente a quantidade total de RAM do host local (em MB) disponível para o Bazel gastar em ações de build executadas localmente. Aceita um número inteiro ou "HOST_RAM", opcionalmente seguido por [-|]<float> (por exemplo, HOST_RAM.5 para usar metade da RAM disponível. Por padrão, ("HOST_RAM*.67"), o Bazel consulta a configuração do sistema para estimar a quantidade de RAM disponível e usa 67% dela.
--local_resources=<a named double, 'name=value', where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">vários usos são acumulados-
Defina o número de recursos disponíveis para o Bazel. Recebe uma atribuição a um ponto flutuante ou HOST_RAM/HOST_CPUS, opcionalmente seguida por [-|]<float> (por exemplo, memory=HOST_RAM.5 para usar metade da RAM disponível). Pode ser usado várias vezes para especificar vários tipos de recursos. O Bazel limita as ações em execução simultânea com base nos recursos disponíveis e nos recursos necessários. Os testes podem declarar a quantidade de recursos necessários usando uma tag no formato "resources:<resource name>:<amount>". Substitui os recursos especificados por --local_{cpu|ram|extra}_resources.
- Opções que afetam a verbosidade, o formato ou o local do registro em log:
--build_event_upload_max_retries=<an integer>padrão: "4"-
O número máximo de vezes que o Bazel deve tentar fazer upload de um evento de build.
--[no]debug_spawn_schedulerpadrão: "false"--[no]experimental_bep_target_summarypadrão: "false"-
Se os eventos TargetSummary serão publicados.
--[no]experimental_build_event_expand_filesetspadrão: "false"-
Se for "true", expanda os conjuntos de arquivos no BEP ao apresentar arquivos de saída.
Tags:
affects_outputs --experimental_build_event_output_group_mode=<an output group name followed by an OutputGroupFileMode, e.g. default=both>vários usos são acumulados-
Especifique como os arquivos de um grupo de saída serão representados em eventos BEP TargetComplete/AspectComplete. Os valores são uma atribuição de um nome de grupo de saída a um de "NAMED_SET_OF_FILES_ONLY", "INLINE_ONLY" ou "BOTH". O valor padrão é "NAMED_SET_OF_FILES_ONLY". Se um grupo de saída for repetido, o valor final a aparecer será usado. O valor padrão define o modo para artefatos de cobertura como "BOTH": --experimental_build_event_output_group_mode=baseline.lcov=both
Tags:
affects_outputs - Padrão de
--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.>: "1s" -
Atraso inicial e mínimo para novas tentativas de espera exponencial quando o upload do BEP falha. (expoente: 1,6)
--experimental_build_event_upload_strategy=<a string>padrão: consulte a descrição-
Seleciona como fazer upload dos artefatos referenciados no protocolo de eventos de build. No Bazel, as opções válidas incluem "local" e "remote". O valor padrão é "local".
Tags:
affects_outputs --[no]experimental_docker_verbosepadrão: "false"-
Se ativado, o Bazel vai imprimir mensagens mais detalhadas sobre a estratégia de sandbox do Docker.
Tags:
execution --experimental_frontier_violation_check=<strict, warn or disabled_for_testing>padrão: "strict"-
Estratégias para lidar com possíveis incorreções de mudanças além da fronteira (ou seja, fora dos diretórios ativos)
Tags:
eagerness_to_exit --[no]experimental_frontier_violation_verbosepadrão: "false"-
Se for verdadeiro, o Bazel vai imprimir instruções para corrigir violações do Skycache.
Tags:
terminal_output --[no]experimental_materialize_param_files_directlypadrão: "false"-
Se você materializar arquivos de parâmetros, faça isso com gravações diretas no disco.
Tags:
execution --[no]experimental_run_bep_event_include_residuepadrão: "false"-
Incluir ou não o resíduo da linha de comando em eventos de build de execução que podem conter o resíduo. Por padrão, o resíduo não é incluído em eventos de build de comandos de execução que podem conter o resíduo.
Tags:
affects_outputs --experimental_skyfocus_dump_keys=<none, count or verbose>padrão: "none"-
Para depurar o Skyfocus. Despeja as SkyKeys em foco (raízes, folhas, dependências em foco, dependências inversas em foco).
Tags:
terminal_output --[no]experimental_skyfocus_dump_post_gc_statspadrão: "false"-
Para depurar o Skyfocus. Se ativado, acione a coleta de lixo manual antes/depois de focar para informar as reduções de tamanho do heap. Isso vai aumentar a latência do Skyfocus.
Tags:
terminal_output --[no]experimental_stream_log_file_uploadspadrão: "false"-
Fazer streaming dos uploads de arquivos de registro diretamente para o armazenamento remoto em vez de gravá-los no disco.
Tags:
affects_outputs --explain=<a path>padrão: consulte a descrição-
Faz com que o sistema de build explique cada etapa executada do build. A explicação é gravada no arquivo de registro especificado.
Tags:
affects_outputs --[no]ignore_unsupported_sandboxingpadrão: "false"-
Não imprimir um aviso quando a execução em sandbox não for compatível com este sistema.
Tags:
terminal_output --[no]legacy_important_outputspadrão: "false"-
Use isso para suprimir a geração do campo legado important_outputs no evento TargetComplete. important_outputs são necessários para a integração do Bazel com ResultStore/BTX.
Tags:
affects_outputs --[no]materialize_param_filespadrão: "false"-
Grava arquivos de parâmetros intermediários na árvore de saída, mesmo ao usar a execução ou o armazenamento em cache de ações remotas. Útil ao depurar ações. Isso está implícito em --subcommands e --verbose_failures.
Tags:
execution - Padrão de
--max_config_changes_to_show=<an integer>: "3" -
Ao descartar o cache de análise devido a uma mudança nas opções de build, mostra até o número especificado de nomes de opções alterados. Se o número fornecido for -1, todas as opções alteradas serão exibidas.
Tags:
terminal_output --max_test_output_bytes=<an integer>padrão: "-1"-
Especifica o tamanho máximo por registro de teste que pode ser emitido quando --test_output é "errors" ou "all". Isso é útil para evitar sobrecarregar a saída com resultados de teste excessivamente ruidosos. O cabeçalho do teste está incluído no tamanho do registro. Valores negativos não têm limite. A saída é tudo ou nada.
Tags:
test_runner,terminal_output,execution --output_filter=<a valid Java regular expression>padrão: consulte a descrição-
Mostra apenas avisos e saídas de ações para regras com um nome que corresponda à expressão regular fornecida.
Tags:
affects_outputs --progress_report_interval=<an integer in 0-3600 range>padrão: "0"-
O número de segundos para aguardar entre relatórios sobre jobs ainda em execução. O valor padrão 0 significa que o primeiro relatório será impresso após 10 segundos, depois 30 segundos e, em seguida, o progresso será informado uma vez por minuto. Quando --curses está ativado, o progresso é informado a cada segundo.
Tags:
affects_outputs --remote_analysis_json_log=<a string>padrão: consulte a descrição-
Se definido, um arquivo JSON será gravado nesse local com um registro detalhado do comportamento do cache de análise remota. Ele é interpretado como um caminho relativo ao diretório de trabalho atual.
Tags:
bazel_monitoring - Padrão de
--remote_print_execution_messages=<failure, success or all>: "failure" -
Escolha quando imprimir mensagens de execução remota. Os valores válidos são
failure, para imprimir apenas em falhas,successpara imprimir apenas em sucessos eallpara imprimir sempre.Tags:
terminal_output --[no]sandbox_debugpadrão: "false"-
Ativa recursos de depuração para o recurso de isolamento em sandbox. Isso inclui duas coisas: primeiro, o conteúdo da raiz da sandbox não é alterado após um build; e segundo, imprime informações extras de depuração na execução. Isso pode ajudar os desenvolvedores de regras do Bazel ou do Starlark a depurar falhas devido a arquivos de entrada ausentes etc.
Tags:
terminal_output - Padrão de
--show_result=<an integer>: "1" -
Mostre os resultados do build. Para cada destino, informe se ele foi atualizado ou não e, em caso afirmativo, uma lista dos arquivos de saída criados. Os arquivos impressos são strings convenientes para copiar e colar no shell e executá-los. Essa opção exige um argumento inteiro, que é o número limite de destinos acima do qual as informações de resultado não são impressas. Assim, zero suprime a mensagem, e MAX_INT faz com que o resultado seja impresso sempre. O padrão é um. Se nada foi criado para um destino, os resultados podem ser omitidos para manter a saída abaixo do limite.
Tags:
affects_outputs --[no]subcommands[-s] padrão: "false"-
Mostra os subcomandos executados durante um build. Flags relacionadas: --execution_log_json_file, --execution_log_binary_file (para registrar subcomandos em um arquivo em um formato compatível com ferramentas).
Tags:
terminal_output --test_output=<summary, errors, all or streamed>padrão: "summary"-
Especifica o modo de saída desejado. Os valores válidos são "summary" para gerar apenas o resumo do status do teste, "errors" para também imprimir os registros de testes com falha, "all" para imprimir registros de todos os testes e "streamed" para gerar registros de todos os testes em tempo real. Isso força a execução dos testes localmente, um de cada vez, independente do valor de --test_strategy.
Tags:
test_runner,terminal_output,execution - Padrão de
--test_summary=<short, terse, detailed, none or testcase>: "short" -
Especifica o formato desejado do resumo do teste. Os valores válidos são "short" para imprimir informações apenas sobre os testes executados, "terse" para imprimir informações apenas sobre os testes sem sucesso que foram executados, "detailed" para imprimir informações detalhadas sobre casos de teste com falha, "testcase" para imprimir o resumo na resolução do caso de teste, não imprimir informações detalhadas sobre casos de teste com falha e "none" para omitir o resumo.
Tags:
terminal_output --[no]verbose_failurespadrão: "false"-
Se um comando falhar, imprima a linha de comando completa.
Tags:
terminal_output
- Opções que especificam ou alteram uma entrada genérica para um comando do Bazel que não se enquadra em outras categorias:
--aspects_parameters=<a 'name=value' assignment>vários usos são acumulados-
Especifica os valores dos parâmetros de aspectos da linha de comando. Cada valor de parâmetro é especificado via <param_name>=<param_value>, por exemplo, "my_param=my_val", em que "my_param" é um parâmetro de algum aspecto na lista --aspects ou exigido por um aspecto na lista. Essa opção pode ser usada várias vezes. No entanto, não é permitido atribuir valores ao mesmo parâmetro mais de uma vez.
Tags:
loading_and_analysis --target_pattern_file=<a string>padrão: ""-
Se definido, o build vai ler padrões do arquivo nomeado aqui, em vez de na linha de comando. É um erro especificar um arquivo aqui e padrões de linha de comando.
Tags:
changes_inputs
- Opções de execução e armazenamento em cache remoto:
--experimental_circuit_breaker_strategy=<failure>padrão: consulte a descrição-
Especifica a estratégia a ser usada pelo disjuntor. As estratégias disponíveis são "failure". Em um valor inválido para a opção, o comportamento é o mesmo que se a opção não estivesse definida.
Tags:
execution - Padrão de
--experimental_remote_cache_compression_threshold=<an integer>: "100" -
O tamanho mínimo do blob necessário para compactar/descompactar com zstd. Não tem efeito, a menos que --remote_cache_compression esteja definido.
- Padrão de
--experimental_remote_cache_eviction_retries=<an integer>: "5" -
O número máximo de tentativas de repetição se a build encontrar um erro temporário de cache remoto que, de outra forma, faria com que a build falhasse. Isso se aplica, por exemplo, quando os artefatos são removidos do cache remoto ou em determinadas condições de falha do cache. Um novo ID de invocação será gerado para cada tentativa.
Tags:
execution --[no]experimental_remote_cache_lease_extensionpadrão: "false"-
Se definido como verdadeiro, o Bazel vai estender o lease para saídas de ações remotas durante o build enviando chamadas
FindMissingBlobsperiodicamente ao cache remoto. A frequência é baseada no valor de--experimental_remote_cache_ttl. - Padrão de
--experimental_remote_cache_ttl=<An immutable length of time.>: "3h" -
O TTL mínimo garantido de blobs no cache remoto depois que os resumos são referenciados recentemente, por exemplo, por um ActionResult ou FindMissingBlobs. O Bazel faz várias otimizações com base no TTL dos blobs. Por exemplo, ele não chama GetActionResult repetidamente em um build incremental. O valor precisa ser definido um pouco menor que o TTL real, já que há uma lacuna entre o momento em que o servidor retorna os resumos e quando o Bazel os recebe.
Tags:
execution --experimental_remote_capture_corrupted_outputs=<a path>padrão: consulte a descrição-
Um caminho para um diretório em que as saídas corrompidas serão capturadas.
--[no]experimental_remote_discard_merkle_treespadrão: "true"-
Se definido como "true", descarte as cópias na memória da árvore de Merkle da raiz de entrada e os mapeamentos de entrada associados durante as chamadas para GetActionResult() e Execute(). Isso reduz significativamente o uso da memória, mas exige que o Bazel recalcule esses dados em caso de falhas e novas tentativas de cache remoto.
--experimental_remote_downloader=<a string>padrão: consulte a descrição-
Um URI de endpoint da API Remote Asset, a ser usado como um proxy de download remoto. Os esquemas compatíveis são grpc, grpcs (grpc com TLS ativado) e unix (sockets UNIX locais). Se nenhum esquema for fornecido, o Bazel vai usar grpcs como padrão. Consulte: https://github.com/bazelbuild/remote-apis/blob/master/build/bazel/remote/asset/v1/remote_asset.proto
--[no]experimental_remote_downloader_local_fallbackpadrão: "false"-
Se é necessário voltar ao downloader local se o downloader remoto falhar.
--[no]experimental_remote_downloader_propagate_credentialspadrão: "false"-
Se as credenciais do netrc e do auxiliar de credenciais serão propagadas para o servidor de download remoto. A implementação do servidor precisa oferecer suporte ao novo qualificador
http_header_url:<url-index>:<header-key>, em que<url-index>é uma posição baseada em zero do URL no campourisde FetchBlobRequest. Os cabeçalhos específicos do URL têm precedência sobre os globais. --[no]experimental_remote_execution_keepalivepadrão: "false"-
Indica se o keepalive será usado para chamadas de execução remota.
- Padrão de
--experimental_remote_failure_rate_threshold=<an integer in 0-100 range>: "10" -
Define o número permitido de taxa de falha em porcentagem para um período específico após o qual ele para de chamar o cache/executor remoto. Por padrão, o valor é 10. Definir como 0 significa que não há limitação.
Tags:
execution - Padrão de
--experimental_remote_failure_window_interval=<An immutable length of time.>: "60s" -
O intervalo em que a taxa de falha das solicitações remotas é calculada. Em valor zero ou negativo, a duração da falha é calculada como toda a duração da execução.As seguintes unidades podem ser usadas: dias (d), horas (h), minutos (m), segundos (s) e milissegundos (ms). Se a unidade for omitida, o valor será interpretado como segundos.
Tags:
execution --[no]experimental_remote_mark_tool_inputspadrão: "false"-
Se definido como verdadeiro, o Bazel vai marcar as entradas como entradas de ferramentas para o executor remoto. Isso pode ser usado para implementar trabalhadores persistentes remotos.
--[no]experimental_remote_merkle_tree_cachepadrão: "false"-
Se definido como "true", os cálculos da árvore de Merkle serão memorizados para melhorar a velocidade de verificação de acertos do cache remoto. A pegada de memória do cache é controlada por --experimental_remote_merkle_tree_cache_size.
- Padrão de
--experimental_remote_merkle_tree_cache_size=<a long integer>: "1000" -
O número de árvores de Merkle a serem memorizadas para melhorar a velocidade de verificação de ocorrência em cache remoto. Embora o cache seja reduzido automaticamente de acordo com o processamento de referências leves do Java, erros de falta de memória podem ocorrer se o valor estiver muito alto. Se definido como 0, o tamanho do cache será ilimitado. O valor ideal varia de acordo com o tamanho do projeto. O padrão é 1.000.
--experimental_remote_output_service=<a string>padrão: consulte a descrição-
HOST ou HOST:PORT de um endpoint de serviço de saída remota. Os esquemas compatíveis são grpc, grpcs (grpc com TLS ativado) e unix (sockets UNIX locais). Se nenhum esquema for fornecido, o Bazel vai usar grpcs como padrão. Especifique o esquema grpc:// ou unix: para desativar o TLS.
--experimental_remote_output_service_output_path_prefix=<a string>padrão: ""-
O caminho em que o conteúdo dos diretórios de saída gerenciados pelo --experimental_remote_output_service é colocado. O diretório de saída real usado por um build será um descendente desse caminho e determinado pelo serviço de saída.
--[no]experimental_remote_require_cachedpadrão: "false"-
Se definido como "true", força o cache de todas as ações que podem ser executadas remotamente ou falha na build. Isso é útil para resolver problemas de não determinismo, porque permite verificar se as ações que devem ser armazenadas em cache são realmente armazenadas sem inserir novos resultados no cache.
--experimental_remote_scrubbing_config=<Converts to a Scrubber>padrão: consulte a descrição-
Ativa a limpeza remota de chaves de cache com o arquivo de configuração fornecido, que precisa ser um buffer de protocolo em formato de texto. Consulte src/main/protobuf/remote_scrubbing.proto.
O objetivo desse recurso é facilitar o compartilhamento de um cache remoto/de disco entre ações executadas em plataformas diferentes, mas segmentando a mesma plataforma. Ele precisa ser usado com muito cuidado, já que configurações inadequadas podem causar o compartilhamento acidental de entradas de cache e resultar em builds incorretos.
A limpeza não afeta a execução de uma ação, apenas como a chave de cache remoto/de disco dela é calculada para recuperar ou armazenar um resultado de ação. As ações de limpeza não são compatíveis com a execução remota e sempre serão executadas localmente.
Modificar a configuração de limpeza não invalida as saídas presentes no sistema de arquivos local ou nos caches internos. É necessário um build limpo para reexecutar as ações afetadas.
Para usar esse recurso, defina um --host_platform personalizado junto com --experimental_platform_in_output_dir (para normalizar prefixos de saída) e --incompatible_strict_action_env (para normalizar variáveis de ambiente).
--[no]guard_against_concurrent_changespadrão: "lite"-
Defina como "full" para ativar a verificação do ctime de todos os arquivos de entrada de uma ação antes de fazer upload para um cache remoto. Em alguns casos, o kernel do Linux atrasa a gravação de arquivos, o que pode causar falsos positivos. O padrão é "lite", que verifica apenas arquivos de origem no repositório principal. Definir como "off" desativa todas as verificações. Isso não é recomendado, porque o cache pode ser corrompido quando um arquivo de origem é alterado enquanto uma ação que o usa como entrada está sendo executada.
Tags:
execution --[no]remote_accept_cachedpadrão: "true"-
Se aceitar resultados de ações armazenados em cache remotamente.
--remote_build_event_upload=<all or minimal>padrão: "minimal"-
Se definido como "all", todas as saídas locais referenciadas pelo BEP serão enviadas por upload para o cache remoto. Se definido como "minimal", as saídas locais referenciadas pelo BEP não serão enviadas para o cache remoto, exceto arquivos importantes para os consumidores do BEP (por exemplo, registros de teste e perfil de tempo). O esquema bytestream:// é sempre usado para o URI dos arquivos, mesmo que eles estejam ausentes do cache remoto. O padrão é "minimal".
--remote_bytestream_uri_prefix=<a string>padrão: consulte a descrição-
O nome do host e da instância a serem usados em URIs bytestream:// gravados em fluxos de eventos de build. Essa opção pode ser definida quando os builds são realizados usando um proxy, o que faz com que os valores de --remote_executor e --remote_instance_name não correspondam mais ao nome canônico do serviço de execução remota. Quando não definido, o padrão é "${hostname}/${instance_name}".
--remote_cache=<a string>padrão: consulte a descrição-
Um URI de um endpoint de cache. Os esquemas compatíveis são http, https, grpc, grpcs (grpc com TLS ativado) e unix (sockets UNIX locais). Se nenhum esquema for fornecido, o Bazel vai usar grpcs como padrão. Especifique o esquema grpc://, http:// ou unix: para desativar o TLS. Consulte https://bazel.build/remote/caching
--[no]remote_cache_asyncpadrão: "true"-
Se for verdadeiro, o upload dos resultados da ação para um disco ou cache remoto vai acontecer em segundo plano, em vez de bloquear a conclusão de uma ação. Algumas ações são incompatíveis com uploads em segundo plano e ainda podem bloquear mesmo quando essa flag está definida.
--[no]remote_cache_compressionpadrão: "false"-
Se ativado, compacta/descompacta blobs de cache com zstd quando o tamanho deles for pelo menos --experimental_remote_cache_compression_threshold.
--remote_cache_header=<a 'name=value' assignment>vários usos são acumulados-
Especifique um cabeçalho que será incluído nas solicitações de cache: --remote_cache_header=Name=Value. É possível transmitir vários cabeçalhos especificando a flag várias vezes. Vários valores para o mesmo nome serão convertidos em uma lista separada por vírgulas.
--remote_default_exec_properties=<a 'name=value' assignment>vários usos são acumulados-
Defina as propriedades de execução padrão a serem usadas como a plataforma de execução remota se uma plataforma de execução ainda não tiver definido exec_properties.
Tags:
affects_outputs --remote_default_platform_properties=<a string>padrão: ""-
Defina as propriedades de plataforma padrão para serem definidas para a API de execução remota, caso a plataforma de execução ainda não tenha definido remote_execution_properties. Esse valor também será usado se a plataforma host for selecionada como a plataforma de execução para execução remota.
--remote_download_regex=<a valid Java regular expression>vários usos são acumulados-
Força o download de saídas de build remoto cujo caminho corresponda a esse padrão, independente de --remote_download_outputs. É possível especificar vários padrões repetindo essa flag.
Tags:
affects_outputs --remote_downloader_header=<a 'name=value' assignment>vários usos são acumulados-
Especifique um cabeçalho que será incluído nas solicitações do downloader remoto: --remote_downloader_header=Name=Value. É possível transmitir vários cabeçalhos especificando a flag várias vezes. Vários valores para o mesmo nome serão convertidos em uma lista separada por vírgulas.
--remote_exec_header=<a 'name=value' assignment>vários usos são acumulados-
Especifique um cabeçalho que será incluído nas solicitações de execução: --remote_exec_header=Name=Value. É possível transmitir vários cabeçalhos especificando a flag várias vezes. Vários valores para o mesmo nome serão convertidos em uma lista separada por vírgulas.
--remote_execution_priority=<an integer>padrão: "0"-
A prioridade relativa das ações a serem executadas remotamente. A semântica dos valores de prioridade específicos depende do servidor.
--remote_executor=<a string>padrão: consulte a descrição-
HOST ou HOST:PORT de um endpoint de execução remota. Os esquemas compatíveis são grpc, grpcs (grpc com TLS ativado) e unix (sockets UNIX locais). Se nenhum esquema for fornecido, o Bazel vai usar grpcs como padrão. Especifique o esquema grpc:// ou unix: para desativar o TLS.
--remote_grpc_log=<a path>padrão: consulte a descrição-
Se especificado, um caminho para um arquivo para registrar detalhes relacionados à chamada gRPC. Esse registro consiste em uma sequência de protobufs com.google.devtools.build.lib.remote.logging.RemoteExecutionLog.LogEntry serializados. Cada mensagem tem um prefixo de varint que indica o tamanho da mensagem protobuf serializada a seguir, conforme realizado pelo método LogEntry.writeDelimitedTo(OutputStream).
--remote_header=<a 'name=value' assignment>vários usos são acumulados-
Especifique um cabeçalho que será incluído nas solicitações: --remote_header=Name=Value. É possível transmitir vários cabeçalhos especificando a flag várias vezes. Vários valores para o mesmo nome serão convertidos em uma lista separada por vírgulas.
--remote_instance_name=<a string>padrão: ""-
Valor a ser transmitido como "instance_name" na API de execução remota.
--[no]remote_local_fallbackpadrão: "false"-
Se é necessário voltar para a estratégia de execução local independente se a execução remota falhar.
--remote_local_fallback_strategy=<a string>padrão: "local"-
Obsoleto. Consulte https://github.com/bazelbuild/bazel/issues/7480 para mais detalhes.
- Padrão de
--remote_max_connections=<an integer>: "100" -
Limite o número máximo de conexões simultâneas com o cache/executor remoto. Por padrão, o valor é 100. Definir como 0 significa que não há limitação. Para o cache remoto HTTP, uma conexão TCP pode processar uma solicitação por vez. Assim, o Bazel pode fazer até --remote_max_connections solicitações simultâneas. Para o cache/executor remoto do gRPC, um canal do gRPC geralmente pode processar mais de 100 solicitações simultâneas. Assim, o Bazel pode fazer cerca de
--remote_max_connections * 100solicitações simultâneas. --remote_proxy=<a string>padrão: consulte a descrição-
Conecte-se ao cache remoto por um proxy. No momento, essa flag só pode ser usada para configurar um soquete de domínio Unix (unix:/path/to/socket).
--remote_result_cache_priority=<an integer>padrão: "0"-
A prioridade relativa das ações remotas a serem armazenadas no cache remoto. A semântica dos valores de prioridade específicos depende do servidor.
- Padrão de
--remote_retries=<an integer>: "5" -
O número máximo de tentativas para repetir um erro temporário. Se definido como 0, as novas tentativas serão desativadas.
- Padrão de
--remote_retry_max_delay=<An immutable length of time.>: "5s" -
O atraso máximo de espera entre tentativas remotas. As seguintes unidades podem ser usadas: dias (d), horas (h), minutos (m), segundos (s) e milissegundos (ms). Se a unidade for omitida, o valor será interpretado como segundos.
- Padrão de
--remote_timeout=<An immutable length of time.>: "60s" -
O tempo máximo de espera para execução remota e chamadas de cache. Para o cache REST, esse é o tempo limite de conexão e de leitura. As seguintes unidades podem ser usadas: dias (d), horas (h), minutos (m), segundos (s) e milissegundos (ms). Se a unidade for omitida, o valor será interpretado como segundos.
--[no]remote_upload_local_resultspadrão: "true"-
Se os resultados de ações executadas localmente devem ser enviados por upload para o cache remoto, caso ele seja compatível e o usuário tenha autorização para isso.
--[no]remote_verify_downloadspadrão: "true"-
Se definido como "true", o Bazel vai calcular a soma de hash de todos os downloads remotos e descartar os valores armazenados em cache remotamente se eles não corresponderem ao valor esperado.
- Opções diversas, não categorizadas de outra forma:
--[no]allow_analysis_cache_discardpadrão: "true"-
Se você descartar o cache de análise devido a uma mudança no sistema de build, definir essa opção como "false" fará com que o Bazel saia em vez de continuar com o build. Essa opção não tem efeito quando "discard_analysis_cache" também está definida.
Tags:
eagerness_to_exit --auto_output_filter=<none, all, packages or subpackages>padrão: "none"-
Se --output_filter não for especificado, o valor dessa opção será usado para criar um filtro automaticamente. Os valores permitidos são "none" (não filtrar nada / mostrar tudo), "all" (filtrar tudo / não mostrar nada), "packages" (incluir a saída de regras em pacotes mencionados na linha de comando do Blaze) e "subpackages" (como "packages", mas também inclui subpacotes). Para os valores "packages" e "subpackages", //java/foo e //javatests/foo são tratados como um pacote.
--[no]build_manual_testspadrão: "false"-
Força a criação de destinos de teste marcados como "manual". Os testes "manuais" são excluídos do processamento. Essa opção força a criação deles, mas não a execução.
--build_tag_filters=<comma-separated list of options>padrão: ""-
Especifica uma lista de tags separadas por vírgulas. Cada tag pode ser precedida por "-" para especificar tags excluídas. Somente os destinos que contêm pelo menos uma tag incluída e nenhuma tag excluída serão criados. Essa opção não afeta o conjunto de testes executados com o comando "test". Eles são regidos pelas opções de filtragem de teste, por exemplo, "--test_tag_filters".
--[no]build_tests_onlypadrão: "false"-
Se especificado, somente as regras *_test e test_suite serão criadas, e outros destinos especificados na linha de comando serão ignorados. Por padrão, tudo o que foi solicitado será criado.
--combined_report=<none or lcov>padrão: "lcov"-
Especifica o tipo de relatório de cobertura cumulativa desejado. No momento, apenas o LCOV é compatível.
--[no]compile_one_dependencypadrão: "false"-
Compila uma única dependência dos arquivos de argumento. Isso é útil para verificar a sintaxe de arquivos de origem em IDEs. Por exemplo, ao recriar um único destino que depende do arquivo de origem para detectar erros o mais cedo possível no ciclo de edição/build/teste. Esse argumento afeta a maneira como todos os argumentos não flag são interpretados. Em vez de serem destinos a serem criados, eles são nomes de arquivos de origem. Para cada nome de arquivo de origem, um destino arbitrário que depende dele será criado.
--deleted_packages=<comma-separated list of package names>vários usos são acumulados-
Uma lista separada por vírgulas de nomes de pacotes que o sistema de build vai considerar inexistentes, mesmo que estejam visíveis em algum lugar no caminho do pacote. Use essa opção ao excluir um subpacote "x/y" de um pacote "x" existente. Por exemplo, depois de excluir x/y/BUILD no cliente, o sistema de build poderá reclamar se encontrar um rótulo "//x:y/z" se ele ainda for fornecido por outra entrada package_path. Especificar --deleted_packages x/y evita esse problema.
--[no]discard_analysis_cachepadrão: "false"-
Descarte o cache de análise imediatamente após a conclusão da fase de análise. Reduz o uso de memória em cerca de 10%, mas torna builds incrementais mais lentos.
--disk_cache=<a path>padrão: consulte a descrição-
Um caminho para um diretório em que o Bazel pode ler e gravar ações e saídas de ações. Se o diretório não existir, ele será criado.
--embed_label=<a one-line string>padrão: ""-
Incorporar revisão de controle de origem ou rótulo de lançamento no binário
--execution_log_binary_file=<a path>padrão: consulte a descrição-
Registre os spawns executados nesse arquivo como protos SpawnExec delimitados por comprimento, de acordo com src/main/protobuf/spawn.proto. Prefira --execution_log_compact_file, que é significativamente menor e mais barato de produzir. Flags relacionadas: --execution_log_compact_file (formato compacto; mutuamente exclusivo), --execution_log_json_file (formato JSON de texto; mutuamente exclusivo), --execution_log_sort (se deve classificar o registro de execução), --subcommands (para mostrar subcomandos na saída do terminal).
--execution_log_compact_file=<a path>padrão: consulte a descrição-
Registre os spawns executados nesse arquivo como protos ExecLogEntry delimitados por comprimento, de acordo com src/main/protobuf/spawn.proto. Todo o arquivo é compactado com zstd. Flags relacionadas: --execution_log_binary_file (formato protobuf binário; mutuamente exclusivo), --execution_log_json_file (formato JSON de texto; mutuamente exclusivo), --subcommands (para mostrar subcomandos na saída do terminal).
--execution_log_json_file=<a path>padrão: consulte a descrição-
Registre as gerações executadas nesse arquivo como representações JSON delimitadas por nova linha de protos SpawnExec, de acordo com src/main/protobuf/spawn.proto. Prefira --execution_log_compact_file, que é significativamente menor e mais barato de produzir. Flags relacionadas: --execution_log_compact_file (formato compacto; mutuamente exclusivo), --execution_log_binary_file (formato protobuf binário; mutuamente exclusivo), --execution_log_sort (se deve classificar o registro de execução), --subcommands (para mostrar subcomandos na saída do terminal).
--[no]execution_log_sortpadrão: "true"-
Se o registro de execução deve ser classificado, facilitando a comparação entre invocações. Defina como "false" para evitar o uso potencialmente significativo de CPU e memória no final da invocação, ao custo de produzir o registro em ordem de execução não determinística. Aplicável apenas aos formatos binário e JSON. O formato compacto nunca é classificado.
--[no]expand_test_suitespadrão: "true"-
Expanda os destinos test_suite nos testes constituintes antes da análise. Quando essa flag está ativada (o padrão), os padrões de destino negativos são aplicados aos testes da suíte. Caso contrário, eles não são aplicados. Desativar essa flag é útil quando os aspectos de nível superior são aplicados na linha de comando. Assim, é possível analisar destinos test_suite.
Tags:
loading_and_analysis --experimental_disk_cache_gc_idle_delay=<An immutable length of time.>padrão: "5m"-
Por quanto tempo o servidor precisa ficar inativo antes que uma coleta de lixo do cache de disco ocorra. Para especificar a política de coleta de lixo, defina --experimental_disk_cache_gc_max_size e/ou --experimental_disk_cache_gc_max_age.
--experimental_disk_cache_gc_max_age=<An immutable length of time.>padrão: "0"-
Se definido como um valor positivo, o cache de disco será coletado periodicamente como lixo para remover entradas mais antigas do que essa idade. Se definido em conjunto com --experimental_disk_cache_gc_max_size, os dois critérios serão aplicados. A coleta de lixo ocorre em segundo plano quando o servidor fica inativo, conforme determinado pela flag --experimental_disk_cache_gc_idle_delay.
--experimental_disk_cache_gc_max_size=<a size in bytes, optionally followed by a K, M, G or T multiplier>padrão: "0"-
Se definido como um valor positivo, o cache de disco será coletado periodicamente para ficar abaixo desse tamanho. Se definido em conjunto com --experimental_disk_cache_gc_max_age, os dois critérios serão aplicados. A coleta de lixo ocorre em segundo plano quando o servidor fica inativo, conforme determinado pela flag --experimental_disk_cache_gc_idle_delay.
--experimental_extra_action_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>padrão: ""-
Obsoleto, substituído por "aspectos". Filtra o conjunto de metas para programar extra_actions.
--[no]experimental_extra_action_top_level_onlypadrão: "false"-
Obsoleto, substituído por "aspectos". Agenda apenas extra_actions para destinos de nível superior.
--experimental_spawn_scheduler-
Ative a execução dinâmica executando ações local e remotamente em paralelo. O Bazel gera cada ação local e remotamente e escolhe aquela que é concluída primeiro. Se uma ação for compatível com workers, a ação local será executada no modo de worker persistente. Para ativar a execução dinâmica de um mnemônico de ação individual, use as flags
--internal_spawn_schedulere--strategy=<mnemonic>=dynamic.Expande para:
--internal_spawn_scheduler
--spawn_strategy=dynamic --[no]fetchpadrão: "true"-
Permite que o comando busque dependências externas. Se definido como "false", o comando vai usar qualquer versão em cache da dependência. Se não houver nenhuma, o comando vai falhar.
- Padrão de
--local_termination_grace_seconds=<an integer>: "15" -
Tempo de espera entre o encerramento de um processo local devido a um tempo limite e o desligamento forçado dele.
--package_path=<colon-separated list of options>padrão: "%workspace%"-
Uma lista separada por dois-pontos de onde procurar pacotes. Os elementos que começam com "%workspace%" são relativos ao espaço de trabalho envolvido. Se for omitido ou estiver vazio, o padrão será a saída de "bazel info default-package-path".
--[no]show_loading_progresspadrão: "true"-
Se ativada, faz com que o Bazel imprima mensagens "Carregando pacote:".
--test_lang_filters=<comma-separated list of options>padrão: ""-
Especifica uma lista separada por vírgulas de idiomas de teste. Cada idioma pode ser precedido por "-" para especificar os idiomas excluídos. Somente os destinos de teste escritos nos idiomas especificados serão encontrados. O nome usado para cada idioma precisa ser igual ao prefixo de idioma na regra *_test, por exemplo, "cc", "java", "py" etc. Essa opção afeta o comportamento de --build_tests_only e o comando de teste.
--test_size_filters=<comma-separated list of values: small, medium, large, or enormous>padrão: ""-
Especifica uma lista separada por vírgulas de tamanhos de teste. Cada tamanho pode ser precedido por "-" para especificar tamanhos excluídos. Somente os destinos de teste que contêm pelo menos um tamanho incluído e nenhum tamanho excluído serão encontrados. Essa opção afeta o comportamento de --build_tests_only e o comando de teste.
--test_tag_filters=<comma-separated list of options>padrão: ""-
Especifica uma lista separada por vírgulas de tags de teste. Cada tag pode ser precedida por "-" para especificar tags excluídas. Somente os destinos de teste que contêm pelo menos uma tag incluída e nenhuma tag excluída serão encontrados. Essa opção afeta o comportamento de --build_tests_only e o comando de teste.
--test_timeout_filters=<comma-separated list of values: short, moderate, long, or eternal>padrão: ""-
Especifica uma lista separada por vírgulas de tempos limite de teste. Cada tempo limite pode ser precedido por "-" para especificar tempos limite excluídos. Somente os destinos de teste que contêm pelo menos um tempo limite incluído e nenhum tempo limite excluído serão encontrados. Essa opção afeta o comportamento de --build_tests_only e o comando de teste.
--workspace_status_command=<path>padrão: ""-
Um comando invocado no início do build para fornecer informações de status sobre o espaço de trabalho na forma de pares de chave/valor. Consulte o manual do usuário para ver a especificação completa. Consulte também tools/buildstamp/get_workspace_status para ver um exemplo.
- Opções que controlam a execução do build:
--[no]experimental_persistent_aar_extractorpadrão: "false"-
Ative o extrator aar permanente usando workers.
Tags:
execution,experimental --[no]experimental_remotable_source_manifestspadrão: "false"-
Se as ações do manifesto de origem podem ser executadas remotamente
--[no]experimental_split_coverage_postprocessingpadrão: "false"-
Se for verdadeiro, o Bazel vai executar o pós-processamento de cobertura para o teste em uma nova geração.
Tags:
execution,experimental --[no]experimental_strict_fileset_outputpadrão: "false"-
Se essa opção estiver ativada, os conjuntos de arquivos vão tratar todos os artefatos de saída como arquivos regulares. Eles não vão percorrer diretórios nem serão sensíveis a symlinks.
Tags:
execution,experimental --[no]incompatible_modify_execution_info_additivepadrão: "true"-
Quando ativada, a transmissão de várias flags --modify_execution_info é cumulativa. Quando desativada, apenas a última flag é considerada.
Tags:
execution,affects_outputs,loading_and_analysis,incompatible_change --modify_execution_info=<regex=[+-]key,regex=[+-]key,...>vários usos são acumulados-
Adicione ou remova chaves das informações de execução de uma ação com base no mnemônico dela. Aplicável apenas a ações que oferecem suporte a informações de execução. Muitas ações comuns oferecem suporte a informações de execução, por exemplo, Genrule, CppCompile, Javac, StarlarkAction e TestRunner. Ao especificar vários valores, a ordem é importante porque muitas expressões regulares podem ser aplicadas ao mesmo mnemônico.
Sintaxe: "regex=[+-]key,regex=[+-]key,...".
Exemplos: '.=+x,.=-y,.=+z' adiciona "x" e "z" e remove "y" das informações de execução de todas as ações. "Genrule=+requires-x" adiciona "requires-x" às informações de execução de todas as ações Genrule. '(?!Genrule).=-requires-x' remove 'requires-x' das informações de execução de todas as ações que não são Genrule.
--persistent_android_dex_desugar-
Ative ações persistentes de dex e dessugar do Android usando workers.
Expande para:
--internal_persistent_android_dex_desugar
--strategy=Desugar=worker
--strategy=DexBuilder=worker --persistent_android_resource_processor-
Ative o processador de recursos persistentes do Android usando workers.
Expande para:
--internal_persistent_busybox_tools
--strategy=AaptPackage=worker
--strategy=AndroidResourceParser=worker
--strategy=AndroidResourceValidator=worker
--strategy=AndroidResourceCompiler=worker
--strategy=RClassGenerator=worker
--strategy=AndroidResourceLink=worker
--strategy=AndroidAapt2=worker
--strategy=AndroidAssetMerger=worker
--strategy=AndroidResourceMerger=worker
--strategy=AndroidCompiledResourceMerger=worker
--strategy=ManifestMerger=worker
--strategy=AndroidManifestMerger=worker
--strategy=Aapt2Optimize=worker
--strategy=AARGenerator=worker
--strategy=ProcessDatabinding=worker
--strategy=GenerateDataBindingBaseClasses=worker --persistent_multiplex_android_dex_desugar-
Ative ações persistentes e multiplexadas de dex e dessugar do Android usando workers.
Expande para:
--persistent_android_dex_desugar
--internal_persistent_multiplex_android_dex_desugar --persistent_multiplex_android_resource_processor-
Ative o processador de recursos do Android multiplexado persistente usando workers.
Expande para:
--persistent_android_resource_processor
--modify_execution_info=AaptPackage=+supports-multiplex-workers
--modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
--modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
--modify_execution_info=RClassGenerator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
--modify_execution_info=AndroidAapt2=+supports-multiplex-workers
--modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
--modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
--modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
--modify_execution_info=ManifestMerger=+supports-multiplex-workers
--modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
--modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
--modify_execution_info=AARGenerator=+supports-multiplex-workers --persistent_multiplex_android_tools-
Ativar ferramentas Android persistentes e multiplexadas (dexing, desugaring, processamento de recursos).
Expande para:
--internal_persistent_multiplex_busybox_tools
--persistent_multiplex_android_resource_processor
--persistent_multiplex_android_dex_desugar --[no]use_target_platform_for_testspadrão: "false"-
Se for "true", use a plataforma de destino para executar testes em vez do grupo de execução de teste.
Tags:
execution
- Opções que configuram o conjunto de ferramentas usado para a execução de ações:
--android_compiler=<a string>padrão: consulte a descrição-
O compilador de destino do Android.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state --android_manifest_merger=<legacy, android or force_android>padrão: "android"-
Seleciona o combinador de manifestos a ser usado para regras android_binary. Flag para ajudar na transição do combinador legado para o combinador do manifesto do Android.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state --android_platforms=<a build target label>padrão: ""-
Define as plataformas usadas pelas segmentações android_binary. Se várias plataformas forem especificadas, o binário será um APK fat, que contém binários nativos para cada plataforma de destino especificada.
Tags:
changes_inputs,loading_and_analysis,loses_incremental_state --cc_output_directory_tag=<a string>padrão: ""-
Especifica um sufixo a ser adicionado ao diretório de configuração.
Tags:
affects_outputs --compiler=<a string>padrão: consulte a descrição-
O compilador C++ a ser usado para compilar o destino.
Tags:
loading_and_analysis,execution --coverage_output_generator=<a build target label>default: "@bazel_tools//tools/test:lcov_merger"-
Local do binário usado para pós-processar relatórios de cobertura bruta. Precisa ser uma meta binária. O padrão é "//tools/test:lcov_merger".
--coverage_report_generator=<a build target label>default: "@bazel_tools//tools/test:coverage_report_generator"-
Local do binário usado para gerar relatórios de cobertura. Precisa ser uma meta binária. O padrão é "//tools/test:coverage_report_generator".
--coverage_support=<a build target label>default: "@bazel_tools//tools/test:coverage_support"-
Localização dos arquivos de suporte necessários nas entradas de todas as ações de teste que coletam cobertura de código. O padrão é "//tools/test:coverage_support".
--custom_malloc=<a build target label>padrão: consulte a descrição-
Especifica uma implementação de malloc personalizada. Essa configuração substitui os atributos malloc nas regras de build.
Tags:
changes_inputs,affects_outputs --[no]experimental_include_xcode_execution_requirementspadrão: "false"-
Se definido, adicione um requisito de execução "requires-xcode:{version}" a todas as ações do Xcode. Se a versão do Xcode tiver um rótulo hifenizado, adicione também um requisito de execução "requires-xcode-label:{version_label}".
Tags:
loses_incremental_state,loading_and_analysis,execution,experimental --[no]experimental_prefer_mutual_xcodepadrão: "true"-
Se for "true", use o Xcode mais recente disponível local e remotamente. Se for "false" ou se não houver versões disponíveis em comum, use a versão local do Xcode selecionada com xcode-select.
--extra_execution_platforms=<comma-separated list of options>padrão: ""-
As plataformas disponíveis como plataformas de execução para realizar ações. As plataformas podem ser especificadas por segmentação exata ou como um padrão de segmentação. Essas plataformas serão consideradas antes daquelas declaradas no arquivo WORKSPACE por register_execution_platforms(). Essa opção só pode ser definida uma vez. Instâncias posteriores vão substituir as configurações de flag anteriores.
Tags:
execution --extra_toolchains=<comma-separated list of options>vários usos são acumulados-
As regras da cadeia de ferramentas a serem consideradas durante a resolução da cadeia de ferramentas. As toolchains podem ser especificadas por destino exato ou como um padrão de destino. Esses conjuntos de ferramentas serão considerados antes daqueles declarados no arquivo WORKSPACE por register_toolchains().
--grte_top=<a label>padrão: consulte a descrição-
Um rótulo para uma biblioteca libc registrada. O valor padrão é selecionado pela cadeia de ferramentas crosstool, e quase nunca é necessário substituir esse valor.
--host_compiler=<a string>padrão: consulte a descrição-
Flag de nenhuma operação. Será removido em uma versão futura.
Tags:
loading_and_analysis,execution --host_grte_top=<a label>padrão: consulte a descrição-
Se especificada, essa configuração vai substituir o diretório de nível superior da libc (--grte_top) para a configuração de execução.
--host_platform=<a build target label>default: "@bazel_tools//tools:host_platform"-
O rótulo de uma regra de plataforma que descreve o sistema host.
--[no]incompatible_bazel_test_exec_run_underpadrão: "true"-
Se ativado, "bazel test --run_under=//:runner" vai criar "//:runner" na configuração de execução. Se estiver desativado, ele vai criar "//:runner" na configuração de destino. O Bazel executa testes em máquinas de execução, então o primeiro é mais correto. Isso não afeta "bazel run", que sempre cria "`--run_under=//foo" na configuração de destino.
--[no]incompatible_builtin_objc_strip_actionpadrão: "true"-
Se uma ação de remoção deve ser emitida como parte da vinculação objc.
--[no]incompatible_dont_enable_host_nonhost_crosstool_featurespadrão: "true"-
Se for "true", o Bazel não vai ativar os recursos "host" e "nonhost" na cadeia de ferramentas do C++ (consulte https://github.com/bazelbuild/bazel/issues/7407 para mais informações).
--[no]incompatible_enable_apple_toolchain_resolutionpadrão: "false"-
Use a resolução da cadeia de ferramentas para selecionar o SDK da Apple para regras da Apple (Starlark e nativas).
--[no]incompatible_remove_legacy_whole_archivepadrão: "true"-
Se for "true", o Bazel não vai vincular dependências de biblioteca como um arquivo inteiro por padrão. Consulte https://github.com/bazelbuild/bazel/issues/7362 para instruções de migração.
--[no]incompatible_strip_executable_safelypadrão: "false"-
Se for verdadeiro, a ação de remoção para executáveis usará a flag -x, que não interrompe a resolução dinâmica de símbolos.
-
Use objetos compartilhados de interface se forem compatíveis com o conjunto de ferramentas. Todas as toolchains ELF são compatíveis com essa configuração.
Tags:
loading_and_analysis,affects_outputs,affects_outputs --ios_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Especifica a versão do SDK para iOS a ser usada para criar aplicativos iOS. Se não for especificado, usará a versão padrão do SDK para iOS de "xcode_version".
Tags:
loses_incremental_state --macos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Especifica a versão do SDK do macOS a ser usada para criar aplicativos desse sistema operacional. Se não for especificado, usará a versão padrão do SDK do macOS de "xcode_version".
Tags:
loses_incremental_state --minimum_os_version=<a string>padrão: consulte a descrição-
A versão mínima do SO que sua compilação segmenta.
--platform_mappings=<a main workspace-relative path>padrão: ""-
O local de um arquivo de mapeamento que descreve qual plataforma usar se nenhuma estiver definida ou quais flags definir quando uma plataforma já existir. Precisa ser relativo à raiz do espaço de trabalho principal. O padrão é "platform_mappings", um arquivo diretamente na raiz do espaço de trabalho.
Tags:
affects_outputs,changes_inputs,loading_and_analysis,non_configurable --platforms=<a build target label>padrão: ""-
Os rótulos das regras de plataforma que descrevem as plataformas de destino para o comando atual.
--python_path=<a string>padrão: consulte a descrição-
O caminho absoluto do interpretador Python invocado para executar destinos Python na plataforma de destino. Obsoleto. Desativado por --incompatible_use_python_toolchains.
--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Especifica a versão do SDK do tvOS a ser usada para criar aplicativos desse sistema operacional. Se não for especificado, usará a versão padrão do SDK do tvOS de "xcode_version".
Tags:
loses_incremental_state --[no]use_platforms_in_apple_crosstool_transitionpadrão: "false"-
Faz com que apple_crosstool_transition volte a usar o valor da flag
--platformsem vez do--cpulegado quando necessário.Tags:
loading_and_analysis --watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Especifica a versão do SDK do watchOS a ser usada para criar aplicativos do watchOS. Se não for especificado, usará a versão padrão do SDK do watchOS de "xcode_version".
Tags:
loses_incremental_state --xcode_version=<a string>padrão: consulte a descrição-
Se especificado, usa o Xcode da versão fornecida para ações de build relevantes. Se não for especificado, vai usar a versão padrão do executor do Xcode.
Tags:
loses_incremental_state --xcode_version_config=<a build target label>default: "@bazel_tools//tools/cpp:host_xcodes"-
O rótulo da regra xcode_config a ser usada para selecionar a versão do Xcode na configuração de build.
- Opções que controlam a saída do comando:
--[no]apple_generate_dsympadrão: "false"-
Se é necessário gerar arquivos de símbolos de depuração (.dSYM).
--[no]build_runfile_linkspadrão: "true"-
Se for verdadeiro, vai criar florestas de symlink de runfiles para todos os destinos. Se for "false", grave-os apenas quando exigido por uma ação, teste ou comando de execução local.
Tags:
affects_outputs --[no]build_runfile_manifestspadrão: "true"-
Se verdadeiro, grava manifestos de runfiles para todos os destinos. Se for "false", omita-os. Os testes locais não serão executados quando for "false".
Tags:
affects_outputs --[no]build_test_dwppadrão: "false"-
Se ativado, ao criar testes em C++ de forma estática e com fusão, o arquivo .dwp do binário de teste também será criado automaticamente.
--cc_proto_library_header_suffixes=<comma-separated set of options>padrão: ".pb.h"-
Define os sufixos dos arquivos de cabeçalho que uma cc_proto_library cria.
- Padrão de
--cc_proto_library_source_suffixes=<comma-separated set of options>: ".pb.cc" -
Define os sufixos dos arquivos de origem que uma cc_proto_library cria.
--[no]experimental_proto_descriptor_sets_include_source_infopadrão: "false"-
Executa ações extras para versões alternativas da API Java em uma proto_library.
--[no]experimental_save_feature_statepadrão: "false"-
Salve o estado dos recursos ativados e solicitados como uma saída da compilação.
Tags:
affects_outputs,experimental --fission=<a set of compilation modes>padrão: "no"-
Especifica quais modos de compilação usam a fissão para compilações e vinculações em C++. Pode ser qualquer combinação de {'fastbuild', 'dbg', 'opt'} ou os valores especiais 'yes' para ativar todos os modos e 'no' para desativar todos os modos.
Tags:
loading_and_analysis,action_command_lines,affects_outputs --[no]incompatible_always_include_files_in_datapadrão: "true"-
Se for verdadeiro, as regras nativas vão adicionar <code>DefaultInfo.files</code> de dependências de dados aos runfiles, o que corresponde ao comportamento recomendado para regras do Starlark (https://bazel.build/extending/rules#runfiles_features_to_avoid).
--[no]incompatible_compact_repo_mapping_manifestpadrão: "false"-
Se ativado, o arquivo <binary>.repo_mapping vai emitir o mapeamento de repositório de uma extensão de módulo apenas uma vez, em vez de uma vez para cada repositório gerado pela extensão que contribui com runfiles.
--incompatible_disable_select_on=<comma-separated set of options>padrão: ""-
Lista de flags para as quais o uso em select() está desativado.
Tags:
loading_and_analysis,incompatible_change,non_configurable --[no]incompatible_filegroup_runfiles_for_datapadrão: "true"-
Se for verdadeiro, os runfiles dos destinos listados no atributo "srcs" estarão disponíveis para os destinos que consomem o filegroup como uma dependência de dados.
Tags:
incompatible_change --[no]objc_generate_linkmappadrão: "false"-
Especifica se um arquivo linkmap será gerado.
Tags:
affects_outputs --[no]save_tempspadrão: "false"-
Se definido, as saídas temporárias do gcc serão salvas. Eles incluem arquivos .s (código de assembler), .i (C pré-processado) e .ii (C++ pré-processado).
Tags:
affects_outputs
- Opções que permitem ao usuário configurar a saída pretendida, afetando o valor dela, e não a existência:
--action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable>vários usos são acumulados-
Especifica o conjunto de variáveis de ambiente disponíveis para ações com configuração de destino. As variáveis podem ser especificadas por <code>name</code>, em que o valor é extraído do ambiente de invocação, pelo par <code>name=value</code>, que define o valor independente do ambiente de invocação, ou por <code>=name</code>, que desativa a variável com esse nome. Essa opção pode ser usada várias vezes. Para opções fornecidas para a mesma variável, a mais recente vence. Para variáveis diferentes, as opções são acumuladas. <br> A menos que <code>--incompatible_repo_env_ignores_action_env</code> seja verdadeiro, todos os pares <code>name=value</code> estarão disponíveis para as regras do repositório.
Tags:
action_command_lines --allowed_cpu_values=<comma-separated set of options>padrão: ""-
Valores permitidos para a flag "--cpu".
Tags:
changes_inputs,affects_outputs --[no]android_databinding_use_androidxpadrão: "true"-
Gere arquivos de vinculação de dados compatíveis com o AndroidX. Isso só é usado com a vinculação de dados v2. Essa flag não faz nada.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --[no]android_databinding_use_v3_4_argspadrão: "true"-
Use a vinculação de dados do Android v2 com o argumento 3.4.0. Essa flag não faz nada.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --android_dynamic_mode=<off, default or fully>padrão: "off"-
Determina se as dependências C++ das regras do Android serão vinculadas dinamicamente quando um cc_binary não criar explicitamente uma biblioteca compartilhada. "default" significa que o bazel vai escolher se a vinculação será dinâmica. "Totalmente" significa que todas as bibliotecas serão vinculadas dinamicamente. "off" significa que todas as bibliotecas serão vinculadas principalmente no modo estático.
- Padrão de
--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency>: "alphabetical" -
Define a ordem dos manifestos transmitidos à ferramenta de mescla de manifestos para binários do Android. ALPHABETICAL significa que os manifestos são classificados por caminho em relação ao execroot. ALPHABETICAL_BY_CONFIGURATION significa que os manifestos são classificados por caminhos relativos ao diretório de configuração no diretório de saída. DEPENDENCY significa que os manifestos são ordenados com o manifesto de cada biblioteca antes dos manifestos das dependências dela.
Tags:
action_command_lines,execution --[no]android_resource_shrinkingpadrão: "false"-
Ativa a redução de recursos para APKs android_binary que usam o ProGuard.
--[no]build_python_zippadrão: "auto"-
Criar zip executável do Python; ativado no Windows, desativado em outras plataformas
Tags:
affects_outputs --catalyst_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar binários do Apple Catalyst.
--[no]collect_code_coveragepadrão: "false"-
Se especificado, o Bazel vai instrumentar o código (usando instrumentação off-line sempre que possível) e coletar informações de cobertura durante os testes. Apenas os destinos que correspondem a --instrumentation_filter serão afetados. Normalmente, essa opção não deve ser especificada diretamente. Em vez disso, use o comando "bazel coverage".
Tags:
affects_outputs --compilation_mode=<fastbuild, dbg or opt>[-c] padrão: "fastbuild"-
Especifique o modo em que o binário será criado. Valores: "fastbuild", "dbg", "opt".
--conlyopt=<a string>vários usos são acumulados-
Opção adicional para transmitir ao gcc ao compilar arquivos de origem C.
--copt=<a string>vários usos são acumulados-
Outras opções para transmitir ao gcc.
--cpu=<a string>padrão: ""-
Descontinuada: essa flag não é usada internamente pelo Blaze, embora haja mapeamentos de plataforma legados para permitir a compatibilidade com versões anteriores. Não use essa flag. Em vez disso, use --platforms com uma definição de plataforma adequada.
Tags:
changes_inputs,affects_outputs --cs_fdo_absolute_path=<a string>padrão: consulte a descrição-
Use informações de perfil do CSFDO para otimizar a compilação. Especifique o nome do caminho absoluto do arquivo ZIP que contém o arquivo de perfil, um arquivo de perfil LLVM bruto ou indexado.
Tags:
affects_outputs --cs_fdo_instrument=<a string>padrão: consulte a descrição-
Gere binários com instrumentação FDO sensível ao contexto. Com o compilador Clang/LLVM, ele também aceita o nome do diretório em que os arquivos de perfil brutos serão despejados durante a execução.
Tags:
affects_outputs --cs_fdo_profile=<a build target label>padrão: consulte a descrição-
O cs_fdo_profile que representa o perfil sensível ao contexto a ser usado para otimização.
Tags:
affects_outputs --cxxopt=<a string>vários usos são acumulados-
Opção extra para transmitir ao gcc ao compilar arquivos de origem C++.
--define=<a 'name=value' assignment>vários usos são acumulados-
Cada opção "--define" especifica uma atribuição para uma variável de build. Em caso de vários valores para uma variável, o último vence.
Tags:
changes_inputs,affects_outputs --dynamic_mode=<off, default or fully>padrão: "default"-
Determina se os binários C++ serão vinculados dinamicamente. "default" significa que o Bazel vai escolher se a vinculação será dinâmica. "Totalmente" significa que todas as bibliotecas serão vinculadas dinamicamente. "off" significa que todas as bibliotecas serão vinculadas principalmente no modo estático.
--[no]enable_propeller_optimize_absolute_pathspadrão: "true"-
Se definido, qualquer uso de caminhos absolutos para a otimização do Propeller vai gerar um erro.
Tags:
affects_outputs --[no]enable_remaining_fdo_absolute_pathspadrão: "true"-
Se definido, qualquer uso de caminhos absolutos para FDO vai gerar um erro.
Tags:
affects_outputs --[no]enable_runfilespadrão: "auto"-
Ative a árvore de symlink de runfiles. Por padrão, ela fica desativada no Windows e ativada em outras plataformas.
Tags:
affects_outputs --exec_aspects=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de aspectos a serem aplicados a destinos configurados por execução, sejam eles de nível superior ou não. Este é um recurso experimental e está sujeito a mudanças.
Tags:
loading_and_analysis --experimental_action_listener=<a build target label>vários usos são acumulados-
Obsoleto, substituído por "aspectos". Use action_listener para anexar uma extra_action a ações de build atuais.
Tags:
execution,experimental --[no]experimental_android_compress_java_resourcespadrão: "false"-
Compactar recursos Java em APKs
--[no]experimental_android_databinding_v2padrão: "true"-
Use a vinculação de dados do Android v2. Essa flag não faz nada.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --[no]experimental_android_resource_shrinkingpadrão: "false"-
Ativa a redução de recursos para APKs android_binary que usam o ProGuard.
--[no]experimental_android_rewrite_dexes_with_rexpadrão: "false"-
usar a ferramenta rex para reescrever arquivos dex
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --[no]experimental_collect_code_coverage_for_generated_filespadrão: "false"-
Se especificado, o Bazel também vai gerar informações de cobertura de coleta para arquivos gerados.
Tags:
affects_outputs,experimental --experimental_objc_fastbuild_options=<comma-separated list of options>padrão: "-O0,-DDEBUG=1"-
Usa essas strings como opções do compilador objc fastbuild.
Tags:
action_command_lines --[no]experimental_omitfppadrão: "false"-
Se for verdadeiro, use libunwind para desenrolar a pilha e compile com -fomit-frame-pointer e -fasynchronous-unwind-tables.
--experimental_output_paths=<off or strip>padrão: "off"-
Qual modelo usar para onde as regras da árvore de saída gravam as saídas, principalmente para builds multiplataforma / multiconfiguração. Esse recurso é altamente experimental. Consulte https://github.com/bazelbuild/bazel/issues/6526 para mais detalhes. As ações do Starlark podem ativar o mapeamento de caminhos adicionando a chave "supports-path-mapping" ao dicionário "execution_requirements".
Tags:
loses_incremental_state,bazel_internal_configuration,affects_outputs,execution --experimental_override_platform_cpu_name=<a 'label=value' assignment>vários usos são acumulados-
Cada entrada precisa estar no formato "label=value", em que "label" se refere a uma plataforma e "value" é o nome abreviado desejado para substituir o nome da CPU da plataforma na variável de make $(TARGET_CPU) e no caminho de saída. Usado somente quando --experimental_platform_in_output_dir, --incompatible_target_cpu_from_platform ou --incompatible_bep_cpu_from_platform é verdadeiro. Tem a maior prioridade de nomenclatura.
Tags:
affects_outputs,experimental --[no]experimental_platform_in_output_dirpadrão: "false"-
Se for "true", um nome abreviado para a plataforma de destino será usado no nome do diretório de saída em vez da CPU. Se for "auto", isso só será aplicado à configuração de execução. O esquema exato é experimental e está sujeito a mudanças. Primeiro, no caso raro em que a opção "--platforms" não tem exatamente um valor, um hash da opção "platforms" é usado. Em seguida, se um nome abreviado para a plataforma atual foi registrado por --experimental_override_name_platform_in_output_dir, esse nome abreviado será usado. Em seguida, se --experimental_use_platforms_in_output_dir_legacy_heuristic estiver definido, use um nome abreviado com base no rótulo da plataforma atual. Por fim, um hash da opção de plataforma é usado como último recurso.
Tags:
affects_outputs,experimental --[no]experimental_py_binaries_include_labelpadrão: "false"-
Os destinos py_binary incluem o rótulo mesmo quando a inclusão de carimbos está desativada.
Tags:
affects_outputs,experimental --[no]experimental_use_llvm_covmappadrão: "false"-
Se especificado, o Bazel vai gerar informações de mapa de cobertura llvm-cov em vez de gcov quando collect_code_coverage estiver ativado.
Tags:
changes_inputs,affects_outputs,loading_and_analysis,experimental --[no]experimental_use_platforms_in_output_dir_legacy_heuristicpadrão: "true"-
Use essa flag apenas como parte de uma estratégia de migração ou teste sugerida. A heurística tem deficiências conhecidas. Por isso, recomendamos migrar para usar apenas --experimental_override_name_platform_in_output_dir.
Tags:
affects_outputs,experimental --fdo_instrument=<a string>padrão: consulte a descrição-
Gere binários com instrumentação FDO. Com o compilador Clang/LLVM, ele também aceita o nome do diretório em que os arquivos de perfil brutos serão despejados durante a execução.
Tags:
affects_outputs --fdo_optimize=<a string>padrão: consulte a descrição-
Use informações de perfil da FDO para otimizar a compilação. Especifique o nome de um arquivo zip que contenha uma árvore de arquivos .gcda, um arquivo afdo com um perfil automático ou um arquivo de perfil LLVM. Essa flag também aceita arquivos especificados como rótulos (por exemplo,
//foo/bar:file.afdo. Talvez seja necessário adicionar uma diretivaexports_filesao pacote correspondente) e rótulos que apontam para destinosfdo_profile. Essa flag será substituída pela regrafdo_profile.Tags:
affects_outputs --fdo_prefetch_hints=<a build target label>padrão: consulte a descrição-
Use dicas de pré-busca de cache.
Tags:
affects_outputs --fdo_profile=<a build target label>padrão: consulte a descrição-
O fdo_profile que representa o perfil a ser usado para otimização.
Tags:
affects_outputs --features=<a string>vários usos são acumulados-
Os recursos especificados serão ativados ou desativados por padrão para destinos criados na configuração de destino. Especificar -<recurso> desativa o recurso. Recursos negativos sempre substituem os positivos. Consulte também --host_features
Tags:
changes_inputs,affects_outputs --[no]force_picpadrão: "false"-
Se ativada, todas as compilações em C++ produzem código independente de posição ("-fPIC"), as vinculações preferem bibliotecas pré-criadas PIC em vez de bibliotecas não PIC, e as vinculações produzem executáveis independentes de posição ("-pie").
--host_action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable>vários usos são acumulados-
Especifica o conjunto de variáveis de ambiente disponíveis para ações com configurações de execução. As variáveis podem ser especificadas por nome, caso em que o valor será extraído do ambiente de invocação, pelo par nome=valor, que define o valor independente do ambiente de invocação, ou por <code>=name</code>, que desativa a variável desse nome. Essa opção pode ser usada várias vezes. Para opções fornecidas para a mesma variável, a mais recente vence. Para variáveis diferentes, as opções são acumuladas.
Tags:
action_command_lines --host_compilation_mode=<fastbuild, dbg or opt>padrão: "opt"-
Especifique o modo em que as ferramentas usadas durante a criação serão criadas. Valores: "fastbuild", "dbg", "opt".
--host_conlyopt=<a string>vários usos são acumulados-
Opção extra para transmitir ao compilador C ao compilar arquivos de origem C (mas não C++) nas configurações de execução.
--host_copt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas ao compilador C para ferramentas criadas nas configurações de execução.
--host_cpu=<a string>padrão: ""-
A CPU do host.
Tags:
changes_inputs,affects_outputs --host_cxxopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas ao compilador C++ para ferramentas criadas nas configurações de execução.
--host_features=<a string>vários usos são acumulados-
Os recursos especificados serão ativados ou desativados por padrão para destinos criados na configuração de execução. Especificar -<recurso> desativa o recurso. Recursos negativos sempre substituem os positivos.
Tags:
changes_inputs,affects_outputs --host_linkopt=<a string>vários usos são acumulados-
Opção extra para transmitir ao vinculador ao vincular ferramentas nas configurações de execução.
--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do macOS para destinos de host. Se não for especificado, usará "macos_sdk_version".
Tags:
loses_incremental_state --host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>vários usos são acumulados-
Outras opções para transmitir seletivamente ao compilador C/C++ ao compilar determinados arquivos nas configurações de execução. Essa opção pode ser transmitida várias vezes. Sintaxe: regex_filter@option_1,option_2,...,option_n. Em que regex_filter representa uma lista de padrões de expressões regulares de inclusão e exclusão (consulte também --instrumentation_filter). option_1 a option_n representam opções arbitrárias de linha de comando. Se uma opção tiver uma vírgula, ela precisa ser colocada entre aspas com uma barra invertida. As opções podem conter @. Somente o primeiro @ é usado para dividir a string. Exemplo: --host_per_file_copt=//foo/.*.cc,-//foo/bar.cc@-O0 adiciona a opção de linha de comando -O0 à linha de comando do gcc de todos os arquivos cc em //foo/, exceto bar.cc.
--[no]incompatible_auto_exec_groupspadrão: "false"-
Quando ativado, um grupo de execução é criado automaticamente para cada cadeia de ferramentas usada por uma regra. Para que isso funcione, a regra precisa especificar o parâmetro
toolchainnas ações dela. Para mais informações, consulte https://github.com/bazelbuild/bazel/issues/17134. --[no]incompatible_merge_genfiles_directorypadrão: "true"-
Se for verdadeiro, o diretório "genfiles" será incorporado ao diretório "bin".
--[no]incompatible_target_cpu_from_platformpadrão: "true"-
Se especificado, o valor da restrição de CPU (@platforms//cpu:cpu) da plataforma de destino será usado para definir a variável de criação $(TARGET_CPU).
--[no]instrument_test_targetspadrão: "false"-
Quando a cobertura está ativada, especifica se as regras de teste de instrumentação devem ser consideradas. Quando definido, as regras de teste incluídas por --instrumentation_filter são instrumentadas. Caso contrário, as regras de teste são sempre excluídas da instrumentação de cobertura.
Tags:
affects_outputs --instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>padrão: "-/javatests[/:],-/test/java[/:]"-
Quando a cobertura está ativada, apenas as regras com nomes incluídos pelo filtro especificado baseado em regex são instrumentadas. As regras com o prefixo "-" são excluídas. Somente regras que não são de teste são instrumentadas, a menos que a flag --instrument_test_targets esteja ativada.
Tags:
affects_outputs --ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do iOS para simuladores e dispositivos de destino. Se não for especificado, usará "ios_sdk_version".
Tags:
loses_incremental_state --ios_multi_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar um ios_application. O resultado é um binário universal que contém todas as arquiteturas especificadas.
--[no]legacy_whole_archivepadrão: "true"-
Obsoleto, substituído por --incompatible_remove_legacy_whole_archive. Consulte https://github.com/bazelbuild/bazel/issues/7362 para mais detalhes. Quando ativada, use --whole-archive para regras cc_binary que tenham linkshared=True e linkstatic=True ou "-static" em linkopts. Isso é apenas para compatibilidade com versões anteriores. Uma alternativa melhor é usar alwayslink=1 quando necessário.
--linkopt=<a string>vários usos são acumulados-
Opção extra a ser transmitida para o gcc ao vincular.
--ltobackendopt=<a string>vários usos são acumulados-
Opção adicional para transmitir à etapa de back-end do LTO (em --features=thin_lto).
--ltoindexopt=<a string>vários usos são acumulados-
Opção adicional para transmitir à etapa de indexação do LTO (em --features=thin_lto).
--macos_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para as quais criar binários do Apple macOS.
--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do macOS para destinos. Se não for especificado, usará "macos_sdk_version".
Tags:
loses_incremental_state --memprof_profile=<a build target label>padrão: consulte a descrição-
Usar o perfil memprof.
Tags:
affects_outputs --[no]objc_debug_with_GLIBCXXpadrão: "false"-
Se definido e o modo de compilação for "dbg", defina GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC e GLIBCPP_CONCEPT_CHECKS.
Tags:
action_command_lines --[no]objc_enable_binary_strippingpadrão: "false"-
Se é necessário realizar remoções de símbolos e código morto em binários vinculados. A remoção de binários será realizada se esta flag e --compilation_mode=opt forem especificadas.
Tags:
action_command_lines --objccopt=<a string>vários usos são acumulados-
Opções extras a serem transmitidas para o gcc ao compilar arquivos de origem Objective-C/C++.
Tags:
action_command_lines --per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>vários usos são acumulados-
Outras opções para transmitir seletivamente ao gcc ao compilar determinados arquivos. Essa opção pode ser transmitida várias vezes. Sintaxe: regex_filter@option_1,option_2,...,option_n. Em que regex_filter representa uma lista de padrões de expressões regulares de inclusão e exclusão (consulte também --instrumentation_filter). option_1 a option_n representam opções arbitrárias de linha de comando. Se uma opção tiver uma vírgula, ela precisa ser colocada entre aspas com uma barra invertida. As opções podem conter @. Somente o primeiro @ é usado para dividir a string. Exemplo: --per_file_copt=//foo/.*.cc,-//foo/bar.cc@-O0 adiciona a opção de linha de comando -O0 à linha de comando gcc de todos os arquivos cc em //foo/, exceto bar.cc.
--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>vários usos são acumulados-
Outras opções para transmitir seletivamente ao back-end do LTO (em --features=thin_lto) ao compilar determinados objetos de back-end. Essa opção pode ser transmitida várias vezes. Sintaxe: regex_filter@option_1,option_2,...,option_n. Em que regex_filter representa uma lista de padrões de expressão regular de inclusão e exclusão, e option_1 a option_n representam opções arbitrárias de linha de comando. Se uma opção tiver uma vírgula, ela precisa ser colocada entre aspas com uma barra invertida. As opções podem conter @. Somente o primeiro @ é usado para dividir a string. Exemplo: --per_file_ltobackendopt=//foo/.*.o,-//foo/bar.o@-O0 adiciona a opção de linha de comando -O0 à linha de comando do back-end LTO de todos os arquivos o em //foo/, exceto bar.o.
--platform_suffix=<a string>padrão: consulte a descrição-
Especifica um sufixo a ser adicionado ao diretório de configuração.
Tags:
loses_incremental_state,affects_outputs,loading_and_analysis --propeller_optimize=<a build target label>padrão: consulte a descrição-
Use as informações do perfil do Propeller para otimizar o destino do build.Um perfil do Propeller precisa consistir em pelo menos um de dois arquivos: um perfil cc e um perfil ld. Essa flag aceita um rótulo de build que precisa se referir aos arquivos de entrada do perfil do Propeller. Por exemplo, o arquivo BUILD que define o rótulo, em a/b/BUILD:propeller_optimize( name = "propeller_profile", cc_profile = "propeller_cc_profile.txt", ld_profile = "propeller_ld_profile.txt",)Talvez seja necessário adicionar uma diretiva exports_files ao pacote correspondente para tornar esses arquivos visíveis ao Bazel. A opção precisa ser usada como: --propeller_optimize=//a/b:propeller_profile
--propeller_optimize_absolute_cc_profile=<a string>padrão: consulte a descrição-
Nome do caminho absoluto do arquivo cc_profile para builds otimizados do Propeller.
Tags:
affects_outputs --propeller_optimize_absolute_ld_profile=<a string>padrão: consulte a descrição-
Nome do caminho absoluto do arquivo ld_profile para builds otimizados do Propeller.
Tags:
affects_outputs --run_under=<a prefix in front of command>padrão: consulte a descrição-
Prefixo a ser inserido antes dos executáveis dos comandos "test" e "run". Se o valor for "foo -bar" e a linha de comando de execução for "test_binary -baz", a linha de comando final será "foo -bar test_binary -baz".Isso também pode ser um rótulo para um destino executável. Alguns exemplos são: "valgrind", "strace", "strace -c", "valgrind --quiet --num-callers=20", "//package:target", "//package:target --options".
Tags:
action_command_lines -
Se for "true", as bibliotecas nativas com funcionalidade idêntica serão compartilhadas entre diferentes destinos.
--[no]stamppadrão: "false"-
Adicionar carimbo aos binários com a data, o nome de usuário, o nome do host, as informações do espaço de trabalho etc.
Tags:
affects_outputs - Padrão de
--strip=<always, sometimes or never>: "sometimes" -
Especifica se os binários e as bibliotecas compartilhadas devem ser removidos (usando "-Wl,--strip-debug"). O valor padrão "sometimes" significa remover se --compilation_mode=fastbuild.
Tags:
affects_outputs --stripopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas para a remoção ao gerar um binário "<name>.stripped".
--tvos_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar binários do Apple tvOS.
--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do tvOS para simuladores e dispositivos de destino. Se não for especificado, usará "tvos_sdk_version".
Tags:
loses_incremental_state --visionos_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar binários do Apple visionOS.
--watchos_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar binários do Apple watchOS.
--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do watchOS para simuladores e dispositivos de destino. Se não for especificado, usará "watchos_sdk_version".
Tags:
loses_incremental_state --xbinary_fdo=<a build target label>padrão: consulte a descrição-
Use informações de perfil do XbinaryFDO para otimizar a compilação. Especifique o nome do perfil binário cruzado padrão. Quando a opção é usada com --fdo_instrument/--fdo_optimize/--fdo_profile, essas opções sempre prevalecem como se xbinary_fdo nunca fosse especificado.
Tags:
affects_outputs
- Opções que afetam a rigidez com que o Bazel aplica entradas de build válidas (definições de regras, combinações de flags etc.):
--[no]check_visibilitypadrão: "true"-
Se desativado, os erros de visibilidade nas dependências de destino serão rebaixados para avisos.
--[no]desugar_for_androidpadrão: "true"-
Define se o bytecode Java 8 deve ser simplificado antes da conversão para DEX.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state --[no]desugar_java8_libspadrão: "false"-
Se as bibliotecas Java 8 compatíveis devem ser incluídas em apps para dispositivos legados.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --[no]enforce_constraintspadrão: "true"-
Verifica os ambientes com que cada destino é compatível e informa erros se algum destino tiver dependências que não oferecem suporte aos mesmos ambientes.
Tags:
build_file_semantics --[no]experimental_check_desugar_depspadrão: "true"-
Se é necessário verificar novamente a dessugarização correta no nível binário do Android.
--[no]experimental_enforce_transitive_visibilitypadrão: "false"-
Se verdadeiro, permite que package()s definam o atributo transitive_visibility para restringir quais pacotes podem depender deles.
Tags:
build_file_semantics,experimental --experimental_one_version_enforcement=<off, warning or error>padrão: "OFF"-
Quando ativada, essa opção exige que uma regra java_binary não contenha mais de uma versão do mesmo arquivo de classe no classpath. Essa aplicação pode interromper o build ou apenas resultar em avisos.
Tags:
loading_and_analysis --experimental_strict_java_deps=<off, warn, error, strict or default>padrão: "default"-
Se for verdadeiro, verifica se um destino Java declara explicitamente todos os destinos usados diretamente como dependências.
--[no]incompatible_check_testonly_for_output_filespadrão: "false"-
Se ativado, verifique testonly para destinos de pré-requisito que são arquivos de saída pesquisando o testonly da regra geradora. Isso corresponde à verificação de visibilidade.
--[no]incompatible_disable_native_android_rulespadrão: "false"-
Se ativada, o uso direto das regras nativas do Android será desativado. Use as regras do Starlark Android em https://github.com/bazelbuild/rules_android
--[no]incompatible_disable_native_apple_binary_rulepadrão: "false"-
Não faz nada. Mantido aqui para compatibilidade com versões anteriores.
--[no]one_version_enforcement_on_java_testspadrão: "true"-
Quando ativada e com experimental_one_version_enforcement definido como um valor diferente de NONE, impõe uma versão em destinos java_test. Essa flag pode ser desativada para melhorar a performance do teste incremental, mas isso pode fazer com que possíveis violações de uma versão sejam perdidas.
Tags:
loading_and_analysis --python_native_rules_allowlist=<a build target label>padrão: consulte a descrição-
Uma lista de permissões (destino package_group) a ser usada ao aplicar --incompatible_python_disallow_native_rules.
Tags:
loading_and_analysis --[no]strict_filesetspadrão: "false"-
Se essa opção estiver ativada, os conjuntos de arquivos que cruzam os limites do pacote serão informados como erros.
--strict_proto_deps=<off, warn, error, strict or default>padrão: "error"-
A menos que esteja OFF, verifica se um destino proto_library declara explicitamente todos os destinos usados diretamente como dependências.
Tags:
build_file_semantics,eagerness_to_exit,incompatible_change --strict_public_imports=<off, warn, error, strict or default>padrão: "off"-
A menos que esteja OFF, verifica se um destino proto_library declara explicitamente como exportados todos os destinos usados em "import public".
Tags:
build_file_semantics,eagerness_to_exit,incompatible_change --[no]strict_system_includespadrão: "false"-
Se for "true", os cabeçalhos encontrados por caminhos de inclusão do sistema (-isystem) também precisarão ser declarados.
--target_environment=<a build target label>vários usos são acumulados-
Declara o ambiente de destino deste build. Precisa ser uma referência de rótulo a uma regra de "ambiente". Se especificado, todos os destinos de nível superior precisam ser compatíveis com esse ambiente.
Tags:
changes_inputs
- Opções que afetam as saídas de assinatura de um build:
--apk_signing_method=<v1, v2, v1_v2 or v4>padrão: "v1_v2"-
Implementação a ser usada para assinar APKs
Tags:
action_command_lines,affects_outputs,loading_and_analysis --[no]device_debug_entitlementspadrão: "true"-
Se definido e o modo de compilação não for "opt", os apps objc vão incluir direitos de depuração ao assinar.
Tags:
changes_inputs --ios_signing_cert_name=<a string>padrão: consulte a descrição-
Nome do certificado a ser usado para assinatura do iOS. Se não for definido, vai voltar ao perfil de provisionamento. Pode ser a preferência de identidade do chaveiro do certificado ou (substring) do nome comum do certificado, conforme a página de manual do codesign (IDENTIDADES DE ASSINATURA).
Tags:
action_command_lines
- Essa opção afeta a semântica da linguagem Starlark ou a API de build acessível a arquivos BUILD, .bzl ou WORKSPACE.:
--[no]incompatible_disallow_sdk_frameworks_attributespadrão: "false"-
Se for "true", não permita os atributos sdk_frameworks e weak_sdk_frameworks em objc_library e objc_import.
--[no]incompatible_objc_alwayslink_by_defaultpadrão: "false"-
Se for verdadeiro, defina o valor padrão como verdadeiro para atributos alwayslink em objc_library e objc_import.
--[no]incompatible_python_disallow_native_rulespadrão: "false"-
Quando verdadeiro, um erro ocorre ao usar as regras py_* integradas. Em vez disso, as regras rule_python devem ser usadas. Consulte https://github.com/bazelbuild/bazel/issues/17773 para mais informações e instruções de migração.
- Opções que regem o comportamento do ambiente de teste ou do executor de testes:
--[no]allow_analysis_failurespadrão: "false"-
Se for "true", uma falha na análise de um destino de regra vai resultar na propagação de uma instância de "AnalysisFailureInfo" contendo a descrição do erro, em vez de resultar em uma falha de build.
Tags:
loading_and_analysis,experimental - Padrão de
--analysis_testing_deps_limit=<an integer>: "2000" -
Define o número máximo de dependências transitivas usando um atributo de regra com uma transição de configuração for_analysis_testing. Exceder esse limite vai resultar em um erro de regra.
Tags:
loading_and_analysis --[no]break_build_on_parallel_dex2oat_failurepadrão: "false"-
Se for "true", as falhas na ação dex2oat vão interromper o build em vez de executar dex2oat durante o tempo de execução do teste.
Tags:
loading_and_analysis,experimental --default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100>vários usos são acumulados-
Substitua a quantidade padrão de recursos para testes. O formato esperado é <resource>=<value>. Se um único número positivo for especificado como <value>, ele vai substituir os recursos padrão para todos os tamanhos de teste. Se quatro números separados por vírgulas forem especificados, eles vão substituir a quantidade de recursos para os tamanhos de teste pequeno, médio, grande e enorme, respectivamente. Os valores também podem ser HOST_RAM/HOST_CPU, seguidos opcionalmente por [-|]<float> (por exemplo, memory=HOST_RAM.1,HOST_RAM*.2,HOST_RAM*.3,HOST_RAM*.4). Os recursos de teste padrão especificados por essa flag são substituídos por recursos explícitos especificados em tags.
--[no]experimental_android_use_parallel_dex2oatpadrão: "false"-
Use dex2oat em paralelo para acelerar o android_test.
Tags:
loading_and_analysis,host_machine_resource_optimizations,experimental --[no]ios_memleakspadrão: "false"-
Ativa a verificação de vazamentos de memória em destinos ios_test.
Tags:
action_command_lines --ios_simulator_device=<a string>padrão: consulte a descrição-
O dispositivo a ser simulado ao executar um aplicativo iOS no simulador, por exemplo, "iPhone 6". Para conferir uma lista de dispositivos, execute "xcrun simctl list devicetypes" na máquina em que o simulador será executado.
Tags:
test_runner --ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
A versão do iOS a ser executada no simulador durante a execução ou o teste. Isso é ignorado para regras ios_test se um dispositivo de destino for especificado na regra.
Tags:
test_runner --runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once>vários usos são acumulados-
Especifica o número de vezes que cada teste será executado. Se alguma dessas tentativas falhar por qualquer motivo, todo o teste será considerado falho. Normalmente, o valor especificado é apenas um número inteiro. Exemplo: --runs_per_test=3 vai executar todos os testes três vezes. Sintaxe alternativa: regex_filter@runs_per_test. Em que runs_per_test representa um valor inteiro e regex_filter representa uma lista de padrões de expressões regulares de inclusão e exclusão (consulte também --instrumentation_filter). Exemplo: --runs_per_test=//foo/.,-//foo/bar/.@3 executa todos os testes em //foo/, exceto aqueles em foo/bar, três vezes. Essa opção pode ser transmitida várias vezes. O argumento transmitido mais recentemente que corresponde tem precedência. Se nada corresponder, o teste será executado apenas uma vez.
--test_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable>vários usos são acumulados-
Especifica outras variáveis de ambiente a serem injetadas no ambiente do executor de testes. As variáveis podem ser especificadas por <code>name</code>, nesse caso, o valor será lido do ambiente do cliente Bazel, ou pelo par <code>name=value</code>. As variáveis definidas anteriormente podem ser desdefinidas usando <code>=name</code>. Essa opção pode ser usada várias vezes para especificar várias variáveis. Usado apenas pelo comando "bazel test".
Tags:
test_runner --test_timeout=<a single integer or comma-separated list of 4 integers>padrão: "-1"-
Substitui os valores padrão de tempo limite de teste para tempos limite de teste (em segundos). Se um único valor inteiro positivo for especificado, ele vai substituir todas as categorias. Se quatro números inteiros separados por vírgulas forem especificados, eles vão substituir os tempos limite para curto, moderado, longo e eterno (nessa ordem). Em qualquer uma das formas, um valor de -1 informa ao Blaze para usar os tempos limite padrão para essa categoria.
--[no]zip_undeclared_test_outputspadrão: "false"-
Se for "true", as saídas de teste não declaradas serão arquivadas em um arquivo ZIP.
Tags:
test_runner
- Opções que acionam otimizações do tempo de build:
--[no]experimental_filter_library_jar_with_program_jarpadrão: "false"-
Filtre o ProGuard ProgramJar para remover todas as classes também presentes no LibraryJar.
Tags:
action_command_lines,experimental --[no]experimental_inmemory_dotd_filespadrão: "true"-
Se ativada, os arquivos .d do C++ serão transmitidos na memória diretamente dos nós de build remoto em vez de serem gravados em disco.
Tags:
loading_and_analysis,execution,affects_outputs,experimental --[no]experimental_inmemory_jdeps_filespadrão: "true"-
Se ativada, os arquivos de dependência (.jdeps) gerados de compilações Java serão transmitidos na memória diretamente dos nós de build remoto em vez de serem gravados no disco.
Tags:
loading_and_analysis,execution,affects_outputs,experimental --[no]experimental_retain_test_configuration_across_testonlypadrão: "false"-
Quando ativada, a flag --trim_test_configuration não vai remover a configuração de teste para regras marcadas como testonly=1. Isso reduz problemas de conflito de ações quando regras que não são de teste dependem de regras cc_test. Não tem efeito se "--trim_test_configuration" for "false".
Tags:
loading_and_analysis,loses_incremental_state,experimental --[no]experimental_unsupported_and_brittle_include_scanningpadrão: "false"-
Indica se é necessário restringir as entradas à compilação em C/C++ analisando as linhas #include dos arquivos de entrada. Isso pode melhorar a performance e a incrementalidade, diminuindo o tamanho das árvores de entrada de compilação. No entanto, ele também pode interromper builds porque o scanner de inclusão não implementa totalmente a semântica do pré-processador C. Em particular, ele não entende diretivas #include dinâmicas e ignora a lógica condicional do pré-processador. Use por sua conta e risco. Todos os problemas relacionados a essa denúncia que forem enviados serão encerrados.
Tags:
loading_and_analysis,execution,changes_inputs,experimental --[no]incremental_dexingpadrão: "true"-
Faz a maior parte do trabalho de dexing separadamente para cada arquivo Jar.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state --[no]objc_use_dotd_pruningpadrão: "true"-
Se definido, os arquivos .d emitidos pelo clang serão usados para remover o conjunto de entradas transmitidas para compilações objc.
--[no]process_headers_in_dependenciespadrão: "false"-
Ao criar um destino //a:a, processe os cabeçalhos em todos os destinos de que //a:a depende (se o processamento de cabeçalho estiver ativado para a cadeia de ferramentas).
Tags:
execution --[no]trim_test_configurationpadrão: "true"-
Quando ativada, as opções relacionadas a testes serão limpas abaixo do nível superior do build. Quando essa flag está ativa, os testes não podem ser criados como dependências de regras que não são de teste, mas as mudanças nas opções relacionadas a testes não fazem com que as regras que não são de teste sejam analisadas novamente.
- Opções que afetam a verbosidade, o formato ou o local do registro em log:
- Padrão de
--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>: "-.*" -
Imprime informações de depuração durante a resolução da cadeia de ferramentas. A flag usa uma regex, que é verificada em relação a tipos de cadeia de ferramentas e destinos específicos para ver qual depurar. É possível separar várias expressões regulares com vírgulas, e cada uma delas é verificada separadamente. Observação: a saída dessa flag é muito complexa e provavelmente só será útil para especialistas em resolução de toolchain.
Tags:
terminal_output --[no]verbose_visibility_errorspadrão: "false"-
Se ativados, os erros de visibilidade incluem mais informações de diagnóstico.
- Opções que especificam ou alteram uma entrada genérica para um comando do Bazel que não se enquadra em outras categorias:
--flag_alias=<a 'name=value' flag alias>vários usos são acumulados-
Define um nome abreviado para uma flag do Starlark. Ele usa um único par de chave-valor no formato "<chave>=<valor>" como argumento.
Tags:
changes_inputs,non_configurable --[no]incompatible_default_to_explicit_init_pypadrão: "false"-
Essa flag muda o comportamento padrão para que os arquivos init.py não sejam mais criados automaticamente nos arquivos de execução de destinos Python. Precisamente, quando um destino py_binary ou py_test tem legacy_create_init definido como "auto" (o padrão), ele é tratado como falso se e somente se essa flag estiver definida. Consulte https://github.com/bazelbuild/bazel/issues/10076.
- Opções diversas, não categorizadas de outra forma:
--[no]cache_test_results[-t] padrão: "auto"-
Se definido como "auto", o Bazel vai executar novamente um teste somente se: (1) o Bazel detectar mudanças no teste ou nas dependências dele, (2) o teste for marcado como externo, (3) várias execuções de teste forem solicitadas com --runs_per_test ou(4) o teste falhou anteriormente. Se definido como "yes", o Bazel armazena em cache todos os resultados de testes, exceto aqueles marcados como externos. Se definido como "no", o Bazel não armazena em cache nenhum resultado de teste.
- Padrão de
--[no]experimental_cancel_concurrent_tests: "never" -
Se for "on_failed" ou "on_passed", o Blaze vai cancelar os testes em execução simultânea na primeira execução com esse resultado. Isso só é útil em combinação com --runs_per_test_detects_flakes.
--[no]experimental_fetch_all_coverage_outputspadrão: "false"-
Se for verdadeiro, o Bazel vai buscar todo o diretório de dados de cobertura para cada teste durante uma execução de cobertura.
--[no]experimental_generate_llvm_lcovpadrão: "false"-
Se for verdadeiro, a cobertura do clang vai gerar um relatório LCOV.
- Padrão de
--experimental_java_classpath=<off, javabuilder, bazel or bazel_no_fallback>: "bazel" -
Ativa caminhos de classe reduzidos para compilações Java.
--[no]experimental_run_android_lint_on_java_rulespadrão: "false"-
Se as fontes java_* precisam ser validadas.
Tags:
affects_outputs,experimental --[no]explicit_java_test_depspadrão: "false"-
Especifique explicitamente uma dependência do JUnit ou do Hamcrest em um java_test em vez de obter acidentalmente das dependências do TestRunner. No momento, só funciona para bazel.
--host_java_launcher=<a build target label>padrão: consulte a descrição-
O iniciador Java usado por ferramentas executadas durante um build.
--host_javacopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas para o javac ao criar ferramentas executadas durante um build.
--host_jvmopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas para a VM Java ao criar ferramentas executadas durante o build. Essas opções serão adicionadas às opções de inicialização da VM de cada destino java_binary.
--[no]incompatible_check_sharding_supportpadrão: "true"-
Se for verdadeiro, o Bazel vai falhar em um teste fragmentado se o executor de testes não indicar que oferece suporte à fragmentação ao tocar no arquivo no caminho em TEST_SHARD_STATUS_FILE. Se for "false", um executor de testes que não oferece suporte a fragmentação vai fazer com que todos os testes sejam executados em cada fragmento.
Tags:
incompatible_change --[no]incompatible_exclusive_test_sandboxedpadrão: "true"-
Se for verdadeiro, os testes exclusivos serão executados com a estratégia em sandbox. Adicione a tag "local" para forçar uma execução de teste exclusiva localmente
Tags:
incompatible_change --[no]incompatible_strict_action_envpadrão: "false"-
Se for "true", o Bazel usará um ambiente com um valor estático para PATH e não vai herdar LD_LIBRARY_PATH. Use --action_env=ENV_VARIABLE se quiser herdar variáveis de ambiente específicas do cliente, mas observe que isso pode impedir o armazenamento em cache entre usuários se um cache compartilhado for usado.
--j2objc_translation_flags=<comma-separated list of options>vários usos são acumulados-
Outras opções a serem transmitidas para a ferramenta J2ObjC.
--java_debug-
Faz com que a máquina virtual Java de um teste Java aguarde uma conexão de um depurador compatível com JDWP (como jdb) antes de iniciar o teste. Implica -test_output=streamed.
Expande para:
--test_arg=--wrapper_script_flag=--debug
--test_output=streamed
--test_strategy=exclusive
--test_timeout=9999
--nocache_test_results --[no]java_depspadrão: "true"-
Gere informações de dependência (por enquanto, classpath de tempo de compilação) por destino Java.
--[no]java_header_compilationpadrão: "true"-
Compile ijars diretamente da origem.
--java_language_version=<a string>padrão: ""-
A versão da linguagem Java
--java_launcher=<a build target label>padrão: consulte a descrição-
O inicializador Java a ser usado ao criar binários Java. Se essa flag for definida como uma string vazia, o iniciador do JDK será usado. O atributo "launcher" substitui essa flag.
- Padrão de
--java_runtime_version=<a string>: "local_jdk" -
A versão do ambiente de execução do Java
--javacopt=<a string>vários usos são acumulados-
Outras opções para transmitir ao javac.
--jvmopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas para a VM Java. Essas opções serão adicionadas às opções de inicialização da VM de cada destino java_binary.
--legacy_main_dex_list_generator=<a build target label>padrão: consulte a descrição-
Especifica um binário a ser usado para gerar a lista de classes que precisam estar no dex principal ao compilar o multidex legado.
--optimizing_dexer=<a build target label>padrão: consulte a descrição-
Especifica um binário a ser usado para fazer dexing sem sharding.
--plugin=<a build target label>vários usos são acumulados-
Plug-ins a serem usados no build. No momento, funciona com java_plugin.
--proguard_top=<a build target label>padrão: consulte a descrição-
Especifica qual versão do ProGuard usar para remoção de código ao criar um binário Java.
--proto_compiler=<a build target label>default: "@bazel_tools//tools/proto:protoc"-
O rótulo do proto-compilador.
--[no]proto_profilepadrão: "true"-
Se o profile_path será transmitido ao compilador proto.
--proto_profile_path=<a build target label>padrão: consulte a descrição-
O perfil a ser transmitido ao compilador proto como profile_path. Se não for definido, mas --proto_profile for verdadeiro (o padrão), vai inferir o caminho de --fdo_optimize.
--proto_toolchain_for_cc=<a build target label>default: "@bazel_tools//tools/proto:cc_toolchain"-
Rótulo de proto_lang_toolchain() que descreve como compilar protos C++
--proto_toolchain_for_j2objc=<a build target label>padrão: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain"-
Rótulo de proto_lang_toolchain() que descreve como compilar protos j2objc.
--proto_toolchain_for_java=<a build target label>default: "@bazel_tools//tools/proto:java_toolchain"-
Rótulo de proto_lang_toolchain() que descreve como compilar protos Java.
--proto_toolchain_for_javalite=<a build target label>default: "@bazel_tools//tools/proto:javalite_toolchain"-
Rótulo de proto_lang_toolchain() que descreve como compilar protos do JavaLite.
--protocopt=<a string>vários usos são acumulados-
Outras opções para transmitir ao compilador protobuf.
Tags:
affects_outputs --[no]runs_per_test_detects_flakespadrão: "false"-
Se for "true", qualquer fragmento em que pelo menos uma execução/tentativa seja aprovada e pelo menos uma execução/tentativa falhe vai receber o status "FLAKY".
--shell_executable=<a path>padrão: consulte a descrição-
Caminho absoluto para o executável do shell que o Bazel vai usar. Se não estiver definido, mas a variável de ambiente BAZEL_SH estiver definida na primeira invocação do Bazel (que inicia um servidor do Bazel), o Bazel vai usar essa variável. Se nenhum dos dois estiver definido, o Bazel usará um caminho padrão codificado, dependendo do sistema operacional em que ele é executado (Windows: c:/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, todos os outros: /bin/bash). Usar um shell incompatível com bash pode causar falhas de build ou de tempo de execução dos binários gerados.
Tags:
loading_and_analysis --test_arg=<a string>vários usos são acumulados-
Especifica outras opções e argumentos que devem ser transmitidos para o executável de teste. Pode ser usado várias vezes para especificar vários argumentos. Se vários testes forem executados, cada um deles vai receber argumentos idênticos. Usado apenas pelo comando "bazel test".
--test_filter=<a string>padrão: consulte a descrição-
Especifica um filtro para encaminhar ao framework de teste. Usado para limitar os testes executados. Isso não afeta quais destinos são criados.
--test_result_expiration=<an integer>padrão: "-1"-
Essa opção foi descontinuada e não tem efeito.
--[no]test_runner_fail_fastpadrão: "false"-
Encaminha a opção de falha rápida para o executor de testes. O executor de testes precisa interromper a execução na primeira falha.
--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce>padrão: "explicit"-
Especifique a estratégia para o sharding de teste: "explicit" para usar o sharding somente se o atributo "shard_count" BUILD estiver presente. "disabled" para nunca usar o sharding de teste. "forced=k" para forçar "k" fragmentos para teste, independente do atributo "shard_count" BUILD.
--tool_java_language_version=<a string>padrão: ""-
A versão da linguagem Java usada para executar as ferramentas necessárias durante um build.
--tool_java_runtime_version=<a string>padrão: "remotejdk_11"-
A versão do ambiente de execução Java usada para executar ferramentas durante o build.
--[no]use_ijarspadrão: "true"-
Se ativada, essa opção faz com que a compilação Java use jars de interface. Isso resulta em uma compilação incremental mais rápida, mas as mensagens de erro podem ser diferentes.
Opções de canonicalize-flags
Herda todas as opções de build.
- Opções que controlam a saída do comando:
--[no]canonicalize_policypadrão: "false"-
Gere a política canônica após a expansão e a filtragem. Para manter a saída limpa, os argumentos de comando canonizados NÃO serão mostrados quando essa opção for definida como "true". O comando especificado por --for_command afeta a política filtrada. Se nenhum for especificado, o comando padrão será "build".
Tags:
affects_outputs,terminal_output --[no]experimental_include_default_valuespadrão: "true"-
Se as opções do Starlark definidas com os valores padrão estão incluídas na saída.
Tags:
affects_outputs,terminal_output
- Essa opção afeta a semântica da linguagem Starlark ou a API de build acessível a arquivos BUILD, .bzl ou WORKSPACE.:
--[no]incompatible_config_setting_private_default_visibilitypadrão: "false"-
Se "incompatible_enforce_config_setting_visibility=false", isso não terá efeito. Caso contrário, se essa flag for "false", qualquer config_setting sem um atributo de visibilidade explícito será //visibility:public. Se essa flag for "true", "config_setting" vai seguir a mesma lógica de visibilidade de todas as outras regras. Consulte https://github.com/bazelbuild/bazel/issues/12933.
--[no]incompatible_enforce_config_setting_visibilitypadrão: "true"-
Se for "true", aplique as restrições de visibilidade de "config_setting". Se for "false", todas as config_setting serão visíveis para todos os destinos. Consulte https://github.com/bazelbuild/bazel/issues/12932.
- Opções que especificam ou alteram uma entrada genérica para um comando do Bazel que não se enquadra em outras categorias:
--for_command=<a string>padrão: "build"-
O comando para o qual as opções precisam ser canonizadas.
Tags:
affects_outputs,terminal_output --invocation_policy=<a string>padrão: ""-
Aplica uma política de invocação às opções a serem canonizadas.
Tags:
affects_outputs,terminal_output
- Opções diversas, não categorizadas de outra forma:
--deleted_packages=<comma-separated list of package names>vários usos são acumulados-
Uma lista separada por vírgulas de nomes de pacotes que o sistema de build vai considerar inexistentes, mesmo que estejam visíveis em algum lugar no caminho do pacote. Use essa opção ao excluir um subpacote "x/y" de um pacote "x" existente. Por exemplo, depois de excluir x/y/BUILD no cliente, o sistema de build poderá reclamar se encontrar um rótulo "//x:y/z" se ele ainda for fornecido por outra entrada package_path. Especificar --deleted_packages x/y evita esse problema.
--[no]fetchpadrão: "true"-
Permite que o comando busque dependências externas. Se definido como "false", o comando vai usar qualquer versão em cache da dependência. Se não houver nenhuma, o comando vai falhar.
--package_path=<colon-separated list of options>padrão: "%workspace%"-
Uma lista separada por dois-pontos de onde procurar pacotes. Os elementos que começam com "%workspace%" são relativos ao espaço de trabalho envolvido. Se for omitido ou estiver vazio, o padrão será a saída de "bazel info default-package-path".
--[no]show_loading_progresspadrão: "true"-
Se ativada, faz com que o Bazel imprima mensagens "Carregando pacote:".
Opções de limpeza
Herda todas as opções de build.
- Opções que controlam a saída do comando:
--[no]asyncpadrão: "false"-
Se for verdadeiro, a limpeza da saída será assíncrona. Quando esse comando for concluído, será seguro executar novos comandos no mesmo cliente, mesmo que a exclusão continue em segundo plano.
--[no]expungepadrão: "false"-
Se for "true", "clean" vai remover toda a árvore de trabalho dessa instância do Bazel, incluindo todos os arquivos temporários e de saída de build criados pelo Bazel, e vai interromper o servidor do Bazel se ele estiver em execução.
--expunge_async-
Se especificado, o comando "clean" remove de forma assíncrona toda a árvore de trabalho dessa instância do Bazel, incluindo todos os arquivos temporários e de saída de build criados pelo Bazel, e interrompe o servidor do Bazel se ele estiver em execução. Quando esse comando for concluído, será seguro executar novos comandos no mesmo cliente, mesmo que a exclusão continue em segundo plano.
Opções de configuração
Opções de cobertura
Herda todas as opções de test.
Opções de Cquery
Herda todas as opções de test.
- Opções relacionadas à saída e à semântica da consulta:
--aspect_deps=<off, conservative or precise>padrão: "conservative"-
Como resolver dependências de aspectos quando o formato de saída é um dos seguintes: {xml,proto,record}. "off" significa que nenhuma dependência de aspecto é resolvida. "conservative" (o padrão) significa que todas as dependências de aspecto declaradas são adicionadas, independente de terem recebido a classe de regra de dependências diretas. "precise" significa que apenas os aspectos possivelmente ativos são adicionados, considerando a classe de regra das dependências diretas. O modo preciso exige o carregamento de outros pacotes para avaliar uma única meta, o que o torna mais lento do que os outros modos. Além disso, mesmo o modo preciso não é completamente preciso: a decisão de calcular um aspecto é tomada na fase de análise, que não é executada durante "bazel query".
Tags:
build_file_semantics --[no]consistent_labelspadrão: "false"-
Se ativado, todo comando de consulta vai emitir rótulos como se a função <code>str</code> do Starlark fosse aplicada a uma instância <code>Label</code>. Isso é útil para ferramentas que precisam corresponder à saída de diferentes comandos de consulta e/ou rótulos emitidos por regras. Se não estiver ativado, os formatadores de saída poderão emitir nomes de repositórios aparentes (em relação ao repositório principal) para tornar a saída mais legível.
Tags:
terminal_output --[no]experimental_explicit_aspectspadrão: "false"-
aquery, cquery: se as ações geradas por aspectos devem ser incluídas na saída. query: no-op (os aspectos são sempre seguidos).
Tags:
terminal_output --[no]graph:factoredpadrão: "true"-
Se for "verdadeiro", o gráfico será emitido "fatorado", ou seja, nós topologicamente equivalentes serão mesclados e os rótulos concatenados. Essa opção só é aplicável a --output=graph.
Tags:
terminal_output --graph:node_limit=<an integer>padrão: "512"-
O comprimento máximo da string de rótulo para um nó de gráfico na saída. Rótulos mais longos serão truncados. -1 significa que não haverá truncamento. Essa opção só é aplicável a --output=graph.
Tags:
terminal_output --[no]implicit_depspadrão: "true"-
Se ativadas, as dependências implícitas serão incluídas no gráfico de dependências em que a consulta opera. Uma dependência implícita é aquela que não é especificada explicitamente no arquivo BUILD, mas é adicionada pelo Bazel. Para cquery, essa opção controla a filtragem de toolchains resolvidas.
Tags:
build_file_semantics --[no]include_aspectspadrão: "true"-
aquery, cquery: se as ações geradas por aspectos devem ser incluídas na saída. query: no-op (os aspectos são sempre seguidos).
Tags:
terminal_output --[no]incompatible_package_group_includes_double_slashpadrão: "true"-
Se ativado, ao gerar o atributo
packagesde package_group, o//inicial não será omitido. --[no]infer_universe_scopepadrão: "false"-
Se definido e --universe_scope não estiver definido, um valor de --universe_scope será inferido como a lista de padrões de destino exclusivos na expressão de consulta. O valor --universe_scope inferido para uma expressão de consulta que usa funções com escopo de universo (por exemplo,
allrdeps) pode não ser o que você quer. Portanto, use essa opção apenas se souber o que está fazendo. Acesse https://bazel.build/reference/query#sky-query para ver detalhes e exemplos. Se --universe_scope estiver definido, o valor dessa opção será ignorado. Observação: essa opção se aplica apenas aquery(ou seja, nãocquery).Tags:
loading_and_analysis --[no]line_terminator_nullpadrão: "false"-
Se cada formato é encerrado com \0 em vez de uma nova linha.
Tags:
terminal_output --[no]nodep_depspadrão: "true"-
Se ativada, as dependências dos atributos "nodep" serão incluídas no gráfico de dependências em que a consulta opera. Um exemplo comum de atributo "nodep" é "visibility". Execute e analise a saída de
info build-languagepara saber mais sobre todos os atributos "nodep" na linguagem de build.Tags:
build_file_semantics - Padrão de
--output=<a string>: "label" -
O formato em que os resultados da cquery precisam ser impressos. Os valores permitidos para cquery são: label, label_kind, textproto, transitions, proto, streamed_proto, jsonproto. Se você selecionar "transições", também precisará especificar a opção --transitions=(lite|full).
Tags:
terminal_output --output_file=<a string>padrão: ""-
Quando especificado, os resultados da consulta são gravados diretamente nesse arquivo, e nada é impresso no stream de saída padrão (stdout) do Bazel. Em comparativos, isso geralmente é mais rápido do que <code>bazel query > file</code>.
Tags:
terminal_output --[no]proto:default_valuespadrão: "true"-
Se for "true", os atributos cujo valor não for especificado explicitamente no arquivo BUILD serão incluídos. Caso contrário, eles serão omitidos. Essa opção é válida para --output=proto
Tags:
terminal_output --[no]proto:definition_stackpadrão: "false"-
Preencha o campo proto "definition_stack", que registra para cada instância de regra a pilha de chamadas do Starlark no momento em que a classe da regra foi definida.
Tags:
terminal_output --[no]proto:flatten_selectspadrão: "true"-
Se ativado, os atributos configuráveis criados por select() serão simplificados. Para tipos de lista, a representação simplificada é uma lista que contém cada valor do mapa de seleção exatamente uma vez. Os tipos escalares são nivelados como nulos.
Tags:
build_file_semantics --[no]proto:include_attribute_source_aspectspadrão: "false"-
Preencha o campo proto source_aspect_name de cada atributo com o aspecto de origem de onde ele veio (string vazia se não veio de nenhum).
Tags:
terminal_output --[no]proto:include_configurationspadrão: "true"-
Se ativado, a saída do proto vai incluir informações sobre as configurações. Quando desativado,o formato de saída do cquery proto é semelhante ao formato de saída da consulta.
Tags:
affects_outputs --[no]proto:include_starlark_rule_envpadrão: "true"-
Use o ambiente starlark no valor do atributo $internal_attr_hash gerado. Isso garante que a definição da regra do Starlark (e as importações transitivas dela) façam parte desse identificador.
Tags:
terminal_output --[no]proto:include_synthetic_attribute_hashpadrão: "false"-
Se o atributo $internal_attr_hash deve ser calculado e preenchido.
Tags:
terminal_output --[no]proto:instantiation_stackpadrão: "false"-
Preencha a pilha de chamadas de instanciação de cada regra. Isso exige que a pilha esteja presente
Tags:
terminal_output --[no]proto:locationspadrão: "true"-
Determina se as informações de local devem ser geradas na saída proto.
Tags:
terminal_output - Padrão de
--proto:output_rule_attrs=<comma-separated list of options>: "all" -
Lista separada por vírgulas de atributos a serem incluídos na saída. O padrão é todos os atributos. Defina como uma string vazia para não gerar nenhum atributo. Essa opção é válida para --output=proto.
Tags:
terminal_output --[no]proto:rule_classespadrão: "false"-
Preencha o campo "rule_class_key" de cada regra e, para a primeira regra com um determinado "rule_class_key", preencha também o campo proto "rule_class_info". O campo "rule_class_key" identifica exclusivamente uma classe de regra, e o campo "rule_class_info" é uma definição de API de classe de regra no formato Stardoc.
Tags:
terminal_output --[no]proto:rule_inputs_and_outputspadrão: "true"-
Se os campos "rule_input" e "rule_output" devem ser preenchidos.
Tags:
terminal_output --query_file=<a string>padrão: ""-
Se definido, a consulta vai ler o arquivo nomeado aqui, em vez da linha de comando. É um erro especificar um arquivo aqui e uma consulta de linha de comando.
Tags:
changes_inputs --[no]relative_locationspadrão: "false"-
Se for "true", o local dos arquivos BUILD nas saídas XML e proto será relativo. Por padrão, a saída de local é um caminho absoluto e não é consistente em todas as máquinas. Defina essa opção como "true" para ter um resultado consistente em todas as máquinas.
Tags:
terminal_output --show_config_fragments=<off, direct or transitive>padrão: "off"-
Mostra os fragmentos de configuração exigidos por uma regra e suas dependências transitivas. Isso pode ser útil para avaliar o quanto um gráfico de destino configurado pode ser reduzido.
Tags:
affects_outputs --starlark:expr=<a string>padrão: ""-
Uma expressão Starlark para formatar cada destino configurado no modo --output=starlark do cquery. O destino configurado está vinculado a "target". Se nem --starlark:expr nem --starlark:file forem especificados, essa opção vai usar "str(target.label)" por padrão. É um erro especificar --starlark:expr e --starlark:file.
Tags:
terminal_output --starlark:file=<a string>padrão: ""-
O nome de um arquivo que define uma função Starlark chamada "format", de um argumento, que é aplicada a cada destino configurado para formatá-lo como uma string. É um erro especificar --starlark:expr e --starlark:file. Consulte a ajuda para --output=starlark para mais detalhes.
Tags:
terminal_output --[no]tool_depspadrão: "true"-
Consulta: se desativado, as dependências da "configuração de execução" não serão incluídas no gráfico de dependências em que a consulta opera. Uma aresta de dependência de "configuração de execução", como a de qualquer regra "proto_library" para o compilador de protocolo, geralmente aponta para uma ferramenta executada durante a build, em vez de uma parte do mesmo programa "target". Cquery: se desativado, filtra todos os destinos configurados que cruzam uma transição de execução do destino de nível superior que descobriu esse destino configurado. Isso significa que, se o destino de nível superior estiver na configuração de destino, somente os destinos configurados que também estiverem na configuração de destino serão retornados. Se o destino de nível superior estiver na configuração de execução, somente os destinos configurados para execução serão retornados. Essa opção NÃO exclui toolchains resolvidas.
Tags:
build_file_semantics --transitions=<full, lite or none>padrão: "none"-
O formato em que o cquery vai imprimir informações de transição.
Tags:
affects_outputs --universe_scope=<comma-separated list of options>padrão: ""-
Um conjunto de padrões de destino separados por vírgulas (aditivos e subtrativos). A consulta pode ser realizada no universo definido pelo fechamento transitivo das metas especificadas. Essa opção é usada para os comandos "query" e "cquery". Para cquery, a entrada dessa opção são os destinos em que todas as respostas são criadas. Portanto, essa opção pode afetar configurações e transições. Se essa opção não for especificada, os destinos de nível superior serão considerados os destinos analisados da expressão de consulta. Observação: para cquery, não especificar essa opção pode fazer com que o build seja interrompido se os destinos analisados da expressão de consulta não puderem ser criados com opções de nível superior.
Tags:
loading_and_analysis
- Opções que controlam a execução do build:
--[no]experimental_persistent_aar_extractorpadrão: "false"-
Ative o extrator aar permanente usando workers.
Tags:
execution,experimental --[no]experimental_remotable_source_manifestspadrão: "false"-
Se as ações do manifesto de origem podem ser executadas remotamente
--[no]experimental_split_coverage_postprocessingpadrão: "false"-
Se for verdadeiro, o Bazel vai executar o pós-processamento de cobertura para o teste em uma nova geração.
Tags:
execution,experimental --[no]experimental_strict_fileset_outputpadrão: "false"-
Se essa opção estiver ativada, os conjuntos de arquivos vão tratar todos os artefatos de saída como arquivos regulares. Eles não vão percorrer diretórios nem serão sensíveis a symlinks.
Tags:
execution,experimental --[no]incompatible_modify_execution_info_additivepadrão: "true"-
Quando ativada, a transmissão de várias flags --modify_execution_info é cumulativa. Quando desativada, apenas a última flag é considerada.
Tags:
execution,affects_outputs,loading_and_analysis,incompatible_change --modify_execution_info=<regex=[+-]key,regex=[+-]key,...>vários usos são acumulados-
Adicione ou remova chaves das informações de execução de uma ação com base no mnemônico dela. Aplicável apenas a ações que oferecem suporte a informações de execução. Muitas ações comuns oferecem suporte a informações de execução, por exemplo, Genrule, CppCompile, Javac, StarlarkAction e TestRunner. Ao especificar vários valores, a ordem é importante porque muitas expressões regulares podem ser aplicadas ao mesmo mnemônico.
Sintaxe: "regex=[+-]key,regex=[+-]key,...".
Exemplos: '.=+x,.=-y,.=+z' adiciona "x" e "z" e remove "y" das informações de execução de todas as ações. "Genrule=+requires-x" adiciona "requires-x" às informações de execução de todas as ações Genrule. '(?!Genrule).=-requires-x' remove 'requires-x' das informações de execução de todas as ações que não são Genrule.
--persistent_android_dex_desugar-
Ative ações persistentes de dex e dessugar do Android usando workers.
Expande para:
--internal_persistent_android_dex_desugar
--strategy=Desugar=worker
--strategy=DexBuilder=worker --persistent_android_resource_processor-
Ative o processador de recursos persistentes do Android usando workers.
Expande para:
--internal_persistent_busybox_tools
--strategy=AaptPackage=worker
--strategy=AndroidResourceParser=worker
--strategy=AndroidResourceValidator=worker
--strategy=AndroidResourceCompiler=worker
--strategy=RClassGenerator=worker
--strategy=AndroidResourceLink=worker
--strategy=AndroidAapt2=worker
--strategy=AndroidAssetMerger=worker
--strategy=AndroidResourceMerger=worker
--strategy=AndroidCompiledResourceMerger=worker
--strategy=ManifestMerger=worker
--strategy=AndroidManifestMerger=worker
--strategy=Aapt2Optimize=worker
--strategy=AARGenerator=worker
--strategy=ProcessDatabinding=worker
--strategy=GenerateDataBindingBaseClasses=worker --persistent_multiplex_android_dex_desugar-
Ative ações persistentes e multiplexadas de dex e dessugar do Android usando workers.
Expande para:
--persistent_android_dex_desugar
--internal_persistent_multiplex_android_dex_desugar --persistent_multiplex_android_resource_processor-
Ative o processador de recursos do Android multiplexado persistente usando workers.
Expande para:
--persistent_android_resource_processor
--modify_execution_info=AaptPackage=+supports-multiplex-workers
--modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
--modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
--modify_execution_info=RClassGenerator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
--modify_execution_info=AndroidAapt2=+supports-multiplex-workers
--modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
--modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
--modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
--modify_execution_info=ManifestMerger=+supports-multiplex-workers
--modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
--modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
--modify_execution_info=AARGenerator=+supports-multiplex-workers --persistent_multiplex_android_tools-
Ativar ferramentas Android persistentes e multiplexadas (dexing, desugaring, processamento de recursos).
Expande para:
--internal_persistent_multiplex_busybox_tools
--persistent_multiplex_android_resource_processor
--persistent_multiplex_android_dex_desugar --[no]use_target_platform_for_testspadrão: "false"-
Se for "true", use a plataforma de destino para executar testes em vez do grupo de execução de teste.
Tags:
execution
- Opções que configuram o conjunto de ferramentas usado para a execução de ações:
--android_compiler=<a string>padrão: consulte a descrição-
O compilador de destino do Android.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state --android_manifest_merger=<legacy, android or force_android>padrão: "android"-
Seleciona o combinador de manifestos a ser usado para regras android_binary. Flag para ajudar na transição do combinador legado para o combinador do manifesto do Android.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state --android_platforms=<a build target label>padrão: ""-
Define as plataformas usadas pelas segmentações android_binary. Se várias plataformas forem especificadas, o binário será um APK fat, que contém binários nativos para cada plataforma de destino especificada.
Tags:
changes_inputs,loading_and_analysis,loses_incremental_state --cc_output_directory_tag=<a string>padrão: ""-
Especifica um sufixo a ser adicionado ao diretório de configuração.
Tags:
affects_outputs --compiler=<a string>padrão: consulte a descrição-
O compilador C++ a ser usado para compilar o destino.
Tags:
loading_and_analysis,execution --coverage_output_generator=<a build target label>default: "@bazel_tools//tools/test:lcov_merger"-
Local do binário usado para pós-processar relatórios de cobertura bruta. Precisa ser uma meta binária. O padrão é "//tools/test:lcov_merger".
--coverage_report_generator=<a build target label>default: "@bazel_tools//tools/test:coverage_report_generator"-
Local do binário usado para gerar relatórios de cobertura. Precisa ser uma meta binária. O padrão é "//tools/test:coverage_report_generator".
--coverage_support=<a build target label>default: "@bazel_tools//tools/test:coverage_support"-
Localização dos arquivos de suporte necessários nas entradas de todas as ações de teste que coletam cobertura de código. O padrão é "//tools/test:coverage_support".
--custom_malloc=<a build target label>padrão: consulte a descrição-
Especifica uma implementação de malloc personalizada. Essa configuração substitui os atributos malloc nas regras de build.
Tags:
changes_inputs,affects_outputs --[no]experimental_include_xcode_execution_requirementspadrão: "false"-
Se definido, adicione um requisito de execução "requires-xcode:{version}" a todas as ações do Xcode. Se a versão do Xcode tiver um rótulo hifenizado, adicione também um requisito de execução "requires-xcode-label:{version_label}".
Tags:
loses_incremental_state,loading_and_analysis,execution,experimental --[no]experimental_prefer_mutual_xcodepadrão: "true"-
Se for "true", use o Xcode mais recente disponível local e remotamente. Se for "false" ou se não houver versões disponíveis em comum, use a versão local do Xcode selecionada com xcode-select.
--extra_execution_platforms=<comma-separated list of options>padrão: ""-
As plataformas disponíveis como plataformas de execução para realizar ações. As plataformas podem ser especificadas por segmentação exata ou como um padrão de segmentação. Essas plataformas serão consideradas antes daquelas declaradas no arquivo WORKSPACE por register_execution_platforms(). Essa opção só pode ser definida uma vez. Instâncias posteriores vão substituir as configurações de flag anteriores.
Tags:
execution --extra_toolchains=<comma-separated list of options>vários usos são acumulados-
As regras da cadeia de ferramentas a serem consideradas durante a resolução da cadeia de ferramentas. As toolchains podem ser especificadas por destino exato ou como um padrão de destino. Esses conjuntos de ferramentas serão considerados antes daqueles declarados no arquivo WORKSPACE por register_toolchains().
--grte_top=<a label>padrão: consulte a descrição-
Um rótulo para uma biblioteca libc registrada. O valor padrão é selecionado pela cadeia de ferramentas crosstool, e quase nunca é necessário substituir esse valor.
--host_compiler=<a string>padrão: consulte a descrição-
Flag de nenhuma operação. Será removido em uma versão futura.
Tags:
loading_and_analysis,execution --host_grte_top=<a label>padrão: consulte a descrição-
Se especificada, essa configuração vai substituir o diretório de nível superior da libc (--grte_top) para a configuração de execução.
--host_platform=<a build target label>default: "@bazel_tools//tools:host_platform"-
O rótulo de uma regra de plataforma que descreve o sistema host.
--[no]incompatible_bazel_test_exec_run_underpadrão: "true"-
Se ativado, "bazel test --run_under=//:runner" vai criar "//:runner" na configuração de execução. Se estiver desativado, ele vai criar "//:runner" na configuração de destino. O Bazel executa testes em máquinas de execução, então o primeiro é mais correto. Isso não afeta "bazel run", que sempre cria "`--run_under=//foo" na configuração de destino.
--[no]incompatible_builtin_objc_strip_actionpadrão: "true"-
Se uma ação de remoção deve ser emitida como parte da vinculação objc.
--[no]incompatible_dont_enable_host_nonhost_crosstool_featurespadrão: "true"-
Se for "true", o Bazel não vai ativar os recursos "host" e "nonhost" na cadeia de ferramentas do C++ (consulte https://github.com/bazelbuild/bazel/issues/7407 para mais informações).
--[no]incompatible_enable_apple_toolchain_resolutionpadrão: "false"-
Use a resolução da cadeia de ferramentas para selecionar o SDK da Apple para regras da Apple (Starlark e nativas).
--[no]incompatible_remove_legacy_whole_archivepadrão: "true"-
Se for "true", o Bazel não vai vincular dependências de biblioteca como um arquivo inteiro por padrão. Consulte https://github.com/bazelbuild/bazel/issues/7362 para instruções de migração.
--[no]incompatible_strip_executable_safelypadrão: "false"-
Se for verdadeiro, a ação de remoção para executáveis usará a flag -x, que não interrompe a resolução dinâmica de símbolos.
-
Use objetos compartilhados de interface se forem compatíveis com o conjunto de ferramentas. Todas as toolchains ELF são compatíveis com essa configuração.
Tags:
loading_and_analysis,affects_outputs,affects_outputs --ios_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Especifica a versão do SDK para iOS a ser usada para criar aplicativos iOS. Se não for especificado, usará a versão padrão do SDK para iOS de "xcode_version".
Tags:
loses_incremental_state --macos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Especifica a versão do SDK do macOS a ser usada para criar aplicativos desse sistema operacional. Se não for especificado, usará a versão padrão do SDK do macOS de "xcode_version".
Tags:
loses_incremental_state --minimum_os_version=<a string>padrão: consulte a descrição-
A versão mínima do SO que sua compilação segmenta.
--platform_mappings=<a main workspace-relative path>padrão: ""-
O local de um arquivo de mapeamento que descreve qual plataforma usar se nenhuma estiver definida ou quais flags definir quando uma plataforma já existir. Precisa ser relativo à raiz do espaço de trabalho principal. O padrão é "platform_mappings", um arquivo diretamente na raiz do espaço de trabalho.
Tags:
affects_outputs,changes_inputs,loading_and_analysis,non_configurable --platforms=<a build target label>padrão: ""-
Os rótulos das regras de plataforma que descrevem as plataformas de destino para o comando atual.
--python_path=<a string>padrão: consulte a descrição-
O caminho absoluto do interpretador Python invocado para executar destinos Python na plataforma de destino. Obsoleto. Desativado por --incompatible_use_python_toolchains.
--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Especifica a versão do SDK do tvOS a ser usada para criar aplicativos desse sistema operacional. Se não for especificado, usará a versão padrão do SDK do tvOS de "xcode_version".
Tags:
loses_incremental_state --[no]use_platforms_in_apple_crosstool_transitionpadrão: "false"-
Faz com que apple_crosstool_transition volte a usar o valor da flag
--platformsem vez do--cpulegado quando necessário.Tags:
loading_and_analysis --watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Especifica a versão do SDK do watchOS a ser usada para criar aplicativos do watchOS. Se não for especificado, usará a versão padrão do SDK do watchOS de "xcode_version".
Tags:
loses_incremental_state --xcode_version=<a string>padrão: consulte a descrição-
Se especificado, usa o Xcode da versão fornecida para ações de build relevantes. Se não for especificado, vai usar a versão padrão do executor do Xcode.
Tags:
loses_incremental_state --xcode_version_config=<a build target label>default: "@bazel_tools//tools/cpp:host_xcodes"-
O rótulo da regra xcode_config a ser usada para selecionar a versão do Xcode na configuração de build.
- Opções que controlam a saída do comando:
--[no]apple_generate_dsympadrão: "false"-
Se é necessário gerar arquivos de símbolos de depuração (.dSYM).
--[no]build_runfile_linkspadrão: "true"-
Se for verdadeiro, vai criar florestas de symlink de runfiles para todos os destinos. Se for "false", grave-os apenas quando exigido por uma ação, teste ou comando de execução local.
Tags:
affects_outputs --[no]build_runfile_manifestspadrão: "true"-
Se verdadeiro, grava manifestos de runfiles para todos os destinos. Se for "false", omita-os. Os testes locais não serão executados quando for "false".
Tags:
affects_outputs --[no]build_test_dwppadrão: "false"-
Se ativado, ao criar testes em C++ de forma estática e com fusão, o arquivo .dwp do binário de teste também será criado automaticamente.
--cc_proto_library_header_suffixes=<comma-separated set of options>padrão: ".pb.h"-
Define os sufixos dos arquivos de cabeçalho que uma cc_proto_library cria.
- Padrão de
--cc_proto_library_source_suffixes=<comma-separated set of options>: ".pb.cc" -
Define os sufixos dos arquivos de origem que uma cc_proto_library cria.
--[no]experimental_proto_descriptor_sets_include_source_infopadrão: "false"-
Executa ações extras para versões alternativas da API Java em uma proto_library.
--[no]experimental_save_feature_statepadrão: "false"-
Salve o estado dos recursos ativados e solicitados como uma saída da compilação.
Tags:
affects_outputs,experimental --fission=<a set of compilation modes>padrão: "no"-
Especifica quais modos de compilação usam a fissão para compilações e vinculações em C++. Pode ser qualquer combinação de {'fastbuild', 'dbg', 'opt'} ou os valores especiais 'yes' para ativar todos os modos e 'no' para desativar todos os modos.
Tags:
loading_and_analysis,action_command_lines,affects_outputs --[no]incompatible_always_include_files_in_datapadrão: "true"-
Se for verdadeiro, as regras nativas vão adicionar <code>DefaultInfo.files</code> de dependências de dados aos runfiles, o que corresponde ao comportamento recomendado para regras do Starlark (https://bazel.build/extending/rules#runfiles_features_to_avoid).
--[no]incompatible_compact_repo_mapping_manifestpadrão: "false"-
Se ativado, o arquivo <binary>.repo_mapping vai emitir o mapeamento de repositório de uma extensão de módulo apenas uma vez, em vez de uma vez para cada repositório gerado pela extensão que contribui com runfiles.
--incompatible_disable_select_on=<comma-separated set of options>padrão: ""-
Lista de flags para as quais o uso em select() está desativado.
Tags:
loading_and_analysis,incompatible_change,non_configurable --[no]incompatible_filegroup_runfiles_for_datapadrão: "true"-
Se for verdadeiro, os runfiles dos destinos listados no atributo "srcs" estarão disponíveis para os destinos que consomem o filegroup como uma dependência de dados.
Tags:
incompatible_change --[no]objc_generate_linkmappadrão: "false"-
Especifica se um arquivo linkmap será gerado.
Tags:
affects_outputs --[no]save_tempspadrão: "false"-
Se definido, as saídas temporárias do gcc serão salvas. Eles incluem arquivos .s (código de assembler), .i (C pré-processado) e .ii (C++ pré-processado).
Tags:
affects_outputs
- Opções que permitem ao usuário configurar a saída pretendida, afetando o valor dela, e não a existência:
--action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable>vários usos são acumulados-
Especifica o conjunto de variáveis de ambiente disponíveis para ações com configuração de destino. As variáveis podem ser especificadas por <code>name</code>, em que o valor é extraído do ambiente de invocação, pelo par <code>name=value</code>, que define o valor independente do ambiente de invocação, ou por <code>=name</code>, que desativa a variável com esse nome. Essa opção pode ser usada várias vezes. Para opções fornecidas para a mesma variável, a mais recente vence. Para variáveis diferentes, as opções são acumuladas. <br> A menos que <code>--incompatible_repo_env_ignores_action_env</code> seja verdadeiro, todos os pares <code>name=value</code> estarão disponíveis para as regras do repositório.
Tags:
action_command_lines --allowed_cpu_values=<comma-separated set of options>padrão: ""-
Valores permitidos para a flag "--cpu".
Tags:
changes_inputs,affects_outputs --[no]android_databinding_use_androidxpadrão: "true"-
Gere arquivos de vinculação de dados compatíveis com o AndroidX. Isso só é usado com a vinculação de dados v2. Essa flag não faz nada.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --[no]android_databinding_use_v3_4_argspadrão: "true"-
Use a vinculação de dados do Android v2 com o argumento 3.4.0. Essa flag não faz nada.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --android_dynamic_mode=<off, default or fully>padrão: "off"-
Determina se as dependências C++ das regras do Android serão vinculadas dinamicamente quando um cc_binary não criar explicitamente uma biblioteca compartilhada. "default" significa que o bazel vai escolher se a vinculação será dinâmica. "Totalmente" significa que todas as bibliotecas serão vinculadas dinamicamente. "off" significa que todas as bibliotecas serão vinculadas principalmente no modo estático.
- Padrão de
--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency>: "alphabetical" -
Define a ordem dos manifestos transmitidos à ferramenta de mescla de manifestos para binários do Android. ALPHABETICAL significa que os manifestos são classificados por caminho em relação ao execroot. ALPHABETICAL_BY_CONFIGURATION significa que os manifestos são classificados por caminhos relativos ao diretório de configuração no diretório de saída. DEPENDENCY significa que os manifestos são ordenados com o manifesto de cada biblioteca antes dos manifestos das dependências dela.
Tags:
action_command_lines,execution --[no]android_resource_shrinkingpadrão: "false"-
Ativa a redução de recursos para APKs android_binary que usam o ProGuard.
--[no]build_python_zippadrão: "auto"-
Criar zip executável do Python; ativado no Windows, desativado em outras plataformas
Tags:
affects_outputs --catalyst_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar binários do Apple Catalyst.
--[no]collect_code_coveragepadrão: "false"-
Se especificado, o Bazel vai instrumentar o código (usando instrumentação off-line sempre que possível) e coletar informações de cobertura durante os testes. Apenas os destinos que correspondem a --instrumentation_filter serão afetados. Normalmente, essa opção não deve ser especificada diretamente. Em vez disso, use o comando "bazel coverage".
Tags:
affects_outputs --compilation_mode=<fastbuild, dbg or opt>[-c] padrão: "fastbuild"-
Especifique o modo em que o binário será criado. Valores: "fastbuild", "dbg", "opt".
--conlyopt=<a string>vários usos são acumulados-
Opção adicional para transmitir ao gcc ao compilar arquivos de origem C.
--copt=<a string>vários usos são acumulados-
Outras opções para transmitir ao gcc.
--cpu=<a string>padrão: ""-
Descontinuada: essa flag não é usada internamente pelo Blaze, embora haja mapeamentos de plataforma legados para permitir a compatibilidade com versões anteriores. Não use essa flag. Em vez disso, use --platforms com uma definição de plataforma adequada.
Tags:
changes_inputs,affects_outputs --cs_fdo_absolute_path=<a string>padrão: consulte a descrição-
Use informações de perfil do CSFDO para otimizar a compilação. Especifique o nome do caminho absoluto do arquivo ZIP que contém o arquivo de perfil, um arquivo de perfil LLVM bruto ou indexado.
Tags:
affects_outputs --cs_fdo_instrument=<a string>padrão: consulte a descrição-
Gere binários com instrumentação FDO sensível ao contexto. Com o compilador Clang/LLVM, ele também aceita o nome do diretório em que os arquivos de perfil brutos serão despejados durante a execução.
Tags:
affects_outputs --cs_fdo_profile=<a build target label>padrão: consulte a descrição-
O cs_fdo_profile que representa o perfil sensível ao contexto a ser usado para otimização.
Tags:
affects_outputs --cxxopt=<a string>vários usos são acumulados-
Opção extra para transmitir ao gcc ao compilar arquivos de origem C++.
--define=<a 'name=value' assignment>vários usos são acumulados-
Cada opção "--define" especifica uma atribuição para uma variável de build. Em caso de vários valores para uma variável, o último vence.
Tags:
changes_inputs,affects_outputs --dynamic_mode=<off, default or fully>padrão: "default"-
Determina se os binários C++ serão vinculados dinamicamente. "default" significa que o Bazel vai escolher se a vinculação será dinâmica. "Totalmente" significa que todas as bibliotecas serão vinculadas dinamicamente. "off" significa que todas as bibliotecas serão vinculadas principalmente no modo estático.
--[no]enable_propeller_optimize_absolute_pathspadrão: "true"-
Se definido, qualquer uso de caminhos absolutos para a otimização do Propeller vai gerar um erro.
Tags:
affects_outputs --[no]enable_remaining_fdo_absolute_pathspadrão: "true"-
Se definido, qualquer uso de caminhos absolutos para FDO vai gerar um erro.
Tags:
affects_outputs --[no]enable_runfilespadrão: "auto"-
Ative a árvore de symlink de runfiles. Por padrão, ela fica desativada no Windows e ativada em outras plataformas.
Tags:
affects_outputs --exec_aspects=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de aspectos a serem aplicados a destinos configurados por execução, sejam eles de nível superior ou não. Este é um recurso experimental e está sujeito a mudanças.
Tags:
loading_and_analysis --experimental_action_listener=<a build target label>vários usos são acumulados-
Obsoleto, substituído por "aspectos". Use action_listener para anexar uma extra_action a ações de build atuais.
Tags:
execution,experimental --[no]experimental_android_compress_java_resourcespadrão: "false"-
Compactar recursos Java em APKs
--[no]experimental_android_databinding_v2padrão: "true"-
Use a vinculação de dados do Android v2. Essa flag não faz nada.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --[no]experimental_android_resource_shrinkingpadrão: "false"-
Ativa a redução de recursos para APKs android_binary que usam o ProGuard.
--[no]experimental_android_rewrite_dexes_with_rexpadrão: "false"-
usar a ferramenta rex para reescrever arquivos dex
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --[no]experimental_collect_code_coverage_for_generated_filespadrão: "false"-
Se especificado, o Bazel também vai gerar informações de cobertura de coleta para arquivos gerados.
Tags:
affects_outputs,experimental --experimental_objc_fastbuild_options=<comma-separated list of options>padrão: "-O0,-DDEBUG=1"-
Usa essas strings como opções do compilador objc fastbuild.
Tags:
action_command_lines --[no]experimental_omitfppadrão: "false"-
Se for verdadeiro, use libunwind para desenrolar a pilha e compile com -fomit-frame-pointer e -fasynchronous-unwind-tables.
--experimental_output_paths=<off or strip>padrão: "off"-
Qual modelo usar para onde as regras da árvore de saída gravam as saídas, principalmente para builds multiplataforma / multiconfiguração. Esse recurso é altamente experimental. Consulte https://github.com/bazelbuild/bazel/issues/6526 para mais detalhes. As ações do Starlark podem ativar o mapeamento de caminhos adicionando a chave "supports-path-mapping" ao dicionário "execution_requirements".
Tags:
loses_incremental_state,bazel_internal_configuration,affects_outputs,execution --experimental_override_platform_cpu_name=<a 'label=value' assignment>vários usos são acumulados-
Cada entrada precisa estar no formato "label=value", em que "label" se refere a uma plataforma e "value" é o nome abreviado desejado para substituir o nome da CPU da plataforma na variável de make $(TARGET_CPU) e no caminho de saída. Usado somente quando --experimental_platform_in_output_dir, --incompatible_target_cpu_from_platform ou --incompatible_bep_cpu_from_platform é verdadeiro. Tem a maior prioridade de nomenclatura.
Tags:
affects_outputs,experimental --[no]experimental_platform_in_output_dirpadrão: "false"-
Se for "true", um nome abreviado para a plataforma de destino será usado no nome do diretório de saída em vez da CPU. Se for "auto", isso só será aplicado à configuração de execução. O esquema exato é experimental e está sujeito a mudanças. Primeiro, no caso raro em que a opção "--platforms" não tem exatamente um valor, um hash da opção "platforms" é usado. Em seguida, se um nome abreviado para a plataforma atual foi registrado por --experimental_override_name_platform_in_output_dir, esse nome abreviado será usado. Em seguida, se --experimental_use_platforms_in_output_dir_legacy_heuristic estiver definido, use um nome abreviado com base no rótulo da plataforma atual. Por fim, um hash da opção de plataforma é usado como último recurso.
Tags:
affects_outputs,experimental --[no]experimental_py_binaries_include_labelpadrão: "false"-
Os destinos py_binary incluem o rótulo mesmo quando a inclusão de carimbos está desativada.
Tags:
affects_outputs,experimental --[no]experimental_use_llvm_covmappadrão: "false"-
Se especificado, o Bazel vai gerar informações de mapa de cobertura llvm-cov em vez de gcov quando collect_code_coverage estiver ativado.
Tags:
changes_inputs,affects_outputs,loading_and_analysis,experimental --[no]experimental_use_platforms_in_output_dir_legacy_heuristicpadrão: "true"-
Use essa flag apenas como parte de uma estratégia de migração ou teste sugerida. A heurística tem deficiências conhecidas. Por isso, recomendamos migrar para usar apenas --experimental_override_name_platform_in_output_dir.
Tags:
affects_outputs,experimental --fdo_instrument=<a string>padrão: consulte a descrição-
Gere binários com instrumentação FDO. Com o compilador Clang/LLVM, ele também aceita o nome do diretório em que os arquivos de perfil brutos serão despejados durante a execução.
Tags:
affects_outputs --fdo_optimize=<a string>padrão: consulte a descrição-
Use informações de perfil da FDO para otimizar a compilação. Especifique o nome de um arquivo zip que contenha uma árvore de arquivos .gcda, um arquivo afdo com um perfil automático ou um arquivo de perfil LLVM. Essa flag também aceita arquivos especificados como rótulos (por exemplo,
//foo/bar:file.afdo. Talvez seja necessário adicionar uma diretivaexports_filesao pacote correspondente) e rótulos que apontam para destinosfdo_profile. Essa flag será substituída pela regrafdo_profile.Tags:
affects_outputs --fdo_prefetch_hints=<a build target label>padrão: consulte a descrição-
Use dicas de pré-busca de cache.
Tags:
affects_outputs --fdo_profile=<a build target label>padrão: consulte a descrição-
O fdo_profile que representa o perfil a ser usado para otimização.
Tags:
affects_outputs --features=<a string>vários usos são acumulados-
Os recursos especificados serão ativados ou desativados por padrão para destinos criados na configuração de destino. Especificar -<recurso> desativa o recurso. Recursos negativos sempre substituem os positivos. Consulte também --host_features
Tags:
changes_inputs,affects_outputs --[no]force_picpadrão: "false"-
Se ativada, todas as compilações em C++ produzem código independente de posição ("-fPIC"), as vinculações preferem bibliotecas pré-criadas PIC em vez de bibliotecas não PIC, e as vinculações produzem executáveis independentes de posição ("-pie").
--host_action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable>vários usos são acumulados-
Especifica o conjunto de variáveis de ambiente disponíveis para ações com configurações de execução. As variáveis podem ser especificadas por nome, caso em que o valor será extraído do ambiente de invocação, pelo par nome=valor, que define o valor independente do ambiente de invocação, ou por <code>=name</code>, que desativa a variável desse nome. Essa opção pode ser usada várias vezes. Para opções fornecidas para a mesma variável, a mais recente vence. Para variáveis diferentes, as opções são acumuladas.
Tags:
action_command_lines --host_compilation_mode=<fastbuild, dbg or opt>padrão: "opt"-
Especifique o modo em que as ferramentas usadas durante a criação serão criadas. Valores: "fastbuild", "dbg", "opt".
--host_conlyopt=<a string>vários usos são acumulados-
Opção extra para transmitir ao compilador C ao compilar arquivos de origem C (mas não C++) nas configurações de execução.
--host_copt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas ao compilador C para ferramentas criadas nas configurações de execução.
--host_cpu=<a string>padrão: ""-
A CPU do host.
Tags:
changes_inputs,affects_outputs --host_cxxopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas ao compilador C++ para ferramentas criadas nas configurações de execução.
--host_features=<a string>vários usos são acumulados-
Os recursos especificados serão ativados ou desativados por padrão para destinos criados na configuração de execução. Especificar -<recurso> desativa o recurso. Recursos negativos sempre substituem os positivos.
Tags:
changes_inputs,affects_outputs --host_linkopt=<a string>vários usos são acumulados-
Opção extra para transmitir ao vinculador ao vincular ferramentas nas configurações de execução.
--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do macOS para destinos de host. Se não for especificado, usará "macos_sdk_version".
Tags:
loses_incremental_state --host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>vários usos são acumulados-
Outras opções para transmitir seletivamente ao compilador C/C++ ao compilar determinados arquivos nas configurações de execução. Essa opção pode ser transmitida várias vezes. Sintaxe: regex_filter@option_1,option_2,...,option_n. Em que regex_filter representa uma lista de padrões de expressões regulares de inclusão e exclusão (consulte também --instrumentation_filter). option_1 a option_n representam opções arbitrárias de linha de comando. Se uma opção tiver uma vírgula, ela precisa ser colocada entre aspas com uma barra invertida. As opções podem conter @. Somente o primeiro @ é usado para dividir a string. Exemplo: --host_per_file_copt=//foo/.*.cc,-//foo/bar.cc@-O0 adiciona a opção de linha de comando -O0 à linha de comando do gcc de todos os arquivos cc em //foo/, exceto bar.cc.
--[no]incompatible_auto_exec_groupspadrão: "false"-
Quando ativado, um grupo de execução é criado automaticamente para cada cadeia de ferramentas usada por uma regra. Para que isso funcione, a regra precisa especificar o parâmetro
toolchainnas ações dela. Para mais informações, consulte https://github.com/bazelbuild/bazel/issues/17134. --[no]incompatible_merge_genfiles_directorypadrão: "true"-
Se for verdadeiro, o diretório "genfiles" será incorporado ao diretório "bin".
--[no]incompatible_target_cpu_from_platformpadrão: "true"-
Se especificado, o valor da restrição de CPU (@platforms//cpu:cpu) da plataforma de destino será usado para definir a variável de criação $(TARGET_CPU).
--[no]instrument_test_targetspadrão: "false"-
Quando a cobertura está ativada, especifica se as regras de teste de instrumentação devem ser consideradas. Quando definido, as regras de teste incluídas por --instrumentation_filter são instrumentadas. Caso contrário, as regras de teste são sempre excluídas da instrumentação de cobertura.
Tags:
affects_outputs --instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>padrão: "-/javatests[/:],-/test/java[/:]"-
Quando a cobertura está ativada, apenas as regras com nomes incluídos pelo filtro especificado baseado em regex são instrumentadas. As regras com o prefixo "-" são excluídas. Somente regras que não são de teste são instrumentadas, a menos que a flag --instrument_test_targets esteja ativada.
Tags:
affects_outputs --ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do iOS para simuladores e dispositivos de destino. Se não for especificado, usará "ios_sdk_version".
Tags:
loses_incremental_state --ios_multi_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar um ios_application. O resultado é um binário universal que contém todas as arquiteturas especificadas.
--[no]legacy_whole_archivepadrão: "true"-
Obsoleto, substituído por --incompatible_remove_legacy_whole_archive. Consulte https://github.com/bazelbuild/bazel/issues/7362 para mais detalhes. Quando ativada, use --whole-archive para regras cc_binary que tenham linkshared=True e linkstatic=True ou "-static" em linkopts. Isso é apenas para compatibilidade com versões anteriores. Uma alternativa melhor é usar alwayslink=1 quando necessário.
--linkopt=<a string>vários usos são acumulados-
Opção extra a ser transmitida para o gcc ao vincular.
--ltobackendopt=<a string>vários usos são acumulados-
Opção adicional para transmitir à etapa de back-end do LTO (em --features=thin_lto).
--ltoindexopt=<a string>vários usos são acumulados-
Opção adicional para transmitir à etapa de indexação do LTO (em --features=thin_lto).
--macos_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para as quais criar binários do Apple macOS.
--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do macOS para destinos. Se não for especificado, usará "macos_sdk_version".
Tags:
loses_incremental_state --memprof_profile=<a build target label>padrão: consulte a descrição-
Usar o perfil memprof.
Tags:
affects_outputs --[no]objc_debug_with_GLIBCXXpadrão: "false"-
Se definido e o modo de compilação for "dbg", defina GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC e GLIBCPP_CONCEPT_CHECKS.
Tags:
action_command_lines --[no]objc_enable_binary_strippingpadrão: "false"-
Se é necessário realizar remoções de símbolos e código morto em binários vinculados. A remoção de binários será realizada se esta flag e --compilation_mode=opt forem especificadas.
Tags:
action_command_lines --objccopt=<a string>vários usos são acumulados-
Opções extras a serem transmitidas para o gcc ao compilar arquivos de origem Objective-C/C++.
Tags:
action_command_lines --per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>vários usos são acumulados-
Outras opções para transmitir seletivamente ao gcc ao compilar determinados arquivos. Essa opção pode ser transmitida várias vezes. Sintaxe: regex_filter@option_1,option_2,...,option_n. Em que regex_filter representa uma lista de padrões de expressões regulares de inclusão e exclusão (consulte também --instrumentation_filter). option_1 a option_n representam opções arbitrárias de linha de comando. Se uma opção tiver uma vírgula, ela precisa ser colocada entre aspas com uma barra invertida. As opções podem conter @. Somente o primeiro @ é usado para dividir a string. Exemplo: --per_file_copt=//foo/.*.cc,-//foo/bar.cc@-O0 adiciona a opção de linha de comando -O0 à linha de comando gcc de todos os arquivos cc em //foo/, exceto bar.cc.
--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>vários usos são acumulados-
Outras opções para transmitir seletivamente ao back-end do LTO (em --features=thin_lto) ao compilar determinados objetos de back-end. Essa opção pode ser transmitida várias vezes. Sintaxe: regex_filter@option_1,option_2,...,option_n. Em que regex_filter representa uma lista de padrões de expressão regular de inclusão e exclusão, e option_1 a option_n representam opções arbitrárias de linha de comando. Se uma opção tiver uma vírgula, ela precisa ser colocada entre aspas com uma barra invertida. As opções podem conter @. Somente o primeiro @ é usado para dividir a string. Exemplo: --per_file_ltobackendopt=//foo/.*.o,-//foo/bar.o@-O0 adiciona a opção de linha de comando -O0 à linha de comando do back-end LTO de todos os arquivos o em //foo/, exceto bar.o.
--platform_suffix=<a string>padrão: consulte a descrição-
Especifica um sufixo a ser adicionado ao diretório de configuração.
Tags:
loses_incremental_state,affects_outputs,loading_and_analysis --propeller_optimize=<a build target label>padrão: consulte a descrição-
Use as informações do perfil do Propeller para otimizar o destino do build.Um perfil do Propeller precisa consistir em pelo menos um de dois arquivos: um perfil cc e um perfil ld. Essa flag aceita um rótulo de build que precisa se referir aos arquivos de entrada do perfil do Propeller. Por exemplo, o arquivo BUILD que define o rótulo, em a/b/BUILD:propeller_optimize( name = "propeller_profile", cc_profile = "propeller_cc_profile.txt", ld_profile = "propeller_ld_profile.txt",)Talvez seja necessário adicionar uma diretiva exports_files ao pacote correspondente para tornar esses arquivos visíveis ao Bazel. A opção precisa ser usada como: --propeller_optimize=//a/b:propeller_profile
--propeller_optimize_absolute_cc_profile=<a string>padrão: consulte a descrição-
Nome do caminho absoluto do arquivo cc_profile para builds otimizados do Propeller.
Tags:
affects_outputs --propeller_optimize_absolute_ld_profile=<a string>padrão: consulte a descrição-
Nome do caminho absoluto do arquivo ld_profile para builds otimizados do Propeller.
Tags:
affects_outputs --run_under=<a prefix in front of command>padrão: consulte a descrição-
Prefixo a ser inserido antes dos executáveis dos comandos "test" e "run". Se o valor for "foo -bar" e a linha de comando de execução for "test_binary -baz", a linha de comando final será "foo -bar test_binary -baz".Isso também pode ser um rótulo para um destino executável. Alguns exemplos são: "valgrind", "strace", "strace -c", "valgrind --quiet --num-callers=20", "//package:target", "//package:target --options".
Tags:
action_command_lines -
Se for "true", as bibliotecas nativas com funcionalidade idêntica serão compartilhadas entre diferentes destinos.
--[no]stamppadrão: "false"-
Adicionar carimbo aos binários com a data, o nome de usuário, o nome do host, as informações do espaço de trabalho etc.
Tags:
affects_outputs - Padrão de
--strip=<always, sometimes or never>: "sometimes" -
Especifica se os binários e as bibliotecas compartilhadas devem ser removidos (usando "-Wl,--strip-debug"). O valor padrão "sometimes" significa remover se --compilation_mode=fastbuild.
Tags:
affects_outputs --stripopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas para a remoção ao gerar um binário "<name>.stripped".
--tvos_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar binários do Apple tvOS.
--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do tvOS para simuladores e dispositivos de destino. Se não for especificado, usará "tvos_sdk_version".
Tags:
loses_incremental_state --visionos_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar binários do Apple visionOS.
--watchos_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar binários do Apple watchOS.
--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do watchOS para simuladores e dispositivos de destino. Se não for especificado, usará "watchos_sdk_version".
Tags:
loses_incremental_state --xbinary_fdo=<a build target label>padrão: consulte a descrição-
Use informações de perfil do XbinaryFDO para otimizar a compilação. Especifique o nome do perfil binário cruzado padrão. Quando a opção é usada com --fdo_instrument/--fdo_optimize/--fdo_profile, essas opções sempre prevalecem como se xbinary_fdo nunca fosse especificado.
Tags:
affects_outputs
- Opções que afetam a rigidez com que o Bazel aplica entradas de build válidas (definições de regras, combinações de flags etc.):
--[no]check_visibilitypadrão: "true"-
Se desativado, os erros de visibilidade nas dependências de destino serão rebaixados para avisos.
--[no]desugar_for_androidpadrão: "true"-
Define se o bytecode Java 8 deve ser simplificado antes da conversão para DEX.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state --[no]desugar_java8_libspadrão: "false"-
Se as bibliotecas Java 8 compatíveis devem ser incluídas em apps para dispositivos legados.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --[no]enforce_constraintspadrão: "true"-
Verifica os ambientes com que cada destino é compatível e informa erros se algum destino tiver dependências que não oferecem suporte aos mesmos ambientes.
Tags:
build_file_semantics --[no]experimental_check_desugar_depspadrão: "true"-
Se é necessário verificar novamente a dessugarização correta no nível binário do Android.
--[no]experimental_enforce_transitive_visibilitypadrão: "false"-
Se verdadeiro, permite que package()s definam o atributo transitive_visibility para restringir quais pacotes podem depender deles.
Tags:
build_file_semantics,experimental --experimental_one_version_enforcement=<off, warning or error>padrão: "OFF"-
Quando ativada, essa opção exige que uma regra java_binary não contenha mais de uma versão do mesmo arquivo de classe no classpath. Essa aplicação pode interromper o build ou apenas resultar em avisos.
Tags:
loading_and_analysis --experimental_strict_java_deps=<off, warn, error, strict or default>padrão: "default"-
Se for verdadeiro, verifica se um destino Java declara explicitamente todos os destinos usados diretamente como dependências.
--[no]incompatible_check_testonly_for_output_filespadrão: "false"-
Se ativado, verifique testonly para destinos de pré-requisito que são arquivos de saída pesquisando o testonly da regra geradora. Isso corresponde à verificação de visibilidade.
--[no]incompatible_disable_native_android_rulespadrão: "false"-
Se ativada, o uso direto das regras nativas do Android será desativado. Use as regras do Starlark Android em https://github.com/bazelbuild/rules_android
--[no]incompatible_disable_native_apple_binary_rulepadrão: "false"-
Não faz nada. Mantido aqui para compatibilidade com versões anteriores.
--[no]one_version_enforcement_on_java_testspadrão: "true"-
Quando ativada e com experimental_one_version_enforcement definido como um valor diferente de NONE, impõe uma versão em destinos java_test. Essa flag pode ser desativada para melhorar a performance do teste incremental, mas isso pode fazer com que possíveis violações de uma versão sejam perdidas.
Tags:
loading_and_analysis --python_native_rules_allowlist=<a build target label>padrão: consulte a descrição-
Uma lista de permissões (destino package_group) a ser usada ao aplicar --incompatible_python_disallow_native_rules.
Tags:
loading_and_analysis --[no]strict_filesetspadrão: "false"-
Se essa opção estiver ativada, os conjuntos de arquivos que cruzam os limites do pacote serão informados como erros.
--strict_proto_deps=<off, warn, error, strict or default>padrão: "error"-
A menos que esteja OFF, verifica se um destino proto_library declara explicitamente todos os destinos usados diretamente como dependências.
Tags:
build_file_semantics,eagerness_to_exit,incompatible_change --strict_public_imports=<off, warn, error, strict or default>padrão: "off"-
A menos que esteja OFF, verifica se um destino proto_library declara explicitamente como exportados todos os destinos usados em "import public".
Tags:
build_file_semantics,eagerness_to_exit,incompatible_change --[no]strict_system_includespadrão: "false"-
Se for "true", os cabeçalhos encontrados por caminhos de inclusão do sistema (-isystem) também precisarão ser declarados.
--target_environment=<a build target label>vários usos são acumulados-
Declara o ambiente de destino deste build. Precisa ser uma referência de rótulo a uma regra de "ambiente". Se especificado, todos os destinos de nível superior precisam ser compatíveis com esse ambiente.
Tags:
changes_inputs
- Opções que afetam as saídas de assinatura de um build:
--apk_signing_method=<v1, v2, v1_v2 or v4>padrão: "v1_v2"-
Implementação a ser usada para assinar APKs
Tags:
action_command_lines,affects_outputs,loading_and_analysis --[no]device_debug_entitlementspadrão: "true"-
Se definido e o modo de compilação não for "opt", os apps objc vão incluir direitos de depuração ao assinar.
Tags:
changes_inputs --ios_signing_cert_name=<a string>padrão: consulte a descrição-
Nome do certificado a ser usado para assinatura do iOS. Se não for definido, vai voltar ao perfil de provisionamento. Pode ser a preferência de identidade do chaveiro do certificado ou (substring) do nome comum do certificado, conforme a página de manual do codesign (IDENTIDADES DE ASSINATURA).
Tags:
action_command_lines
- Essa opção afeta a semântica da linguagem Starlark ou a API de build acessível a arquivos BUILD, .bzl ou WORKSPACE.:
--[no]incompatible_disallow_sdk_frameworks_attributespadrão: "false"-
Se for "true", não permita os atributos sdk_frameworks e weak_sdk_frameworks em objc_library e objc_import.
--[no]incompatible_objc_alwayslink_by_defaultpadrão: "false"-
Se for verdadeiro, defina o valor padrão como verdadeiro para atributos alwayslink em objc_library e objc_import.
--[no]incompatible_python_disallow_native_rulespadrão: "false"-
Quando verdadeiro, um erro ocorre ao usar as regras py_* integradas. Em vez disso, as regras rule_python devem ser usadas. Consulte https://github.com/bazelbuild/bazel/issues/17773 para mais informações e instruções de migração.
- Opções que regem o comportamento do ambiente de teste ou do executor de testes:
--[no]allow_analysis_failurespadrão: "false"-
Se for "true", uma falha na análise de um destino de regra vai resultar na propagação de uma instância de "AnalysisFailureInfo" contendo a descrição do erro, em vez de resultar em uma falha de build.
Tags:
loading_and_analysis,experimental - Padrão de
--analysis_testing_deps_limit=<an integer>: "2000" -
Define o número máximo de dependências transitivas usando um atributo de regra com uma transição de configuração for_analysis_testing. Exceder esse limite vai resultar em um erro de regra.
Tags:
loading_and_analysis --[no]break_build_on_parallel_dex2oat_failurepadrão: "false"-
Se for "true", as falhas na ação dex2oat vão interromper o build em vez de executar dex2oat durante o tempo de execução do teste.
Tags:
loading_and_analysis,experimental --default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100>vários usos são acumulados-
Substitua a quantidade padrão de recursos para testes. O formato esperado é <resource>=<value>. Se um único número positivo for especificado como <value>, ele vai substituir os recursos padrão para todos os tamanhos de teste. Se quatro números separados por vírgulas forem especificados, eles vão substituir a quantidade de recursos para os tamanhos de teste pequeno, médio, grande e enorme, respectivamente. Os valores também podem ser HOST_RAM/HOST_CPU, seguidos opcionalmente por [-|]<float> (por exemplo, memory=HOST_RAM.1,HOST_RAM*.2,HOST_RAM*.3,HOST_RAM*.4). Os recursos de teste padrão especificados por essa flag são substituídos por recursos explícitos especificados em tags.
--[no]experimental_android_use_parallel_dex2oatpadrão: "false"-
Use dex2oat em paralelo para acelerar o android_test.
Tags:
loading_and_analysis,host_machine_resource_optimizations,experimental --[no]ios_memleakspadrão: "false"-
Ativa a verificação de vazamentos de memória em destinos ios_test.
Tags:
action_command_lines --ios_simulator_device=<a string>padrão: consulte a descrição-
O dispositivo a ser simulado ao executar um aplicativo iOS no simulador, por exemplo, "iPhone 6". Para conferir uma lista de dispositivos, execute "xcrun simctl list devicetypes" na máquina em que o simulador será executado.
Tags:
test_runner --ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
A versão do iOS a ser executada no simulador durante a execução ou o teste. Isso é ignorado para regras ios_test se um dispositivo de destino for especificado na regra.
Tags:
test_runner --runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once>vários usos são acumulados-
Especifica o número de vezes que cada teste será executado. Se alguma dessas tentativas falhar por qualquer motivo, todo o teste será considerado falho. Normalmente, o valor especificado é apenas um número inteiro. Exemplo: --runs_per_test=3 vai executar todos os testes três vezes. Sintaxe alternativa: regex_filter@runs_per_test. Em que runs_per_test representa um valor inteiro e regex_filter representa uma lista de padrões de expressões regulares de inclusão e exclusão (consulte também --instrumentation_filter). Exemplo: --runs_per_test=//foo/.,-//foo/bar/.@3 executa todos os testes em //foo/, exceto aqueles em foo/bar, três vezes. Essa opção pode ser transmitida várias vezes. O argumento transmitido mais recentemente que corresponde tem precedência. Se nada corresponder, o teste será executado apenas uma vez.
--test_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable>vários usos são acumulados-
Especifica outras variáveis de ambiente a serem injetadas no ambiente do executor de testes. As variáveis podem ser especificadas por <code>name</code>, nesse caso, o valor será lido do ambiente do cliente Bazel, ou pelo par <code>name=value</code>. As variáveis definidas anteriormente podem ser desdefinidas usando <code>=name</code>. Essa opção pode ser usada várias vezes para especificar várias variáveis. Usado apenas pelo comando "bazel test".
Tags:
test_runner --test_timeout=<a single integer or comma-separated list of 4 integers>padrão: "-1"-
Substitui os valores padrão de tempo limite de teste para tempos limite de teste (em segundos). Se um único valor inteiro positivo for especificado, ele vai substituir todas as categorias. Se quatro números inteiros separados por vírgulas forem especificados, eles vão substituir os tempos limite para curto, moderado, longo e eterno (nessa ordem). Em qualquer uma das formas, um valor de -1 informa ao Blaze para usar os tempos limite padrão para essa categoria.
--[no]zip_undeclared_test_outputspadrão: "false"-
Se for "true", as saídas de teste não declaradas serão arquivadas em um arquivo ZIP.
Tags:
test_runner
- Opções que acionam otimizações do tempo de build:
--[no]experimental_filter_library_jar_with_program_jarpadrão: "false"-
Filtre o ProGuard ProgramJar para remover todas as classes também presentes no LibraryJar.
Tags:
action_command_lines,experimental --[no]experimental_inmemory_dotd_filespadrão: "true"-
Se ativada, os arquivos .d do C++ serão transmitidos na memória diretamente dos nós de build remoto em vez de serem gravados em disco.
Tags:
loading_and_analysis,execution,affects_outputs,experimental --[no]experimental_inmemory_jdeps_filespadrão: "true"-
Se ativada, os arquivos de dependência (.jdeps) gerados de compilações Java serão transmitidos na memória diretamente dos nós de build remoto em vez de serem gravados no disco.
Tags:
loading_and_analysis,execution,affects_outputs,experimental --[no]experimental_retain_test_configuration_across_testonlypadrão: "false"-
Quando ativada, a flag --trim_test_configuration não vai remover a configuração de teste para regras marcadas como testonly=1. Isso reduz problemas de conflito de ações quando regras que não são de teste dependem de regras cc_test. Não tem efeito se "--trim_test_configuration" for "false".
Tags:
loading_and_analysis,loses_incremental_state,experimental --[no]experimental_unsupported_and_brittle_include_scanningpadrão: "false"-
Indica se é necessário restringir as entradas à compilação em C/C++ analisando as linhas #include dos arquivos de entrada. Isso pode melhorar a performance e a incrementalidade, diminuindo o tamanho das árvores de entrada de compilação. No entanto, ele também pode interromper builds porque o scanner de inclusão não implementa totalmente a semântica do pré-processador C. Em particular, ele não entende diretivas #include dinâmicas e ignora a lógica condicional do pré-processador. Use por sua conta e risco. Todos os problemas relacionados a essa denúncia que forem enviados serão encerrados.
Tags:
loading_and_analysis,execution,changes_inputs,experimental --[no]incremental_dexingpadrão: "true"-
Faz a maior parte do trabalho de dexing separadamente para cada arquivo Jar.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state --[no]objc_use_dotd_pruningpadrão: "true"-
Se definido, os arquivos .d emitidos pelo clang serão usados para remover o conjunto de entradas transmitidas para compilações objc.
--[no]process_headers_in_dependenciespadrão: "false"-
Ao criar um destino //a:a, processe os cabeçalhos em todos os destinos de que //a:a depende (se o processamento de cabeçalho estiver ativado para a cadeia de ferramentas).
Tags:
execution --[no]trim_test_configurationpadrão: "true"-
Quando ativada, as opções relacionadas a testes serão limpas abaixo do nível superior do build. Quando essa flag está ativa, os testes não podem ser criados como dependências de regras que não são de teste, mas as mudanças nas opções relacionadas a testes não fazem com que as regras que não são de teste sejam analisadas novamente.
- Opções que afetam a verbosidade, o formato ou o local do registro em log:
- Padrão de
--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>: "-.*" -
Imprime informações de depuração durante a resolução da cadeia de ferramentas. A flag usa uma regex, que é verificada em relação a tipos de cadeia de ferramentas e destinos específicos para ver qual depurar. É possível separar várias expressões regulares com vírgulas, e cada uma delas é verificada separadamente. Observação: a saída dessa flag é muito complexa e provavelmente só será útil para especialistas em resolução de toolchain.
Tags:
terminal_output --[no]verbose_visibility_errorspadrão: "false"-
Se ativados, os erros de visibilidade incluem mais informações de diagnóstico.
- Opções que especificam ou alteram uma entrada genérica para um comando do Bazel que não se enquadra em outras categorias:
--flag_alias=<a 'name=value' flag alias>vários usos são acumulados-
Define um nome abreviado para uma flag do Starlark. Ele usa um único par de chave-valor no formato "<chave>=<valor>" como argumento.
Tags:
changes_inputs,non_configurable --[no]incompatible_default_to_explicit_init_pypadrão: "false"-
Essa flag muda o comportamento padrão para que os arquivos init.py não sejam mais criados automaticamente nos arquivos de execução de destinos Python. Precisamente, quando um destino py_binary ou py_test tem legacy_create_init definido como "auto" (o padrão), ele é tratado como falso se e somente se essa flag estiver definida. Consulte https://github.com/bazelbuild/bazel/issues/10076.
- Opções diversas, não categorizadas de outra forma:
--[no]cache_test_results[-t] padrão: "auto"-
Se definido como "auto", o Bazel vai executar novamente um teste somente se: (1) o Bazel detectar mudanças no teste ou nas dependências dele, (2) o teste for marcado como externo, (3) várias execuções de teste forem solicitadas com --runs_per_test ou(4) o teste falhou anteriormente. Se definido como "yes", o Bazel armazena em cache todos os resultados de testes, exceto aqueles marcados como externos. Se definido como "no", o Bazel não armazena em cache nenhum resultado de teste.
- Padrão de
--[no]experimental_cancel_concurrent_tests: "never" -
Se for "on_failed" ou "on_passed", o Blaze vai cancelar os testes em execução simultânea na primeira execução com esse resultado. Isso só é útil em combinação com --runs_per_test_detects_flakes.
--[no]experimental_fetch_all_coverage_outputspadrão: "false"-
Se for verdadeiro, o Bazel vai buscar todo o diretório de dados de cobertura para cada teste durante uma execução de cobertura.
--[no]experimental_generate_llvm_lcovpadrão: "false"-
Se for verdadeiro, a cobertura do clang vai gerar um relatório LCOV.
- Padrão de
--experimental_java_classpath=<off, javabuilder, bazel or bazel_no_fallback>: "bazel" -
Ativa caminhos de classe reduzidos para compilações Java.
--[no]experimental_run_android_lint_on_java_rulespadrão: "false"-
Se as fontes java_* precisam ser validadas.
Tags:
affects_outputs,experimental --[no]explicit_java_test_depspadrão: "false"-
Especifique explicitamente uma dependência do JUnit ou do Hamcrest em um java_test em vez de obter acidentalmente das dependências do TestRunner. No momento, só funciona para bazel.
--host_java_launcher=<a build target label>padrão: consulte a descrição-
O iniciador Java usado por ferramentas executadas durante um build.
--host_javacopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas para o javac ao criar ferramentas executadas durante um build.
--host_jvmopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas para a VM Java ao criar ferramentas executadas durante o build. Essas opções serão adicionadas às opções de inicialização da VM de cada destino java_binary.
--[no]incompatible_check_sharding_supportpadrão: "true"-
Se for verdadeiro, o Bazel vai falhar em um teste fragmentado se o executor de testes não indicar que oferece suporte à fragmentação ao tocar no arquivo no caminho em TEST_SHARD_STATUS_FILE. Se for "false", um executor de testes que não oferece suporte a fragmentação vai fazer com que todos os testes sejam executados em cada fragmento.
Tags:
incompatible_change --[no]incompatible_exclusive_test_sandboxedpadrão: "true"-
Se for verdadeiro, os testes exclusivos serão executados com a estratégia em sandbox. Adicione a tag "local" para forçar uma execução de teste exclusiva localmente
Tags:
incompatible_change --[no]incompatible_strict_action_envpadrão: "false"-
Se for "true", o Bazel usará um ambiente com um valor estático para PATH e não vai herdar LD_LIBRARY_PATH. Use --action_env=ENV_VARIABLE se quiser herdar variáveis de ambiente específicas do cliente, mas observe que isso pode impedir o armazenamento em cache entre usuários se um cache compartilhado for usado.
--j2objc_translation_flags=<comma-separated list of options>vários usos são acumulados-
Outras opções a serem transmitidas para a ferramenta J2ObjC.
--java_debug-
Faz com que a máquina virtual Java de um teste Java aguarde uma conexão de um depurador compatível com JDWP (como jdb) antes de iniciar o teste. Implica -test_output=streamed.
Expande para:
--test_arg=--wrapper_script_flag=--debug
--test_output=streamed
--test_strategy=exclusive
--test_timeout=9999
--nocache_test_results --[no]java_depspadrão: "true"-
Gere informações de dependência (por enquanto, classpath de tempo de compilação) por destino Java.
--[no]java_header_compilationpadrão: "true"-
Compile ijars diretamente da origem.
--java_language_version=<a string>padrão: ""-
A versão da linguagem Java
--java_launcher=<a build target label>padrão: consulte a descrição-
O inicializador Java a ser usado ao criar binários Java. Se essa flag for definida como uma string vazia, o iniciador do JDK será usado. O atributo "launcher" substitui essa flag.
- Padrão de
--java_runtime_version=<a string>: "local_jdk" -
A versão do ambiente de execução do Java
--javacopt=<a string>vários usos são acumulados-
Outras opções para transmitir ao javac.
--jvmopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas para a VM Java. Essas opções serão adicionadas às opções de inicialização da VM de cada destino java_binary.
--legacy_main_dex_list_generator=<a build target label>padrão: consulte a descrição-
Especifica um binário a ser usado para gerar a lista de classes que precisam estar no dex principal ao compilar o multidex legado.
--optimizing_dexer=<a build target label>padrão: consulte a descrição-
Especifica um binário a ser usado para fazer dexing sem sharding.
--plugin=<a build target label>vários usos são acumulados-
Plug-ins a serem usados no build. No momento, funciona com java_plugin.
--proguard_top=<a build target label>padrão: consulte a descrição-
Especifica qual versão do ProGuard usar para remoção de código ao criar um binário Java.
--proto_compiler=<a build target label>default: "@bazel_tools//tools/proto:protoc"-
O rótulo do proto-compilador.
--[no]proto_profilepadrão: "true"-
Se o profile_path será transmitido ao compilador proto.
--proto_profile_path=<a build target label>padrão: consulte a descrição-
O perfil a ser transmitido ao compilador proto como profile_path. Se não for definido, mas --proto_profile for verdadeiro (o padrão), vai inferir o caminho de --fdo_optimize.
--proto_toolchain_for_cc=<a build target label>default: "@bazel_tools//tools/proto:cc_toolchain"-
Rótulo de proto_lang_toolchain() que descreve como compilar protos C++
--proto_toolchain_for_j2objc=<a build target label>padrão: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain"-
Rótulo de proto_lang_toolchain() que descreve como compilar protos j2objc.
--proto_toolchain_for_java=<a build target label>default: "@bazel_tools//tools/proto:java_toolchain"-
Rótulo de proto_lang_toolchain() que descreve como compilar protos Java.
--proto_toolchain_for_javalite=<a build target label>default: "@bazel_tools//tools/proto:javalite_toolchain"-
Rótulo de proto_lang_toolchain() que descreve como compilar protos do JavaLite.
--protocopt=<a string>vários usos são acumulados-
Outras opções para transmitir ao compilador protobuf.
Tags:
affects_outputs --[no]runs_per_test_detects_flakespadrão: "false"-
Se for "true", qualquer fragmento em que pelo menos uma execução/tentativa seja aprovada e pelo menos uma execução/tentativa falhe vai receber o status "FLAKY".
--shell_executable=<a path>padrão: consulte a descrição-
Caminho absoluto para o executável do shell que o Bazel vai usar. Se não estiver definido, mas a variável de ambiente BAZEL_SH estiver definida na primeira invocação do Bazel (que inicia um servidor do Bazel), o Bazel vai usar essa variável. Se nenhum dos dois estiver definido, o Bazel usará um caminho padrão codificado, dependendo do sistema operacional em que ele é executado (Windows: c:/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, todos os outros: /bin/bash). Usar um shell incompatível com bash pode causar falhas de build ou de tempo de execução dos binários gerados.
Tags:
loading_and_analysis --test_arg=<a string>vários usos são acumulados-
Especifica outras opções e argumentos que devem ser transmitidos para o executável de teste. Pode ser usado várias vezes para especificar vários argumentos. Se vários testes forem executados, cada um deles vai receber argumentos idênticos. Usado apenas pelo comando "bazel test".
--test_filter=<a string>padrão: consulte a descrição-
Especifica um filtro para encaminhar ao framework de teste. Usado para limitar os testes executados. Isso não afeta quais destinos são criados.
--test_result_expiration=<an integer>padrão: "-1"-
Essa opção foi descontinuada e não tem efeito.
--[no]test_runner_fail_fastpadrão: "false"-
Encaminha a opção de falha rápida para o executor de testes. O executor de testes precisa interromper a execução na primeira falha.
--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce>padrão: "explicit"-
Especifique a estratégia para o sharding de teste: "explicit" para usar o sharding somente se o atributo "shard_count" BUILD estiver presente. "disabled" para nunca usar o sharding de teste. "forced=k" para forçar "k" fragmentos para teste, independente do atributo "shard_count" BUILD.
--tool_java_language_version=<a string>padrão: ""-
A versão da linguagem Java usada para executar as ferramentas necessárias durante um build.
--tool_java_runtime_version=<a string>padrão: "remotejdk_11"-
A versão do ambiente de execução Java usada para executar ferramentas durante o build.
--[no]use_ijarspadrão: "true"-
Se ativada, essa opção faz com que a compilação Java use jars de interface. Isso resulta em uma compilação incremental mais rápida, mas as mensagens de erro podem ser diferentes.
Opções de dump
- Opções que controlam a saída do comando:
--[no]action_cachepadrão: "false"-
Despeja o conteúdo do cache de ações.
Tags:
bazel_monitoring --memory=<memory mode>padrão: consulte a descrição-
Despeja o uso de memória do nó Skyframe especificado.
Tags:
bazel_monitoring --[no]packagespadrão: "false"-
Despeja o conteúdo do cache do pacote.
Tags:
bazel_monitoring --[no]rule_classespadrão: "false"-
Despeja classes de regras.
Tags:
bazel_monitoring --[no]rulespadrão: "false"-
Regras de despejo, incluindo contagens e uso de memória (se a memória for rastreada).
Tags:
bazel_monitoring --skyframe=<off, summary, count, value, deps, rdeps, function_graph, active_directories or active_directories_frontier_deps>padrão: "off"-
Despeje o gráfico do Skyframe.
Tags:
bazel_monitoring - Padrão de
--skykey_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>: ".*" -
Filtro de regex dos nomes de SkyKey para saída. Usado apenas com --skyframe=deps, rdeps, function_graph.
Tags:
bazel_monitoring --skylark_memory=<a string>padrão: consulte a descrição-
Despeja um perfil de memória compatível com pprof no caminho especificado. Para saber mais, consulte https://github.com/google/pprof.
Tags:
bazel_monitoring
Opções de busca
Herda todas as opções de test.
- Opções que controlam a execução do build:
--[no]allpadrão: "false"-
Busca todos os repositórios externos necessários para criar qualquer destino ou repositório. Esse é o padrão se nenhuma outra flag ou argumento for fornecido. Só funciona quando --enable_bzlmod está ativado.
Tags:
changes_inputs --[no]keep_going[-k] padrão: "false"-
Continue o máximo possível após um erro. Embora o destino com falha e aqueles que dependem dele não possam ser analisados, outros pré-requisitos desses destinos podem ser.
Tags:
eagerness_to_exit --loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">padrão: "auto"-
Número de linhas de execução paralelas a serem usadas na fase de carregamento/análise. Recebe um número inteiro ou uma palavra-chave ("auto", "HOST_CPUS", "HOST_RAM"), opcionalmente seguida por uma operação ([-|]<float>), por exemplo, "auto", "HOST_CPUS.5". "auto" define um padrão razoável com base nos recursos do host. Precisa ser pelo menos 1.
- Essa opção afeta a semântica da linguagem Starlark ou a API de build acessível a arquivos BUILD, .bzl ou WORKSPACE.:
--[no]incompatible_config_setting_private_default_visibilitypadrão: "false"-
Se "incompatible_enforce_config_setting_visibility=false", isso não terá efeito. Caso contrário, se essa flag for "false", qualquer config_setting sem um atributo de visibilidade explícito será //visibility:public. Se essa flag for "true", "config_setting" vai seguir a mesma lógica de visibilidade de todas as outras regras. Consulte https://github.com/bazelbuild/bazel/issues/12933.
--[no]incompatible_enforce_config_setting_visibilitypadrão: "true"-
Se for "true", aplique as restrições de visibilidade de "config_setting". Se for "false", todas as config_setting serão visíveis para todos os destinos. Consulte https://github.com/bazelbuild/bazel/issues/12932.
- Opções relacionadas à saída e à semântica do Bzlmod:
--[no]configurepadrão: "false"-
Busca apenas repositórios marcados como "configurar" para fins de configuração do sistema. Só funciona quando --enable_bzlmod está ativado.
Tags:
changes_inputs --[no]forcepadrão: "false"-
Ignora o repositório atual, se houver, e força a busca novamente. Só funciona quando --enable_bzlmod está ativado.
Tags:
changes_inputs --repo=<a string>vários usos são acumulados-
Busca apenas o repositório especificado, que pode ser {@apparent_repo_name} ou {@@canonical_repo_name}. Só funciona quando --enable_bzlmod está ativado.
Tags:
changes_inputs
- Opções diversas, não categorizadas de outra forma:
--deleted_packages=<comma-separated list of package names>vários usos são acumulados-
Uma lista separada por vírgulas de nomes de pacotes que o sistema de build vai considerar inexistentes, mesmo que estejam visíveis em algum lugar no caminho do pacote. Use essa opção ao excluir um subpacote "x/y" de um pacote "x" existente. Por exemplo, depois de excluir x/y/BUILD no cliente, o sistema de build poderá reclamar se encontrar um rótulo "//x:y/z" se ele ainda for fornecido por outra entrada package_path. Especificar --deleted_packages x/y evita esse problema.
--[no]fetchpadrão: "true"-
Permite que o comando busque dependências externas. Se definido como "false", o comando vai usar qualquer versão em cache da dependência. Se não houver nenhuma, o comando vai falhar.
--package_path=<colon-separated list of options>padrão: "%workspace%"-
Uma lista separada por dois-pontos de onde procurar pacotes. Os elementos que começam com "%workspace%" são relativos ao espaço de trabalho envolvido. Se for omitido ou estiver vazio, o padrão será a saída de "bazel info default-package-path".
--[no]show_loading_progresspadrão: "true"-
Se ativada, faz com que o Bazel imprima mensagens "Carregando pacote:".
- Opções que controlam a execução do build:
--[no]experimental_persistent_aar_extractorpadrão: "false"-
Ative o extrator aar permanente usando workers.
Tags:
execution,experimental --[no]experimental_remotable_source_manifestspadrão: "false"-
Se as ações do manifesto de origem podem ser executadas remotamente
--[no]experimental_split_coverage_postprocessingpadrão: "false"-
Se for verdadeiro, o Bazel vai executar o pós-processamento de cobertura para o teste em uma nova geração.
Tags:
execution,experimental --[no]experimental_strict_fileset_outputpadrão: "false"-
Se essa opção estiver ativada, os conjuntos de arquivos vão tratar todos os artefatos de saída como arquivos regulares. Eles não vão percorrer diretórios nem serão sensíveis a symlinks.
Tags:
execution,experimental --[no]incompatible_modify_execution_info_additivepadrão: "true"-
Quando ativada, a transmissão de várias flags --modify_execution_info é cumulativa. Quando desativada, apenas a última flag é considerada.
Tags:
execution,affects_outputs,loading_and_analysis,incompatible_change --modify_execution_info=<regex=[+-]key,regex=[+-]key,...>vários usos são acumulados-
Adicione ou remova chaves das informações de execução de uma ação com base no mnemônico dela. Aplicável apenas a ações que oferecem suporte a informações de execução. Muitas ações comuns oferecem suporte a informações de execução, por exemplo, Genrule, CppCompile, Javac, StarlarkAction e TestRunner. Ao especificar vários valores, a ordem é importante porque muitas expressões regulares podem ser aplicadas ao mesmo mnemônico.
Sintaxe: "regex=[+-]key,regex=[+-]key,...".
Exemplos: '.=+x,.=-y,.=+z' adiciona "x" e "z" e remove "y" das informações de execução de todas as ações. "Genrule=+requires-x" adiciona "requires-x" às informações de execução de todas as ações Genrule. '(?!Genrule).=-requires-x' remove 'requires-x' das informações de execução de todas as ações que não são Genrule.
--persistent_android_dex_desugar-
Ative ações persistentes de dex e dessugar do Android usando workers.
Expande para:
--internal_persistent_android_dex_desugar
--strategy=Desugar=worker
--strategy=DexBuilder=worker --persistent_android_resource_processor-
Ative o processador de recursos persistentes do Android usando workers.
Expande para:
--internal_persistent_busybox_tools
--strategy=AaptPackage=worker
--strategy=AndroidResourceParser=worker
--strategy=AndroidResourceValidator=worker
--strategy=AndroidResourceCompiler=worker
--strategy=RClassGenerator=worker
--strategy=AndroidResourceLink=worker
--strategy=AndroidAapt2=worker
--strategy=AndroidAssetMerger=worker
--strategy=AndroidResourceMerger=worker
--strategy=AndroidCompiledResourceMerger=worker
--strategy=ManifestMerger=worker
--strategy=AndroidManifestMerger=worker
--strategy=Aapt2Optimize=worker
--strategy=AARGenerator=worker
--strategy=ProcessDatabinding=worker
--strategy=GenerateDataBindingBaseClasses=worker --persistent_multiplex_android_dex_desugar-
Ative ações persistentes e multiplexadas de dex e dessugar do Android usando workers.
Expande para:
--persistent_android_dex_desugar
--internal_persistent_multiplex_android_dex_desugar --persistent_multiplex_android_resource_processor-
Ative o processador de recursos do Android multiplexado persistente usando workers.
Expande para:
--persistent_android_resource_processor
--modify_execution_info=AaptPackage=+supports-multiplex-workers
--modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
--modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
--modify_execution_info=RClassGenerator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
--modify_execution_info=AndroidAapt2=+supports-multiplex-workers
--modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
--modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
--modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
--modify_execution_info=ManifestMerger=+supports-multiplex-workers
--modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
--modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
--modify_execution_info=AARGenerator=+supports-multiplex-workers --persistent_multiplex_android_tools-
Ativar ferramentas Android persistentes e multiplexadas (dexing, desugaring, processamento de recursos).
Expande para:
--internal_persistent_multiplex_busybox_tools
--persistent_multiplex_android_resource_processor
--persistent_multiplex_android_dex_desugar --[no]use_target_platform_for_testspadrão: "false"-
Se for "true", use a plataforma de destino para executar testes em vez do grupo de execução de teste.
Tags:
execution
- Opções que configuram o conjunto de ferramentas usado para a execução de ações:
--android_compiler=<a string>padrão: consulte a descrição-
O compilador de destino do Android.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state --android_manifest_merger=<legacy, android or force_android>padrão: "android"-
Seleciona o combinador de manifestos a ser usado para regras android_binary. Flag para ajudar na transição do combinador legado para o combinador do manifesto do Android.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state --android_platforms=<a build target label>padrão: ""-
Define as plataformas usadas pelas segmentações android_binary. Se várias plataformas forem especificadas, o binário será um APK fat, que contém binários nativos para cada plataforma de destino especificada.
Tags:
changes_inputs,loading_and_analysis,loses_incremental_state --cc_output_directory_tag=<a string>padrão: ""-
Especifica um sufixo a ser adicionado ao diretório de configuração.
Tags:
affects_outputs --compiler=<a string>padrão: consulte a descrição-
O compilador C++ a ser usado para compilar o destino.
Tags:
loading_and_analysis,execution --coverage_output_generator=<a build target label>default: "@bazel_tools//tools/test:lcov_merger"-
Local do binário usado para pós-processar relatórios de cobertura bruta. Precisa ser uma meta binária. O padrão é "//tools/test:lcov_merger".
--coverage_report_generator=<a build target label>default: "@bazel_tools//tools/test:coverage_report_generator"-
Local do binário usado para gerar relatórios de cobertura. Precisa ser uma meta binária. O padrão é "//tools/test:coverage_report_generator".
--coverage_support=<a build target label>default: "@bazel_tools//tools/test:coverage_support"-
Localização dos arquivos de suporte necessários nas entradas de todas as ações de teste que coletam cobertura de código. O padrão é "//tools/test:coverage_support".
--custom_malloc=<a build target label>padrão: consulte a descrição-
Especifica uma implementação de malloc personalizada. Essa configuração substitui os atributos malloc nas regras de build.
Tags:
changes_inputs,affects_outputs --[no]experimental_include_xcode_execution_requirementspadrão: "false"-
Se definido, adicione um requisito de execução "requires-xcode:{version}" a todas as ações do Xcode. Se a versão do Xcode tiver um rótulo hifenizado, adicione também um requisito de execução "requires-xcode-label:{version_label}".
Tags:
loses_incremental_state,loading_and_analysis,execution,experimental --[no]experimental_prefer_mutual_xcodepadrão: "true"-
Se for "true", use o Xcode mais recente disponível local e remotamente. Se for "false" ou se não houver versões disponíveis em comum, use a versão local do Xcode selecionada com xcode-select.
--extra_execution_platforms=<comma-separated list of options>padrão: ""-
As plataformas disponíveis como plataformas de execução para realizar ações. As plataformas podem ser especificadas por segmentação exata ou como um padrão de segmentação. Essas plataformas serão consideradas antes daquelas declaradas no arquivo WORKSPACE por register_execution_platforms(). Essa opção só pode ser definida uma vez. Instâncias posteriores vão substituir as configurações de flag anteriores.
Tags:
execution --extra_toolchains=<comma-separated list of options>vários usos são acumulados-
As regras da cadeia de ferramentas a serem consideradas durante a resolução da cadeia de ferramentas. As toolchains podem ser especificadas por destino exato ou como um padrão de destino. Esses conjuntos de ferramentas serão considerados antes daqueles declarados no arquivo WORKSPACE por register_toolchains().
--grte_top=<a label>padrão: consulte a descrição-
Um rótulo para uma biblioteca libc registrada. O valor padrão é selecionado pela cadeia de ferramentas crosstool, e quase nunca é necessário substituir esse valor.
--host_compiler=<a string>padrão: consulte a descrição-
Flag de nenhuma operação. Será removido em uma versão futura.
Tags:
loading_and_analysis,execution --host_grte_top=<a label>padrão: consulte a descrição-
Se especificada, essa configuração vai substituir o diretório de nível superior da libc (--grte_top) para a configuração de execução.
--host_platform=<a build target label>default: "@bazel_tools//tools:host_platform"-
O rótulo de uma regra de plataforma que descreve o sistema host.
--[no]incompatible_bazel_test_exec_run_underpadrão: "true"-
Se ativado, "bazel test --run_under=//:runner" vai criar "//:runner" na configuração de execução. Se estiver desativado, ele vai criar "//:runner" na configuração de destino. O Bazel executa testes em máquinas de execução, então o primeiro é mais correto. Isso não afeta "bazel run", que sempre cria "`--run_under=//foo" na configuração de destino.
--[no]incompatible_builtin_objc_strip_actionpadrão: "true"-
Se uma ação de remoção deve ser emitida como parte da vinculação objc.
--[no]incompatible_dont_enable_host_nonhost_crosstool_featurespadrão: "true"-
Se for "true", o Bazel não vai ativar os recursos "host" e "nonhost" na cadeia de ferramentas do C++ (consulte https://github.com/bazelbuild/bazel/issues/7407 para mais informações).
--[no]incompatible_enable_apple_toolchain_resolutionpadrão: "false"-
Use a resolução da cadeia de ferramentas para selecionar o SDK da Apple para regras da Apple (Starlark e nativas).
--[no]incompatible_remove_legacy_whole_archivepadrão: "true"-
Se for "true", o Bazel não vai vincular dependências de biblioteca como um arquivo inteiro por padrão. Consulte https://github.com/bazelbuild/bazel/issues/7362 para instruções de migração.
--[no]incompatible_strip_executable_safelypadrão: "false"-
Se for verdadeiro, a ação de remoção para executáveis usará a flag -x, que não interrompe a resolução dinâmica de símbolos.
-
Use objetos compartilhados de interface se forem compatíveis com o conjunto de ferramentas. Todas as toolchains ELF são compatíveis com essa configuração.
Tags:
loading_and_analysis,affects_outputs,affects_outputs --ios_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Especifica a versão do SDK para iOS a ser usada para criar aplicativos iOS. Se não for especificado, usará a versão padrão do SDK para iOS de "xcode_version".
Tags:
loses_incremental_state --macos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Especifica a versão do SDK do macOS a ser usada para criar aplicativos desse sistema operacional. Se não for especificado, usará a versão padrão do SDK do macOS de "xcode_version".
Tags:
loses_incremental_state --minimum_os_version=<a string>padrão: consulte a descrição-
A versão mínima do SO que sua compilação segmenta.
--platform_mappings=<a main workspace-relative path>padrão: ""-
O local de um arquivo de mapeamento que descreve qual plataforma usar se nenhuma estiver definida ou quais flags definir quando uma plataforma já existir. Precisa ser relativo à raiz do espaço de trabalho principal. O padrão é "platform_mappings", um arquivo diretamente na raiz do espaço de trabalho.
Tags:
affects_outputs,changes_inputs,loading_and_analysis,non_configurable --platforms=<a build target label>padrão: ""-
Os rótulos das regras de plataforma que descrevem as plataformas de destino para o comando atual.
--python_path=<a string>padrão: consulte a descrição-
O caminho absoluto do interpretador Python invocado para executar destinos Python na plataforma de destino. Obsoleto. Desativado por --incompatible_use_python_toolchains.
--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Especifica a versão do SDK do tvOS a ser usada para criar aplicativos desse sistema operacional. Se não for especificado, usará a versão padrão do SDK do tvOS de "xcode_version".
Tags:
loses_incremental_state --[no]use_platforms_in_apple_crosstool_transitionpadrão: "false"-
Faz com que apple_crosstool_transition volte a usar o valor da flag
--platformsem vez do--cpulegado quando necessário.Tags:
loading_and_analysis --watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Especifica a versão do SDK do watchOS a ser usada para criar aplicativos do watchOS. Se não for especificado, usará a versão padrão do SDK do watchOS de "xcode_version".
Tags:
loses_incremental_state --xcode_version=<a string>padrão: consulte a descrição-
Se especificado, usa o Xcode da versão fornecida para ações de build relevantes. Se não for especificado, vai usar a versão padrão do executor do Xcode.
Tags:
loses_incremental_state --xcode_version_config=<a build target label>default: "@bazel_tools//tools/cpp:host_xcodes"-
O rótulo da regra xcode_config a ser usada para selecionar a versão do Xcode na configuração de build.
- Opções que controlam a saída do comando:
--[no]apple_generate_dsympadrão: "false"-
Se é necessário gerar arquivos de símbolos de depuração (.dSYM).
--[no]build_runfile_linkspadrão: "true"-
Se for verdadeiro, vai criar florestas de symlink de runfiles para todos os destinos. Se for "false", grave-os apenas quando exigido por uma ação, teste ou comando de execução local.
Tags:
affects_outputs --[no]build_runfile_manifestspadrão: "true"-
Se verdadeiro, grava manifestos de runfiles para todos os destinos. Se for "false", omita-os. Os testes locais não serão executados quando for "false".
Tags:
affects_outputs --[no]build_test_dwppadrão: "false"-
Se ativado, ao criar testes em C++ de forma estática e com fusão, o arquivo .dwp do binário de teste também será criado automaticamente.
--cc_proto_library_header_suffixes=<comma-separated set of options>padrão: ".pb.h"-
Define os sufixos dos arquivos de cabeçalho que uma cc_proto_library cria.
- Padrão de
--cc_proto_library_source_suffixes=<comma-separated set of options>: ".pb.cc" -
Define os sufixos dos arquivos de origem que uma cc_proto_library cria.
--[no]experimental_proto_descriptor_sets_include_source_infopadrão: "false"-
Executa ações extras para versões alternativas da API Java em uma proto_library.
--[no]experimental_save_feature_statepadrão: "false"-
Salve o estado dos recursos ativados e solicitados como uma saída da compilação.
Tags:
affects_outputs,experimental --fission=<a set of compilation modes>padrão: "no"-
Especifica quais modos de compilação usam a fissão para compilações e vinculações em C++. Pode ser qualquer combinação de {'fastbuild', 'dbg', 'opt'} ou os valores especiais 'yes' para ativar todos os modos e 'no' para desativar todos os modos.
Tags:
loading_and_analysis,action_command_lines,affects_outputs --[no]incompatible_always_include_files_in_datapadrão: "true"-
Se for verdadeiro, as regras nativas vão adicionar <code>DefaultInfo.files</code> de dependências de dados aos runfiles, o que corresponde ao comportamento recomendado para regras do Starlark (https://bazel.build/extending/rules#runfiles_features_to_avoid).
--[no]incompatible_compact_repo_mapping_manifestpadrão: "false"-
Se ativado, o arquivo <binary>.repo_mapping vai emitir o mapeamento de repositório de uma extensão de módulo apenas uma vez, em vez de uma vez para cada repositório gerado pela extensão que contribui com runfiles.
--incompatible_disable_select_on=<comma-separated set of options>padrão: ""-
Lista de flags para as quais o uso em select() está desativado.
Tags:
loading_and_analysis,incompatible_change,non_configurable --[no]incompatible_filegroup_runfiles_for_datapadrão: "true"-
Se for verdadeiro, os runfiles dos destinos listados no atributo "srcs" estarão disponíveis para os destinos que consomem o filegroup como uma dependência de dados.
Tags:
incompatible_change --[no]objc_generate_linkmappadrão: "false"-
Especifica se um arquivo linkmap será gerado.
Tags:
affects_outputs --[no]save_tempspadrão: "false"-
Se definido, as saídas temporárias do gcc serão salvas. Eles incluem arquivos .s (código de assembler), .i (C pré-processado) e .ii (C++ pré-processado).
Tags:
affects_outputs
- Opções que permitem ao usuário configurar a saída pretendida, afetando o valor dela, e não a existência:
--action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable>vários usos são acumulados-
Especifica o conjunto de variáveis de ambiente disponíveis para ações com configuração de destino. As variáveis podem ser especificadas por <code>name</code>, em que o valor é extraído do ambiente de invocação, pelo par <code>name=value</code>, que define o valor independente do ambiente de invocação, ou por <code>=name</code>, que desativa a variável com esse nome. Essa opção pode ser usada várias vezes. Para opções fornecidas para a mesma variável, a mais recente vence. Para variáveis diferentes, as opções são acumuladas. <br> A menos que <code>--incompatible_repo_env_ignores_action_env</code> seja verdadeiro, todos os pares <code>name=value</code> estarão disponíveis para as regras do repositório.
Tags:
action_command_lines --allowed_cpu_values=<comma-separated set of options>padrão: ""-
Valores permitidos para a flag "--cpu".
Tags:
changes_inputs,affects_outputs --[no]android_databinding_use_androidxpadrão: "true"-
Gere arquivos de vinculação de dados compatíveis com o AndroidX. Isso só é usado com a vinculação de dados v2. Essa flag não faz nada.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --[no]android_databinding_use_v3_4_argspadrão: "true"-
Use a vinculação de dados do Android v2 com o argumento 3.4.0. Essa flag não faz nada.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --android_dynamic_mode=<off, default or fully>padrão: "off"-
Determina se as dependências C++ das regras do Android serão vinculadas dinamicamente quando um cc_binary não criar explicitamente uma biblioteca compartilhada. "default" significa que o bazel vai escolher se a vinculação será dinâmica. "Totalmente" significa que todas as bibliotecas serão vinculadas dinamicamente. "off" significa que todas as bibliotecas serão vinculadas principalmente no modo estático.
- Padrão de
--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency>: "alphabetical" -
Define a ordem dos manifestos transmitidos à ferramenta de mescla de manifestos para binários do Android. ALPHABETICAL significa que os manifestos são classificados por caminho em relação ao execroot. ALPHABETICAL_BY_CONFIGURATION significa que os manifestos são classificados por caminhos relativos ao diretório de configuração no diretório de saída. DEPENDENCY significa que os manifestos são ordenados com o manifesto de cada biblioteca antes dos manifestos das dependências dela.
Tags:
action_command_lines,execution --[no]android_resource_shrinkingpadrão: "false"-
Ativa a redução de recursos para APKs android_binary que usam o ProGuard.
--[no]build_python_zippadrão: "auto"-
Criar zip executável do Python; ativado no Windows, desativado em outras plataformas
Tags:
affects_outputs --catalyst_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar binários do Apple Catalyst.
--[no]collect_code_coveragepadrão: "false"-
Se especificado, o Bazel vai instrumentar o código (usando instrumentação off-line sempre que possível) e coletar informações de cobertura durante os testes. Apenas os destinos que correspondem a --instrumentation_filter serão afetados. Normalmente, essa opção não deve ser especificada diretamente. Em vez disso, use o comando "bazel coverage".
Tags:
affects_outputs --compilation_mode=<fastbuild, dbg or opt>[-c] padrão: "fastbuild"-
Especifique o modo em que o binário será criado. Valores: "fastbuild", "dbg", "opt".
--conlyopt=<a string>vários usos são acumulados-
Opção adicional para transmitir ao gcc ao compilar arquivos de origem C.
--copt=<a string>vários usos são acumulados-
Outras opções para transmitir ao gcc.
--cpu=<a string>padrão: ""-
Descontinuada: essa flag não é usada internamente pelo Blaze, embora haja mapeamentos de plataforma legados para permitir a compatibilidade com versões anteriores. Não use essa flag. Em vez disso, use --platforms com uma definição de plataforma adequada.
Tags:
changes_inputs,affects_outputs --cs_fdo_absolute_path=<a string>padrão: consulte a descrição-
Use informações de perfil do CSFDO para otimizar a compilação. Especifique o nome do caminho absoluto do arquivo ZIP que contém o arquivo de perfil, um arquivo de perfil LLVM bruto ou indexado.
Tags:
affects_outputs --cs_fdo_instrument=<a string>padrão: consulte a descrição-
Gere binários com instrumentação FDO sensível ao contexto. Com o compilador Clang/LLVM, ele também aceita o nome do diretório em que os arquivos de perfil brutos serão despejados durante a execução.
Tags:
affects_outputs --cs_fdo_profile=<a build target label>padrão: consulte a descrição-
O cs_fdo_profile que representa o perfil sensível ao contexto a ser usado para otimização.
Tags:
affects_outputs --cxxopt=<a string>vários usos são acumulados-
Opção extra para transmitir ao gcc ao compilar arquivos de origem C++.
--define=<a 'name=value' assignment>vários usos são acumulados-
Cada opção "--define" especifica uma atribuição para uma variável de build. Em caso de vários valores para uma variável, o último vence.
Tags:
changes_inputs,affects_outputs --dynamic_mode=<off, default or fully>padrão: "default"-
Determina se os binários C++ serão vinculados dinamicamente. "default" significa que o Bazel vai escolher se a vinculação será dinâmica. "Totalmente" significa que todas as bibliotecas serão vinculadas dinamicamente. "off" significa que todas as bibliotecas serão vinculadas principalmente no modo estático.
--[no]enable_propeller_optimize_absolute_pathspadrão: "true"-
Se definido, qualquer uso de caminhos absolutos para a otimização do Propeller vai gerar um erro.
Tags:
affects_outputs --[no]enable_remaining_fdo_absolute_pathspadrão: "true"-
Se definido, qualquer uso de caminhos absolutos para FDO vai gerar um erro.
Tags:
affects_outputs --[no]enable_runfilespadrão: "auto"-
Ative a árvore de symlink de runfiles. Por padrão, ela fica desativada no Windows e ativada em outras plataformas.
Tags:
affects_outputs --exec_aspects=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de aspectos a serem aplicados a destinos configurados por execução, sejam eles de nível superior ou não. Este é um recurso experimental e está sujeito a mudanças.
Tags:
loading_and_analysis --experimental_action_listener=<a build target label>vários usos são acumulados-
Obsoleto, substituído por "aspectos". Use action_listener para anexar uma extra_action a ações de build atuais.
Tags:
execution,experimental --[no]experimental_android_compress_java_resourcespadrão: "false"-
Compactar recursos Java em APKs
--[no]experimental_android_databinding_v2padrão: "true"-
Use a vinculação de dados do Android v2. Essa flag não faz nada.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --[no]experimental_android_resource_shrinkingpadrão: "false"-
Ativa a redução de recursos para APKs android_binary que usam o ProGuard.
--[no]experimental_android_rewrite_dexes_with_rexpadrão: "false"-
usar a ferramenta rex para reescrever arquivos dex
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --[no]experimental_collect_code_coverage_for_generated_filespadrão: "false"-
Se especificado, o Bazel também vai gerar informações de cobertura de coleta para arquivos gerados.
Tags:
affects_outputs,experimental --experimental_objc_fastbuild_options=<comma-separated list of options>padrão: "-O0,-DDEBUG=1"-
Usa essas strings como opções do compilador objc fastbuild.
Tags:
action_command_lines --[no]experimental_omitfppadrão: "false"-
Se for verdadeiro, use libunwind para desenrolar a pilha e compile com -fomit-frame-pointer e -fasynchronous-unwind-tables.
--experimental_output_paths=<off or strip>padrão: "off"-
Qual modelo usar para onde as regras da árvore de saída gravam as saídas, principalmente para builds multiplataforma / multiconfiguração. Esse recurso é altamente experimental. Consulte https://github.com/bazelbuild/bazel/issues/6526 para mais detalhes. As ações do Starlark podem ativar o mapeamento de caminhos adicionando a chave "supports-path-mapping" ao dicionário "execution_requirements".
Tags:
loses_incremental_state,bazel_internal_configuration,affects_outputs,execution --experimental_override_platform_cpu_name=<a 'label=value' assignment>vários usos são acumulados-
Cada entrada precisa estar no formato "label=value", em que "label" se refere a uma plataforma e "value" é o nome abreviado desejado para substituir o nome da CPU da plataforma na variável de make $(TARGET_CPU) e no caminho de saída. Usado somente quando --experimental_platform_in_output_dir, --incompatible_target_cpu_from_platform ou --incompatible_bep_cpu_from_platform é verdadeiro. Tem a maior prioridade de nomenclatura.
Tags:
affects_outputs,experimental --[no]experimental_platform_in_output_dirpadrão: "false"-
Se for "true", um nome abreviado para a plataforma de destino será usado no nome do diretório de saída em vez da CPU. Se for "auto", isso só será aplicado à configuração de execução. O esquema exato é experimental e está sujeito a mudanças. Primeiro, no caso raro em que a opção "--platforms" não tem exatamente um valor, um hash da opção "platforms" é usado. Em seguida, se um nome abreviado para a plataforma atual foi registrado por --experimental_override_name_platform_in_output_dir, esse nome abreviado será usado. Em seguida, se --experimental_use_platforms_in_output_dir_legacy_heuristic estiver definido, use um nome abreviado com base no rótulo da plataforma atual. Por fim, um hash da opção de plataforma é usado como último recurso.
Tags:
affects_outputs,experimental --[no]experimental_py_binaries_include_labelpadrão: "false"-
Os destinos py_binary incluem o rótulo mesmo quando a inclusão de carimbos está desativada.
Tags:
affects_outputs,experimental --[no]experimental_use_llvm_covmappadrão: "false"-
Se especificado, o Bazel vai gerar informações de mapa de cobertura llvm-cov em vez de gcov quando collect_code_coverage estiver ativado.
Tags:
changes_inputs,affects_outputs,loading_and_analysis,experimental --[no]experimental_use_platforms_in_output_dir_legacy_heuristicpadrão: "true"-
Use essa flag apenas como parte de uma estratégia de migração ou teste sugerida. A heurística tem deficiências conhecidas. Por isso, recomendamos migrar para usar apenas --experimental_override_name_platform_in_output_dir.
Tags:
affects_outputs,experimental --fdo_instrument=<a string>padrão: consulte a descrição-
Gere binários com instrumentação FDO. Com o compilador Clang/LLVM, ele também aceita o nome do diretório em que os arquivos de perfil brutos serão despejados durante a execução.
Tags:
affects_outputs --fdo_optimize=<a string>padrão: consulte a descrição-
Use informações de perfil da FDO para otimizar a compilação. Especifique o nome de um arquivo zip que contenha uma árvore de arquivos .gcda, um arquivo afdo com um perfil automático ou um arquivo de perfil LLVM. Essa flag também aceita arquivos especificados como rótulos (por exemplo,
//foo/bar:file.afdo. Talvez seja necessário adicionar uma diretivaexports_filesao pacote correspondente) e rótulos que apontam para destinosfdo_profile. Essa flag será substituída pela regrafdo_profile.Tags:
affects_outputs --fdo_prefetch_hints=<a build target label>padrão: consulte a descrição-
Use dicas de pré-busca de cache.
Tags:
affects_outputs --fdo_profile=<a build target label>padrão: consulte a descrição-
O fdo_profile que representa o perfil a ser usado para otimização.
Tags:
affects_outputs --features=<a string>vários usos são acumulados-
Os recursos especificados serão ativados ou desativados por padrão para destinos criados na configuração de destino. Especificar -<recurso> desativa o recurso. Recursos negativos sempre substituem os positivos. Consulte também --host_features
Tags:
changes_inputs,affects_outputs --[no]force_picpadrão: "false"-
Se ativada, todas as compilações em C++ produzem código independente de posição ("-fPIC"), as vinculações preferem bibliotecas pré-criadas PIC em vez de bibliotecas não PIC, e as vinculações produzem executáveis independentes de posição ("-pie").
--host_action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable>vários usos são acumulados-
Especifica o conjunto de variáveis de ambiente disponíveis para ações com configurações de execução. As variáveis podem ser especificadas por nome, caso em que o valor será extraído do ambiente de invocação, pelo par nome=valor, que define o valor independente do ambiente de invocação, ou por <code>=name</code>, que desativa a variável desse nome. Essa opção pode ser usada várias vezes. Para opções fornecidas para a mesma variável, a mais recente vence. Para variáveis diferentes, as opções são acumuladas.
Tags:
action_command_lines --host_compilation_mode=<fastbuild, dbg or opt>padrão: "opt"-
Especifique o modo em que as ferramentas usadas durante a criação serão criadas. Valores: "fastbuild", "dbg", "opt".
--host_conlyopt=<a string>vários usos são acumulados-
Opção extra para transmitir ao compilador C ao compilar arquivos de origem C (mas não C++) nas configurações de execução.
--host_copt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas ao compilador C para ferramentas criadas nas configurações de execução.
--host_cpu=<a string>padrão: ""-
A CPU do host.
Tags:
changes_inputs,affects_outputs --host_cxxopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas ao compilador C++ para ferramentas criadas nas configurações de execução.
--host_features=<a string>vários usos são acumulados-
Os recursos especificados serão ativados ou desativados por padrão para destinos criados na configuração de execução. Especificar -<recurso> desativa o recurso. Recursos negativos sempre substituem os positivos.
Tags:
changes_inputs,affects_outputs --host_linkopt=<a string>vários usos são acumulados-
Opção extra para transmitir ao vinculador ao vincular ferramentas nas configurações de execução.
--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do macOS para destinos de host. Se não for especificado, usará "macos_sdk_version".
Tags:
loses_incremental_state --host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>vários usos são acumulados-
Outras opções para transmitir seletivamente ao compilador C/C++ ao compilar determinados arquivos nas configurações de execução. Essa opção pode ser transmitida várias vezes. Sintaxe: regex_filter@option_1,option_2,...,option_n. Em que regex_filter representa uma lista de padrões de expressões regulares de inclusão e exclusão (consulte também --instrumentation_filter). option_1 a option_n representam opções arbitrárias de linha de comando. Se uma opção tiver uma vírgula, ela precisa ser colocada entre aspas com uma barra invertida. As opções podem conter @. Somente o primeiro @ é usado para dividir a string. Exemplo: --host_per_file_copt=//foo/.*.cc,-//foo/bar.cc@-O0 adiciona a opção de linha de comando -O0 à linha de comando do gcc de todos os arquivos cc em //foo/, exceto bar.cc.
--[no]incompatible_auto_exec_groupspadrão: "false"-
Quando ativado, um grupo de execução é criado automaticamente para cada cadeia de ferramentas usada por uma regra. Para que isso funcione, a regra precisa especificar o parâmetro
toolchainnas ações dela. Para mais informações, consulte https://github.com/bazelbuild/bazel/issues/17134. --[no]incompatible_merge_genfiles_directorypadrão: "true"-
Se for verdadeiro, o diretório "genfiles" será incorporado ao diretório "bin".
--[no]incompatible_target_cpu_from_platformpadrão: "true"-
Se especificado, o valor da restrição de CPU (@platforms//cpu:cpu) da plataforma de destino será usado para definir a variável de criação $(TARGET_CPU).
--[no]instrument_test_targetspadrão: "false"-
Quando a cobertura está ativada, especifica se as regras de teste de instrumentação devem ser consideradas. Quando definido, as regras de teste incluídas por --instrumentation_filter são instrumentadas. Caso contrário, as regras de teste são sempre excluídas da instrumentação de cobertura.
Tags:
affects_outputs --instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>padrão: "-/javatests[/:],-/test/java[/:]"-
Quando a cobertura está ativada, apenas as regras com nomes incluídos pelo filtro especificado baseado em regex são instrumentadas. As regras com o prefixo "-" são excluídas. Somente regras que não são de teste são instrumentadas, a menos que a flag --instrument_test_targets esteja ativada.
Tags:
affects_outputs --ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do iOS para simuladores e dispositivos de destino. Se não for especificado, usará "ios_sdk_version".
Tags:
loses_incremental_state --ios_multi_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar um ios_application. O resultado é um binário universal que contém todas as arquiteturas especificadas.
--[no]legacy_whole_archivepadrão: "true"-
Obsoleto, substituído por --incompatible_remove_legacy_whole_archive. Consulte https://github.com/bazelbuild/bazel/issues/7362 para mais detalhes. Quando ativada, use --whole-archive para regras cc_binary que tenham linkshared=True e linkstatic=True ou "-static" em linkopts. Isso é apenas para compatibilidade com versões anteriores. Uma alternativa melhor é usar alwayslink=1 quando necessário.
--linkopt=<a string>vários usos são acumulados-
Opção extra a ser transmitida para o gcc ao vincular.
--ltobackendopt=<a string>vários usos são acumulados-
Opção adicional para transmitir à etapa de back-end do LTO (em --features=thin_lto).
--ltoindexopt=<a string>vários usos são acumulados-
Opção adicional para transmitir à etapa de indexação do LTO (em --features=thin_lto).
--macos_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para as quais criar binários do Apple macOS.
--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do macOS para destinos. Se não for especificado, usará "macos_sdk_version".
Tags:
loses_incremental_state --memprof_profile=<a build target label>padrão: consulte a descrição-
Usar o perfil memprof.
Tags:
affects_outputs --[no]objc_debug_with_GLIBCXXpadrão: "false"-
Se definido e o modo de compilação for "dbg", defina GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC e GLIBCPP_CONCEPT_CHECKS.
Tags:
action_command_lines --[no]objc_enable_binary_strippingpadrão: "false"-
Se é necessário realizar remoções de símbolos e código morto em binários vinculados. A remoção de binários será realizada se esta flag e --compilation_mode=opt forem especificadas.
Tags:
action_command_lines --objccopt=<a string>vários usos são acumulados-
Opções extras a serem transmitidas para o gcc ao compilar arquivos de origem Objective-C/C++.
Tags:
action_command_lines --per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>vários usos são acumulados-
Outras opções para transmitir seletivamente ao gcc ao compilar determinados arquivos. Essa opção pode ser transmitida várias vezes. Sintaxe: regex_filter@option_1,option_2,...,option_n. Em que regex_filter representa uma lista de padrões de expressões regulares de inclusão e exclusão (consulte também --instrumentation_filter). option_1 a option_n representam opções arbitrárias de linha de comando. Se uma opção tiver uma vírgula, ela precisa ser colocada entre aspas com uma barra invertida. As opções podem conter @. Somente o primeiro @ é usado para dividir a string. Exemplo: --per_file_copt=//foo/.*.cc,-//foo/bar.cc@-O0 adiciona a opção de linha de comando -O0 à linha de comando gcc de todos os arquivos cc em //foo/, exceto bar.cc.
--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>vários usos são acumulados-
Outras opções para transmitir seletivamente ao back-end do LTO (em --features=thin_lto) ao compilar determinados objetos de back-end. Essa opção pode ser transmitida várias vezes. Sintaxe: regex_filter@option_1,option_2,...,option_n. Em que regex_filter representa uma lista de padrões de expressão regular de inclusão e exclusão, e option_1 a option_n representam opções arbitrárias de linha de comando. Se uma opção tiver uma vírgula, ela precisa ser colocada entre aspas com uma barra invertida. As opções podem conter @. Somente o primeiro @ é usado para dividir a string. Exemplo: --per_file_ltobackendopt=//foo/.*.o,-//foo/bar.o@-O0 adiciona a opção de linha de comando -O0 à linha de comando do back-end LTO de todos os arquivos o em //foo/, exceto bar.o.
--platform_suffix=<a string>padrão: consulte a descrição-
Especifica um sufixo a ser adicionado ao diretório de configuração.
Tags:
loses_incremental_state,affects_outputs,loading_and_analysis --propeller_optimize=<a build target label>padrão: consulte a descrição-
Use as informações do perfil do Propeller para otimizar o destino do build.Um perfil do Propeller precisa consistir em pelo menos um de dois arquivos: um perfil cc e um perfil ld. Essa flag aceita um rótulo de build que precisa se referir aos arquivos de entrada do perfil do Propeller. Por exemplo, o arquivo BUILD que define o rótulo, em a/b/BUILD:propeller_optimize( name = "propeller_profile", cc_profile = "propeller_cc_profile.txt", ld_profile = "propeller_ld_profile.txt",)Talvez seja necessário adicionar uma diretiva exports_files ao pacote correspondente para tornar esses arquivos visíveis ao Bazel. A opção precisa ser usada como: --propeller_optimize=//a/b:propeller_profile
--propeller_optimize_absolute_cc_profile=<a string>padrão: consulte a descrição-
Nome do caminho absoluto do arquivo cc_profile para builds otimizados do Propeller.
Tags:
affects_outputs --propeller_optimize_absolute_ld_profile=<a string>padrão: consulte a descrição-
Nome do caminho absoluto do arquivo ld_profile para builds otimizados do Propeller.
Tags:
affects_outputs --run_under=<a prefix in front of command>padrão: consulte a descrição-
Prefixo a ser inserido antes dos executáveis dos comandos "test" e "run". Se o valor for "foo -bar" e a linha de comando de execução for "test_binary -baz", a linha de comando final será "foo -bar test_binary -baz".Isso também pode ser um rótulo para um destino executável. Alguns exemplos são: "valgrind", "strace", "strace -c", "valgrind --quiet --num-callers=20", "//package:target", "//package:target --options".
Tags:
action_command_lines -
Se for "true", as bibliotecas nativas com funcionalidade idêntica serão compartilhadas entre diferentes destinos.
--[no]stamppadrão: "false"-
Adicionar carimbo aos binários com a data, o nome de usuário, o nome do host, as informações do espaço de trabalho etc.
Tags:
affects_outputs - Padrão de
--strip=<always, sometimes or never>: "sometimes" -
Especifica se os binários e as bibliotecas compartilhadas devem ser removidos (usando "-Wl,--strip-debug"). O valor padrão "sometimes" significa remover se --compilation_mode=fastbuild.
Tags:
affects_outputs --stripopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas para a remoção ao gerar um binário "<name>.stripped".
--tvos_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar binários do Apple tvOS.
--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do tvOS para simuladores e dispositivos de destino. Se não for especificado, usará "tvos_sdk_version".
Tags:
loses_incremental_state --visionos_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar binários do Apple visionOS.
--watchos_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar binários do Apple watchOS.
--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do watchOS para simuladores e dispositivos de destino. Se não for especificado, usará "watchos_sdk_version".
Tags:
loses_incremental_state --xbinary_fdo=<a build target label>padrão: consulte a descrição-
Use informações de perfil do XbinaryFDO para otimizar a compilação. Especifique o nome do perfil binário cruzado padrão. Quando a opção é usada com --fdo_instrument/--fdo_optimize/--fdo_profile, essas opções sempre prevalecem como se xbinary_fdo nunca fosse especificado.
Tags:
affects_outputs
- Opções que afetam a rigidez com que o Bazel aplica entradas de build válidas (definições de regras, combinações de flags etc.):
--[no]check_visibilitypadrão: "true"-
Se desativado, os erros de visibilidade nas dependências de destino serão rebaixados para avisos.
--[no]desugar_for_androidpadrão: "true"-
Define se o bytecode Java 8 deve ser simplificado antes da conversão para DEX.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state --[no]desugar_java8_libspadrão: "false"-
Se as bibliotecas Java 8 compatíveis devem ser incluídas em apps para dispositivos legados.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --[no]enforce_constraintspadrão: "true"-
Verifica os ambientes com que cada destino é compatível e informa erros se algum destino tiver dependências que não oferecem suporte aos mesmos ambientes.
Tags:
build_file_semantics --[no]experimental_check_desugar_depspadrão: "true"-
Se é necessário verificar novamente a dessugarização correta no nível binário do Android.
--[no]experimental_enforce_transitive_visibilitypadrão: "false"-
Se verdadeiro, permite que package()s definam o atributo transitive_visibility para restringir quais pacotes podem depender deles.
Tags:
build_file_semantics,experimental --experimental_one_version_enforcement=<off, warning or error>padrão: "OFF"-
Quando ativada, essa opção exige que uma regra java_binary não contenha mais de uma versão do mesmo arquivo de classe no classpath. Essa aplicação pode interromper o build ou apenas resultar em avisos.
Tags:
loading_and_analysis --experimental_strict_java_deps=<off, warn, error, strict or default>padrão: "default"-
Se for verdadeiro, verifica se um destino Java declara explicitamente todos os destinos usados diretamente como dependências.
--[no]incompatible_check_testonly_for_output_filespadrão: "false"-
Se ativado, verifique testonly para destinos de pré-requisito que são arquivos de saída pesquisando o testonly da regra geradora. Isso corresponde à verificação de visibilidade.
--[no]incompatible_disable_native_android_rulespadrão: "false"-
Se ativada, o uso direto das regras nativas do Android será desativado. Use as regras do Starlark Android em https://github.com/bazelbuild/rules_android
--[no]incompatible_disable_native_apple_binary_rulepadrão: "false"-
Não faz nada. Mantido aqui para compatibilidade com versões anteriores.
--[no]one_version_enforcement_on_java_testspadrão: "true"-
Quando ativada e com experimental_one_version_enforcement definido como um valor diferente de NONE, impõe uma versão em destinos java_test. Essa flag pode ser desativada para melhorar a performance do teste incremental, mas isso pode fazer com que possíveis violações de uma versão sejam perdidas.
Tags:
loading_and_analysis --python_native_rules_allowlist=<a build target label>padrão: consulte a descrição-
Uma lista de permissões (destino package_group) a ser usada ao aplicar --incompatible_python_disallow_native_rules.
Tags:
loading_and_analysis --[no]strict_filesetspadrão: "false"-
Se essa opção estiver ativada, os conjuntos de arquivos que cruzam os limites do pacote serão informados como erros.
--strict_proto_deps=<off, warn, error, strict or default>padrão: "error"-
A menos que esteja OFF, verifica se um destino proto_library declara explicitamente todos os destinos usados diretamente como dependências.
Tags:
build_file_semantics,eagerness_to_exit,incompatible_change --strict_public_imports=<off, warn, error, strict or default>padrão: "off"-
A menos que esteja OFF, verifica se um destino proto_library declara explicitamente como exportados todos os destinos usados em "import public".
Tags:
build_file_semantics,eagerness_to_exit,incompatible_change --[no]strict_system_includespadrão: "false"-
Se for "true", os cabeçalhos encontrados por caminhos de inclusão do sistema (-isystem) também precisarão ser declarados.
--target_environment=<a build target label>vários usos são acumulados-
Declara o ambiente de destino deste build. Precisa ser uma referência de rótulo a uma regra de "ambiente". Se especificado, todos os destinos de nível superior precisam ser compatíveis com esse ambiente.
Tags:
changes_inputs
- Opções que afetam as saídas de assinatura de um build:
--apk_signing_method=<v1, v2, v1_v2 or v4>padrão: "v1_v2"-
Implementação a ser usada para assinar APKs
Tags:
action_command_lines,affects_outputs,loading_and_analysis --[no]device_debug_entitlementspadrão: "true"-
Se definido e o modo de compilação não for "opt", os apps objc vão incluir direitos de depuração ao assinar.
Tags:
changes_inputs --ios_signing_cert_name=<a string>padrão: consulte a descrição-
Nome do certificado a ser usado para assinatura do iOS. Se não for definido, vai voltar ao perfil de provisionamento. Pode ser a preferência de identidade do chaveiro do certificado ou (substring) do nome comum do certificado, conforme a página de manual do codesign (IDENTIDADES DE ASSINATURA).
Tags:
action_command_lines
- Essa opção afeta a semântica da linguagem Starlark ou a API de build acessível a arquivos BUILD, .bzl ou WORKSPACE.:
--[no]incompatible_disallow_sdk_frameworks_attributespadrão: "false"-
Se for "true", não permita os atributos sdk_frameworks e weak_sdk_frameworks em objc_library e objc_import.
--[no]incompatible_objc_alwayslink_by_defaultpadrão: "false"-
Se for verdadeiro, defina o valor padrão como verdadeiro para atributos alwayslink em objc_library e objc_import.
--[no]incompatible_python_disallow_native_rulespadrão: "false"-
Quando verdadeiro, um erro ocorre ao usar as regras py_* integradas. Em vez disso, as regras rule_python devem ser usadas. Consulte https://github.com/bazelbuild/bazel/issues/17773 para mais informações e instruções de migração.
- Opções que regem o comportamento do ambiente de teste ou do executor de testes:
--[no]allow_analysis_failurespadrão: "false"-
Se for "true", uma falha na análise de um destino de regra vai resultar na propagação de uma instância de "AnalysisFailureInfo" contendo a descrição do erro, em vez de resultar em uma falha de build.
Tags:
loading_and_analysis,experimental - Padrão de
--analysis_testing_deps_limit=<an integer>: "2000" -
Define o número máximo de dependências transitivas usando um atributo de regra com uma transição de configuração for_analysis_testing. Exceder esse limite vai resultar em um erro de regra.
Tags:
loading_and_analysis --[no]break_build_on_parallel_dex2oat_failurepadrão: "false"-
Se for "true", as falhas na ação dex2oat vão interromper o build em vez de executar dex2oat durante o tempo de execução do teste.
Tags:
loading_and_analysis,experimental --default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100>vários usos são acumulados-
Substitua a quantidade padrão de recursos para testes. O formato esperado é <resource>=<value>. Se um único número positivo for especificado como <value>, ele vai substituir os recursos padrão para todos os tamanhos de teste. Se quatro números separados por vírgulas forem especificados, eles vão substituir a quantidade de recursos para os tamanhos de teste pequeno, médio, grande e enorme, respectivamente. Os valores também podem ser HOST_RAM/HOST_CPU, seguidos opcionalmente por [-|]<float> (por exemplo, memory=HOST_RAM.1,HOST_RAM*.2,HOST_RAM*.3,HOST_RAM*.4). Os recursos de teste padrão especificados por essa flag são substituídos por recursos explícitos especificados em tags.
--[no]experimental_android_use_parallel_dex2oatpadrão: "false"-
Use dex2oat em paralelo para acelerar o android_test.
Tags:
loading_and_analysis,host_machine_resource_optimizations,experimental --[no]ios_memleakspadrão: "false"-
Ativa a verificação de vazamentos de memória em destinos ios_test.
Tags:
action_command_lines --ios_simulator_device=<a string>padrão: consulte a descrição-
O dispositivo a ser simulado ao executar um aplicativo iOS no simulador, por exemplo, "iPhone 6". Para conferir uma lista de dispositivos, execute "xcrun simctl list devicetypes" na máquina em que o simulador será executado.
Tags:
test_runner --ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
A versão do iOS a ser executada no simulador durante a execução ou o teste. Isso é ignorado para regras ios_test se um dispositivo de destino for especificado na regra.
Tags:
test_runner --runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once>vários usos são acumulados-
Especifica o número de vezes que cada teste será executado. Se alguma dessas tentativas falhar por qualquer motivo, todo o teste será considerado falho. Normalmente, o valor especificado é apenas um número inteiro. Exemplo: --runs_per_test=3 vai executar todos os testes três vezes. Sintaxe alternativa: regex_filter@runs_per_test. Em que runs_per_test representa um valor inteiro e regex_filter representa uma lista de padrões de expressões regulares de inclusão e exclusão (consulte também --instrumentation_filter). Exemplo: --runs_per_test=//foo/.,-//foo/bar/.@3 executa todos os testes em //foo/, exceto aqueles em foo/bar, três vezes. Essa opção pode ser transmitida várias vezes. O argumento transmitido mais recentemente que corresponde tem precedência. Se nada corresponder, o teste será executado apenas uma vez.
--test_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable>vários usos são acumulados-
Especifica outras variáveis de ambiente a serem injetadas no ambiente do executor de testes. As variáveis podem ser especificadas por <code>name</code>, nesse caso, o valor será lido do ambiente do cliente Bazel, ou pelo par <code>name=value</code>. As variáveis definidas anteriormente podem ser desdefinidas usando <code>=name</code>. Essa opção pode ser usada várias vezes para especificar várias variáveis. Usado apenas pelo comando "bazel test".
Tags:
test_runner --test_timeout=<a single integer or comma-separated list of 4 integers>padrão: "-1"-
Substitui os valores padrão de tempo limite de teste para tempos limite de teste (em segundos). Se um único valor inteiro positivo for especificado, ele vai substituir todas as categorias. Se quatro números inteiros separados por vírgulas forem especificados, eles vão substituir os tempos limite para curto, moderado, longo e eterno (nessa ordem). Em qualquer uma das formas, um valor de -1 informa ao Blaze para usar os tempos limite padrão para essa categoria.
--[no]zip_undeclared_test_outputspadrão: "false"-
Se for "true", as saídas de teste não declaradas serão arquivadas em um arquivo ZIP.
Tags:
test_runner
- Opções que acionam otimizações do tempo de build:
--[no]experimental_filter_library_jar_with_program_jarpadrão: "false"-
Filtre o ProGuard ProgramJar para remover todas as classes também presentes no LibraryJar.
Tags:
action_command_lines,experimental --[no]experimental_inmemory_dotd_filespadrão: "true"-
Se ativada, os arquivos .d do C++ serão transmitidos na memória diretamente dos nós de build remoto em vez de serem gravados em disco.
Tags:
loading_and_analysis,execution,affects_outputs,experimental --[no]experimental_inmemory_jdeps_filespadrão: "true"-
Se ativada, os arquivos de dependência (.jdeps) gerados de compilações Java serão transmitidos na memória diretamente dos nós de build remoto em vez de serem gravados no disco.
Tags:
loading_and_analysis,execution,affects_outputs,experimental --[no]experimental_retain_test_configuration_across_testonlypadrão: "false"-
Quando ativada, a flag --trim_test_configuration não vai remover a configuração de teste para regras marcadas como testonly=1. Isso reduz problemas de conflito de ações quando regras que não são de teste dependem de regras cc_test. Não tem efeito se "--trim_test_configuration" for "false".
Tags:
loading_and_analysis,loses_incremental_state,experimental --[no]experimental_unsupported_and_brittle_include_scanningpadrão: "false"-
Indica se é necessário restringir as entradas à compilação em C/C++ analisando as linhas #include dos arquivos de entrada. Isso pode melhorar a performance e a incrementalidade, diminuindo o tamanho das árvores de entrada de compilação. No entanto, ele também pode interromper builds porque o scanner de inclusão não implementa totalmente a semântica do pré-processador C. Em particular, ele não entende diretivas #include dinâmicas e ignora a lógica condicional do pré-processador. Use por sua conta e risco. Todos os problemas relacionados a essa denúncia que forem enviados serão encerrados.
Tags:
loading_and_analysis,execution,changes_inputs,experimental --[no]incremental_dexingpadrão: "true"-
Faz a maior parte do trabalho de dexing separadamente para cada arquivo Jar.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state --[no]objc_use_dotd_pruningpadrão: "true"-
Se definido, os arquivos .d emitidos pelo clang serão usados para remover o conjunto de entradas transmitidas para compilações objc.
--[no]process_headers_in_dependenciespadrão: "false"-
Ao criar um destino //a:a, processe os cabeçalhos em todos os destinos de que //a:a depende (se o processamento de cabeçalho estiver ativado para a cadeia de ferramentas).
Tags:
execution --[no]trim_test_configurationpadrão: "true"-
Quando ativada, as opções relacionadas a testes serão limpas abaixo do nível superior do build. Quando essa flag está ativa, os testes não podem ser criados como dependências de regras que não são de teste, mas as mudanças nas opções relacionadas a testes não fazem com que as regras que não são de teste sejam analisadas novamente.
- Opções que afetam a verbosidade, o formato ou o local do registro em log:
- Padrão de
--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>: "-.*" -
Imprime informações de depuração durante a resolução da cadeia de ferramentas. A flag usa uma regex, que é verificada em relação a tipos de cadeia de ferramentas e destinos específicos para ver qual depurar. É possível separar várias expressões regulares com vírgulas, e cada uma delas é verificada separadamente. Observação: a saída dessa flag é muito complexa e provavelmente só será útil para especialistas em resolução de toolchain.
Tags:
terminal_output --[no]verbose_visibility_errorspadrão: "false"-
Se ativados, os erros de visibilidade incluem mais informações de diagnóstico.
- Opções que especificam ou alteram uma entrada genérica para um comando do Bazel que não se enquadra em outras categorias:
--flag_alias=<a 'name=value' flag alias>vários usos são acumulados-
Define um nome abreviado para uma flag do Starlark. Ele usa um único par de chave-valor no formato "<chave>=<valor>" como argumento.
Tags:
changes_inputs,non_configurable --[no]incompatible_default_to_explicit_init_pypadrão: "false"-
Essa flag muda o comportamento padrão para que os arquivos init.py não sejam mais criados automaticamente nos arquivos de execução de destinos Python. Precisamente, quando um destino py_binary ou py_test tem legacy_create_init definido como "auto" (o padrão), ele é tratado como falso se e somente se essa flag estiver definida. Consulte https://github.com/bazelbuild/bazel/issues/10076.
- Opções diversas, não categorizadas de outra forma:
--[no]cache_test_results[-t] padrão: "auto"-
Se definido como "auto", o Bazel vai executar novamente um teste somente se: (1) o Bazel detectar mudanças no teste ou nas dependências dele, (2) o teste for marcado como externo, (3) várias execuções de teste forem solicitadas com --runs_per_test ou(4) o teste falhou anteriormente. Se definido como "yes", o Bazel armazena em cache todos os resultados de testes, exceto aqueles marcados como externos. Se definido como "no", o Bazel não armazena em cache nenhum resultado de teste.
- Padrão de
--[no]experimental_cancel_concurrent_tests: "never" -
Se for "on_failed" ou "on_passed", o Blaze vai cancelar os testes em execução simultânea na primeira execução com esse resultado. Isso só é útil em combinação com --runs_per_test_detects_flakes.
--[no]experimental_fetch_all_coverage_outputspadrão: "false"-
Se for verdadeiro, o Bazel vai buscar todo o diretório de dados de cobertura para cada teste durante uma execução de cobertura.
--[no]experimental_generate_llvm_lcovpadrão: "false"-
Se for verdadeiro, a cobertura do clang vai gerar um relatório LCOV.
- Padrão de
--experimental_java_classpath=<off, javabuilder, bazel or bazel_no_fallback>: "bazel" -
Ativa caminhos de classe reduzidos para compilações Java.
--[no]experimental_run_android_lint_on_java_rulespadrão: "false"-
Se as fontes java_* precisam ser validadas.
Tags:
affects_outputs,experimental --[no]explicit_java_test_depspadrão: "false"-
Especifique explicitamente uma dependência do JUnit ou do Hamcrest em um java_test em vez de obter acidentalmente das dependências do TestRunner. No momento, só funciona para bazel.
--host_java_launcher=<a build target label>padrão: consulte a descrição-
O iniciador Java usado por ferramentas executadas durante um build.
--host_javacopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas para o javac ao criar ferramentas executadas durante um build.
--host_jvmopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas para a VM Java ao criar ferramentas executadas durante o build. Essas opções serão adicionadas às opções de inicialização da VM de cada destino java_binary.
--[no]incompatible_check_sharding_supportpadrão: "true"-
Se for verdadeiro, o Bazel vai falhar em um teste fragmentado se o executor de testes não indicar que oferece suporte à fragmentação ao tocar no arquivo no caminho em TEST_SHARD_STATUS_FILE. Se for "false", um executor de testes que não oferece suporte a fragmentação vai fazer com que todos os testes sejam executados em cada fragmento.
Tags:
incompatible_change --[no]incompatible_exclusive_test_sandboxedpadrão: "true"-
Se for verdadeiro, os testes exclusivos serão executados com a estratégia em sandbox. Adicione a tag "local" para forçar uma execução de teste exclusiva localmente
Tags:
incompatible_change --[no]incompatible_strict_action_envpadrão: "false"-
Se for "true", o Bazel usará um ambiente com um valor estático para PATH e não vai herdar LD_LIBRARY_PATH. Use --action_env=ENV_VARIABLE se quiser herdar variáveis de ambiente específicas do cliente, mas observe que isso pode impedir o armazenamento em cache entre usuários se um cache compartilhado for usado.
--j2objc_translation_flags=<comma-separated list of options>vários usos são acumulados-
Outras opções a serem transmitidas para a ferramenta J2ObjC.
--java_debug-
Faz com que a máquina virtual Java de um teste Java aguarde uma conexão de um depurador compatível com JDWP (como jdb) antes de iniciar o teste. Implica -test_output=streamed.
Expande para:
--test_arg=--wrapper_script_flag=--debug
--test_output=streamed
--test_strategy=exclusive
--test_timeout=9999
--nocache_test_results --[no]java_depspadrão: "true"-
Gere informações de dependência (por enquanto, classpath de tempo de compilação) por destino Java.
--[no]java_header_compilationpadrão: "true"-
Compile ijars diretamente da origem.
--java_language_version=<a string>padrão: ""-
A versão da linguagem Java
--java_launcher=<a build target label>padrão: consulte a descrição-
O inicializador Java a ser usado ao criar binários Java. Se essa flag for definida como uma string vazia, o iniciador do JDK será usado. O atributo "launcher" substitui essa flag.
- Padrão de
--java_runtime_version=<a string>: "local_jdk" -
A versão do ambiente de execução do Java
--javacopt=<a string>vários usos são acumulados-
Outras opções para transmitir ao javac.
--jvmopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas para a VM Java. Essas opções serão adicionadas às opções de inicialização da VM de cada destino java_binary.
--legacy_main_dex_list_generator=<a build target label>padrão: consulte a descrição-
Especifica um binário a ser usado para gerar a lista de classes que precisam estar no dex principal ao compilar o multidex legado.
--optimizing_dexer=<a build target label>padrão: consulte a descrição-
Especifica um binário a ser usado para fazer dexing sem sharding.
--plugin=<a build target label>vários usos são acumulados-
Plug-ins a serem usados no build. No momento, funciona com java_plugin.
--proguard_top=<a build target label>padrão: consulte a descrição-
Especifica qual versão do ProGuard usar para remoção de código ao criar um binário Java.
--proto_compiler=<a build target label>default: "@bazel_tools//tools/proto:protoc"-
O rótulo do proto-compilador.
--[no]proto_profilepadrão: "true"-
Se o profile_path será transmitido ao compilador proto.
--proto_profile_path=<a build target label>padrão: consulte a descrição-
O perfil a ser transmitido ao compilador proto como profile_path. Se não for definido, mas --proto_profile for verdadeiro (o padrão), vai inferir o caminho de --fdo_optimize.
--proto_toolchain_for_cc=<a build target label>default: "@bazel_tools//tools/proto:cc_toolchain"-
Rótulo de proto_lang_toolchain() que descreve como compilar protos C++
--proto_toolchain_for_j2objc=<a build target label>padrão: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain"-
Rótulo de proto_lang_toolchain() que descreve como compilar protos j2objc.
--proto_toolchain_for_java=<a build target label>default: "@bazel_tools//tools/proto:java_toolchain"-
Rótulo de proto_lang_toolchain() que descreve como compilar protos Java.
--proto_toolchain_for_javalite=<a build target label>default: "@bazel_tools//tools/proto:javalite_toolchain"-
Rótulo de proto_lang_toolchain() que descreve como compilar protos do JavaLite.
--protocopt=<a string>vários usos são acumulados-
Outras opções para transmitir ao compilador protobuf.
Tags:
affects_outputs --[no]runs_per_test_detects_flakespadrão: "false"-
Se for "true", qualquer fragmento em que pelo menos uma execução/tentativa seja aprovada e pelo menos uma execução/tentativa falhe vai receber o status "FLAKY".
--shell_executable=<a path>padrão: consulte a descrição-
Caminho absoluto para o executável do shell que o Bazel vai usar. Se não estiver definido, mas a variável de ambiente BAZEL_SH estiver definida na primeira invocação do Bazel (que inicia um servidor do Bazel), o Bazel vai usar essa variável. Se nenhum dos dois estiver definido, o Bazel usará um caminho padrão codificado, dependendo do sistema operacional em que ele é executado (Windows: c:/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, todos os outros: /bin/bash). Usar um shell incompatível com bash pode causar falhas de build ou de tempo de execução dos binários gerados.
Tags:
loading_and_analysis --test_arg=<a string>vários usos são acumulados-
Especifica outras opções e argumentos que devem ser transmitidos para o executável de teste. Pode ser usado várias vezes para especificar vários argumentos. Se vários testes forem executados, cada um deles vai receber argumentos idênticos. Usado apenas pelo comando "bazel test".
--test_filter=<a string>padrão: consulte a descrição-
Especifica um filtro para encaminhar ao framework de teste. Usado para limitar os testes executados. Isso não afeta quais destinos são criados.
--test_result_expiration=<an integer>padrão: "-1"-
Essa opção foi descontinuada e não tem efeito.
--[no]test_runner_fail_fastpadrão: "false"-
Encaminha a opção de falha rápida para o executor de testes. O executor de testes precisa interromper a execução na primeira falha.
--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce>padrão: "explicit"-
Especifique a estratégia para o sharding de teste: "explicit" para usar o sharding somente se o atributo "shard_count" BUILD estiver presente. "disabled" para nunca usar o sharding de teste. "forced=k" para forçar "k" fragmentos para teste, independente do atributo "shard_count" BUILD.
--tool_java_language_version=<a string>padrão: ""-
A versão da linguagem Java usada para executar as ferramentas necessárias durante um build.
--tool_java_runtime_version=<a string>padrão: "remotejdk_11"-
A versão do ambiente de execução Java usada para executar ferramentas durante o build.
--[no]use_ijarspadrão: "true"-
Se ativada, essa opção faz com que a compilação Java use jars de interface. Isso resulta em uma compilação incremental mais rápida, mas as mensagens de erro podem ser diferentes.
Opções de ajuda
- Opções que afetam a verbosidade, o formato ou o local do registro em log:
- Padrão de
--help_verbosity=<long, medium or short>: "medium" -
Selecione o nível de detalhe do comando de ajuda.
Tags:
terminal_output --long[-l]-
Mostrar a descrição completa de cada opção, em vez de apenas o nome.
Expande para:
--help_verbosity=longTags:
terminal_output --short-
Mostre apenas os nomes das opções, não os tipos ou significados.
Expande para:
--help_verbosity=shortTags:
terminal_output
Opções de informações
Herda todas as opções de build.
- Opções que permitem ao usuário configurar a saída pretendida, afetando o valor dela, e não a existência:
--info_output_type=<stdout or response_proto>padrão: "stdout"-
Se for stdout, os resultados serão impressos diretamente no console. Se response_proto, os resultados do comando info serão agrupados em extensões de resposta.
Tags:
affects_outputs,terminal_output
- Opções que afetam a verbosidade, o formato ou o local do registro em log:
--[no]show_make_envpadrão: "false"-
Inclua o ambiente "Make" na saída.
Tags:
affects_outputs,terminal_output
Opções de licença
Opções de instalação em dispositivos móveis
Herda todas as opções de build.
- Opções que controlam a execução do build:
- Padrão de
--mode=<classic, classic_internal_test_do_not_use or skylark>: "skylark" -
Sinalização sem efeito descontinuada. Apenas o modo Skylark ainda é compatível.
- Opções que configuram o conjunto de ferramentas usado para a execução de ações:
--adb=<a string>padrão: ""-
Binário adb a ser usado para o comando "mobile-install". Se não for especificado, será usado o SDK do Android especificado pela opção de linha de comando --android_sdk_channel ou o SDK padrão se --android_sdk_channel não for especificado.
Tags:
changes_inputs
- Opções que controlam a saída do comando:
--[no]incrementalpadrão: "false"-
Se uma instalação incremental deve ser feita. Se for verdadeiro, evite trabalho extra desnecessário lendo o estado do dispositivo em que o código será instalado e usando essas informações para evitar trabalho desnecessário. Se for "false" (o padrão), sempre faça uma instalação completa.
Tags:
loading_and_analysis --[no]split_apkspadrão: "false"-
Se é necessário usar APKs divididos para instalar e atualizar o aplicativo no dispositivo. Funciona apenas com dispositivos Marshmallow ou mais recentes
- Opções que permitem ao usuário configurar a saída pretendida, afetando o valor dela, e não a existência:
--adb_arg=<a string>vários usos são acumulados-
Argumentos extras a serem transmitidos para o adb. Geralmente usado para designar um dispositivo para instalação.
Tags:
action_command_lines --debug_app-
Se é necessário aguardar o depurador antes de iniciar o app.
Expande para:
--start=DEBUGTags:
execution --device=<a string>padrão: ""-
O número de série do dispositivo adb. Se não for especificado, o primeiro dispositivo será usado.
Tags:
action_command_lines --start=<no, cold, warm or debug>padrão: "NO"-
Como o app deve ser iniciado após a instalação. Defina como WARM para preservar e restaurar o estado do aplicativo em instalações incrementais.
Tags:
execution --start_app-
Se o app deve ser iniciado após a instalação.
Expande para:
--start=COLDTags:
execution
- Opções que afetam a verbosidade, o formato ou o local do registro em log:
--incremental_install_verbosity=<a string>padrão: ""-
O nível de detalhamento para instalação incremental. Defina como 1 para geração de registros de depuração.
Tags:
bazel_monitoring
Opções de mod
- Opções que controlam a execução do build:
--[no]experimental_remotable_source_manifestspadrão: "false"-
Se as ações do manifesto de origem podem ser executadas remotamente
--[no]experimental_strict_fileset_outputpadrão: "false"-
Se essa opção estiver ativada, os conjuntos de arquivos vão tratar todos os artefatos de saída como arquivos regulares. Eles não vão percorrer diretórios nem serão sensíveis a symlinks.
Tags:
execution,experimental --[no]incompatible_modify_execution_info_additivepadrão: "true"-
Quando ativada, a transmissão de várias flags --modify_execution_info é cumulativa. Quando desativada, apenas a última flag é considerada.
Tags:
execution,affects_outputs,loading_and_analysis,incompatible_change --loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">padrão: "auto"-
Número de linhas de execução paralelas a serem usadas na fase de carregamento/análise. Recebe um número inteiro ou uma palavra-chave ("auto", "HOST_CPUS", "HOST_RAM"), opcionalmente seguida por uma operação ([-|]<float>), por exemplo, "auto", "HOST_CPUS.5". "auto" define um padrão razoável com base nos recursos do host. Precisa ser pelo menos 1.
--modify_execution_info=<regex=[+-]key,regex=[+-]key,...>vários usos são acumulados-
Adicione ou remova chaves das informações de execução de uma ação com base no mnemônico dela. Aplicável apenas a ações que oferecem suporte a informações de execução. Muitas ações comuns oferecem suporte a informações de execução, por exemplo, Genrule, CppCompile, Javac, StarlarkAction e TestRunner. Ao especificar vários valores, a ordem é importante porque muitas expressões regulares podem ser aplicadas ao mesmo mnemônico.
Sintaxe: "regex=[+-]key,regex=[+-]key,...".
Exemplos: '.=+x,.=-y,.=+z' adiciona "x" e "z" e remove "y" das informações de execução de todas as ações. "Genrule=+requires-x" adiciona "requires-x" às informações de execução de todas as ações Genrule. '(?!Genrule).=-requires-x' remove 'requires-x' das informações de execução de todas as ações que não são Genrule.
--[no]use_target_platform_for_testspadrão: "false"-
Se for "true", use a plataforma de destino para executar testes em vez do grupo de execução de teste.
Tags:
execution
- Opções que configuram o conjunto de ferramentas usado para a execução de ações:
--[no]incompatible_bazel_test_exec_run_underpadrão: "true"-
Se ativado, "bazel test --run_under=//:runner" vai criar "//:runner" na configuração de execução. Se estiver desativado, ele vai criar "//:runner" na configuração de destino. O Bazel executa testes em máquinas de execução, então o primeiro é mais correto. Isso não afeta "bazel run", que sempre cria "`--run_under=//foo" na configuração de destino.
- Opções que controlam a saída do comando:
--[no]build_runfile_linkspadrão: "true"-
Se for verdadeiro, vai criar florestas de symlink de runfiles para todos os destinos. Se for "false", grave-os apenas quando exigido por uma ação, teste ou comando de execução local.
Tags:
affects_outputs --[no]build_runfile_manifestspadrão: "true"-
Se verdadeiro, grava manifestos de runfiles para todos os destinos. Se for "false", omita-os. Os testes locais não serão executados quando for "false".
Tags:
affects_outputs --[no]incompatible_always_include_files_in_datapadrão: "true"-
Se for verdadeiro, as regras nativas vão adicionar <code>DefaultInfo.files</code> de dependências de dados aos runfiles, o que corresponde ao comportamento recomendado para regras do Starlark (https://bazel.build/extending/rules#runfiles_features_to_avoid).
--[no]incompatible_compact_repo_mapping_manifestpadrão: "false"-
Se ativado, o arquivo <binary>.repo_mapping vai emitir o mapeamento de repositório de uma extensão de módulo apenas uma vez, em vez de uma vez para cada repositório gerado pela extensão que contribui com runfiles.
--incompatible_disable_select_on=<comma-separated set of options>padrão: ""-
Lista de flags para as quais o uso em select() está desativado.
Tags:
loading_and_analysis,incompatible_change,non_configurable --[no]incompatible_filegroup_runfiles_for_datapadrão: "true"-
Se for verdadeiro, os runfiles dos destinos listados no atributo "srcs" estarão disponíveis para os destinos que consomem o filegroup como uma dependência de dados.
Tags:
incompatible_change
- Opções que permitem ao usuário configurar a saída pretendida, afetando o valor dela, e não a existência:
--action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable>vários usos são acumulados-
Especifica o conjunto de variáveis de ambiente disponíveis para ações com configuração de destino. As variáveis podem ser especificadas por <code>name</code>, em que o valor é extraído do ambiente de invocação, pelo par <code>name=value</code>, que define o valor independente do ambiente de invocação, ou por <code>=name</code>, que desativa a variável com esse nome. Essa opção pode ser usada várias vezes. Para opções fornecidas para a mesma variável, a mais recente vence. Para variáveis diferentes, as opções são acumuladas. <br> A menos que <code>--incompatible_repo_env_ignores_action_env</code> seja verdadeiro, todos os pares <code>name=value</code> estarão disponíveis para as regras do repositório.
Tags:
action_command_lines --allowed_cpu_values=<comma-separated set of options>padrão: ""-
Valores permitidos para a flag "--cpu".
Tags:
changes_inputs,affects_outputs --[no]collect_code_coveragepadrão: "false"-
Se especificado, o Bazel vai instrumentar o código (usando instrumentação off-line sempre que possível) e coletar informações de cobertura durante os testes. Apenas os destinos que correspondem a --instrumentation_filter serão afetados. Normalmente, essa opção não deve ser especificada diretamente. Em vez disso, use o comando "bazel coverage".
Tags:
affects_outputs --compilation_mode=<fastbuild, dbg or opt>[-c] padrão: "fastbuild"-
Especifique o modo em que o binário será criado. Valores: "fastbuild", "dbg", "opt".
--cpu=<a string>padrão: ""-
Descontinuada: essa flag não é usada internamente pelo Blaze, embora haja mapeamentos de plataforma legados para permitir a compatibilidade com versões anteriores. Não use essa flag. Em vez disso, use --platforms com uma definição de plataforma adequada.
Tags:
changes_inputs,affects_outputs --define=<a 'name=value' assignment>vários usos são acumulados-
Cada opção "--define" especifica uma atribuição para uma variável de build. Em caso de vários valores para uma variável, o último vence.
Tags:
changes_inputs,affects_outputs --[no]enable_runfilespadrão: "auto"-
Ative a árvore de symlink de runfiles. Por padrão, ela fica desativada no Windows e ativada em outras plataformas.
Tags:
affects_outputs --exec_aspects=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de aspectos a serem aplicados a destinos configurados por execução, sejam eles de nível superior ou não. Este é um recurso experimental e está sujeito a mudanças.
Tags:
loading_and_analysis --experimental_action_listener=<a build target label>vários usos são acumulados-
Obsoleto, substituído por "aspectos". Use action_listener para anexar uma extra_action a ações de build atuais.
Tags:
execution,experimental --[no]experimental_collect_code_coverage_for_generated_filespadrão: "false"-
Se especificado, o Bazel também vai gerar informações de cobertura de coleta para arquivos gerados.
Tags:
affects_outputs,experimental --experimental_output_paths=<off or strip>padrão: "off"-
Qual modelo usar para onde as regras da árvore de saída gravam as saídas, principalmente para builds multiplataforma / multiconfiguração. Esse recurso é altamente experimental. Consulte https://github.com/bazelbuild/bazel/issues/6526 para mais detalhes. As ações do Starlark podem ativar o mapeamento de caminhos adicionando a chave "supports-path-mapping" ao dicionário "execution_requirements".
Tags:
loses_incremental_state,bazel_internal_configuration,affects_outputs,execution --experimental_override_platform_cpu_name=<a 'label=value' assignment>vários usos são acumulados-
Cada entrada precisa estar no formato "label=value", em que "label" se refere a uma plataforma e "value" é o nome abreviado desejado para substituir o nome da CPU da plataforma na variável de make $(TARGET_CPU) e no caminho de saída. Usado somente quando --experimental_platform_in_output_dir, --incompatible_target_cpu_from_platform ou --incompatible_bep_cpu_from_platform é verdadeiro. Tem a maior prioridade de nomenclatura.
Tags:
affects_outputs,experimental --[no]experimental_platform_in_output_dirpadrão: "false"-
Se for "true", um nome abreviado para a plataforma de destino será usado no nome do diretório de saída em vez da CPU. Se for "auto", isso só será aplicado à configuração de execução. O esquema exato é experimental e está sujeito a mudanças. Primeiro, no caso raro em que a opção "--platforms" não tem exatamente um valor, um hash da opção "platforms" é usado. Em seguida, se um nome abreviado para a plataforma atual foi registrado por --experimental_override_name_platform_in_output_dir, esse nome abreviado será usado. Em seguida, se --experimental_use_platforms_in_output_dir_legacy_heuristic estiver definido, use um nome abreviado com base no rótulo da plataforma atual. Por fim, um hash da opção de plataforma é usado como último recurso.
Tags:
affects_outputs,experimental --[no]experimental_use_platforms_in_output_dir_legacy_heuristicpadrão: "true"-
Use essa flag apenas como parte de uma estratégia de migração ou teste sugerida. A heurística tem deficiências conhecidas. Por isso, recomendamos migrar para usar apenas --experimental_override_name_platform_in_output_dir.
Tags:
affects_outputs,experimental --features=<a string>vários usos são acumulados-
Os recursos especificados serão ativados ou desativados por padrão para destinos criados na configuração de destino. Especificar -<recurso> desativa o recurso. Recursos negativos sempre substituem os positivos. Consulte também --host_features
Tags:
changes_inputs,affects_outputs --host_action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable>vários usos são acumulados-
Especifica o conjunto de variáveis de ambiente disponíveis para ações com configurações de execução. As variáveis podem ser especificadas por nome, caso em que o valor será extraído do ambiente de invocação, pelo par nome=valor, que define o valor independente do ambiente de invocação, ou por <code>=name</code>, que desativa a variável desse nome. Essa opção pode ser usada várias vezes. Para opções fornecidas para a mesma variável, a mais recente vence. Para variáveis diferentes, as opções são acumuladas.
Tags:
action_command_lines --host_compilation_mode=<fastbuild, dbg or opt>padrão: "opt"-
Especifique o modo em que as ferramentas usadas durante a criação serão criadas. Valores: "fastbuild", "dbg", "opt".
--host_cpu=<a string>padrão: ""-
A CPU do host.
Tags:
changes_inputs,affects_outputs --host_features=<a string>vários usos são acumulados-
Os recursos especificados serão ativados ou desativados por padrão para destinos criados na configuração de execução. Especificar -<recurso> desativa o recurso. Recursos negativos sempre substituem os positivos.
Tags:
changes_inputs,affects_outputs --[no]incompatible_auto_exec_groupspadrão: "false"-
Quando ativado, um grupo de execução é criado automaticamente para cada cadeia de ferramentas usada por uma regra. Para que isso funcione, a regra precisa especificar o parâmetro
toolchainnas ações dela. Para mais informações, consulte https://github.com/bazelbuild/bazel/issues/17134. --[no]incompatible_merge_genfiles_directorypadrão: "true"-
Se for verdadeiro, o diretório "genfiles" será incorporado ao diretório "bin".
--[no]incompatible_target_cpu_from_platformpadrão: "true"-
Se especificado, o valor da restrição de CPU (@platforms//cpu:cpu) da plataforma de destino será usado para definir a variável de criação $(TARGET_CPU).
--[no]instrument_test_targetspadrão: "false"-
Quando a cobertura está ativada, especifica se as regras de teste de instrumentação devem ser consideradas. Quando definido, as regras de teste incluídas por --instrumentation_filter são instrumentadas. Caso contrário, as regras de teste são sempre excluídas da instrumentação de cobertura.
Tags:
affects_outputs --instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>padrão: "-/javatests[/:],-/test/java[/:]"-
Quando a cobertura está ativada, apenas as regras com nomes incluídos pelo filtro especificado baseado em regex são instrumentadas. As regras com o prefixo "-" são excluídas. Somente regras que não são de teste são instrumentadas, a menos que a flag --instrument_test_targets esteja ativada.
Tags:
affects_outputs --platform_suffix=<a string>padrão: consulte a descrição-
Especifica um sufixo a ser adicionado ao diretório de configuração.
Tags:
loses_incremental_state,affects_outputs,loading_and_analysis --run_under=<a prefix in front of command>padrão: consulte a descrição-
Prefixo a ser inserido antes dos executáveis dos comandos "test" e "run". Se o valor for "foo -bar" e a linha de comando de execução for "test_binary -baz", a linha de comando final será "foo -bar test_binary -baz".Isso também pode ser um rótulo para um destino executável. Alguns exemplos são: "valgrind", "strace", "strace -c", "valgrind --quiet --num-callers=20", "//package:target", "//package:target --options".
Tags:
action_command_lines --[no]stamppadrão: "false"-
Adicionar carimbo aos binários com a data, o nome de usuário, o nome do host, as informações do espaço de trabalho etc.
Tags:
affects_outputs
- Opções que afetam a rigidez com que o Bazel aplica entradas de build válidas (definições de regras, combinações de flags etc.):
--[no]check_visibilitypadrão: "true"-
Se desativado, os erros de visibilidade nas dependências de destino serão rebaixados para avisos.
--[no]enforce_constraintspadrão: "true"-
Verifica os ambientes com que cada destino é compatível e informa erros se algum destino tiver dependências que não oferecem suporte aos mesmos ambientes.
Tags:
build_file_semantics --[no]experimental_enforce_transitive_visibilitypadrão: "false"-
Se verdadeiro, permite que package()s definam o atributo transitive_visibility para restringir quais pacotes podem depender deles.
Tags:
build_file_semantics,experimental --[no]incompatible_check_testonly_for_output_filespadrão: "false"-
Se ativado, verifique testonly para destinos de pré-requisito que são arquivos de saída pesquisando o testonly da regra geradora. Isso corresponde à verificação de visibilidade.
--[no]strict_filesetspadrão: "false"-
Se essa opção estiver ativada, os conjuntos de arquivos que cruzam os limites do pacote serão informados como erros.
--target_environment=<a build target label>vários usos são acumulados-
Declara o ambiente de destino deste build. Precisa ser uma referência de rótulo a uma regra de "ambiente". Se especificado, todos os destinos de nível superior precisam ser compatíveis com esse ambiente.
Tags:
changes_inputs
- Essa opção afeta a semântica da linguagem Starlark ou a API de build acessível a arquivos BUILD, .bzl ou WORKSPACE.:
--[no]incompatible_config_setting_private_default_visibilitypadrão: "false"-
Se "incompatible_enforce_config_setting_visibility=false", isso não terá efeito. Caso contrário, se essa flag for "false", qualquer config_setting sem um atributo de visibilidade explícito será //visibility:public. Se essa flag for "true", "config_setting" vai seguir a mesma lógica de visibilidade de todas as outras regras. Consulte https://github.com/bazelbuild/bazel/issues/12933.
--[no]incompatible_enforce_config_setting_visibilitypadrão: "true"-
Se for "true", aplique as restrições de visibilidade de "config_setting". Se for "false", todas as config_setting serão visíveis para todos os destinos. Consulte https://github.com/bazelbuild/bazel/issues/12932.
- Opções que regem o comportamento do ambiente de teste ou do executor de testes:
--[no]allow_analysis_failurespadrão: "false"-
Se for "true", uma falha na análise de um destino de regra vai resultar na propagação de uma instância de "AnalysisFailureInfo" contendo a descrição do erro, em vez de resultar em uma falha de build.
Tags:
loading_and_analysis,experimental - Padrão de
--analysis_testing_deps_limit=<an integer>: "2000" -
Define o número máximo de dependências transitivas usando um atributo de regra com uma transição de configuração for_analysis_testing. Exceder esse limite vai resultar em um erro de regra.
Tags:
loading_and_analysis
- Opções relacionadas à saída e à semântica do subcomando "mod":
--base_module=<"<root>" for the root module; <module>@<version> for a specific version of a module; <module> for all versions of a module; @<name> for a repo with the given apparent name; or @@<name> for a repo with the given canonical name>padrão: "<root>"-
Especifique um módulo em relação ao qual os repositórios de destino especificados serão interpretados.
Tags:
terminal_output - Padrão de
--charset=<utf8 or ascii>: "utf8" -
Escolhe o conjunto de caracteres a ser usado na árvore. Isso só afeta a saída de texto. Os valores válidos são "utf8" ou "ascii". O padrão é "utf8".
Tags:
terminal_output --[no]cyclespadrão: "true"-
Aponta ciclos de dependência na árvore mostrada.
Tags:
terminal_output --depth=<an integer>padrão: "-1"-
Profundidade máxima de exibição da árvore de dependências. Uma profundidade de 1 mostra as dependências diretas, por exemplo. Para tree, path e all_paths, o padrão é Integer.MAX_VALUE. Para deps e explain, o padrão é 1 (mostra apenas as dependências diretas da raiz, além das folhas de destino e dos elementos pai delas).
Tags:
terminal_output --extension_filter=<a comma-separated list of <extension>s>padrão: consulte a descrição-
Só mostre os usos dessas extensões de módulo e os repositórios gerados por elas se as flags respectivas estiverem definidas. Se definido, o gráfico de resultados vai incluir apenas caminhos que contêm módulos usando as extensões especificadas. Uma lista vazia desativa o filtro, especificando todas as extensões possíveis.
Tags:
terminal_output - Padrão de
--extension_info=<hidden, usages, repos or all>: "hidden" -
Especifique o nível de detalhes sobre os usos da extensão que serão incluídos no resultado da consulta. "Usos" mostra apenas os nomes das extensões, "repos" também inclui repositórios importados com use_repo, e "all" também mostra os outros repositórios gerados por extensões.
Tags:
terminal_output --extension_usages=<a comma-separated list of <module>s>padrão: ""-
Especifique os módulos cujos usos de extensão serão mostrados na consulta show_extension.
Tags:
terminal_output --from=<a comma-separated list of <module>s>padrão: "<root>"-
Os módulos a partir dos quais a consulta do gráfico de dependências será exibida. Confira a descrição de cada consulta para saber a semântica exata. O padrão é <root>.
Tags:
terminal_output --[no]include_builtinpadrão: "false"-
Inclua módulos integrados no gráfico de dependências. Desativado por padrão porque é muito ruidoso.
Tags:
terminal_output --[no]include_unusedpadrão: "false"-
As consultas também vão considerar e mostrar os módulos não utilizados, que não estão presentes no gráfico de resolução de módulos após a seleção (devido à seleção de versão mínima ou às regras de substituição). Isso pode ter efeitos diferentes para cada um dos tipos de consulta, ou seja, incluir novos caminhos no comando "all_paths" ou dependentes extras no comando "explain".
Tags:
terminal_output --output=<text, json or graph>padrão: "text"-
O formato em que os resultados da consulta precisam ser impressos. Os valores permitidos para a consulta são: text, json, graph
Tags:
terminal_output --[no]verbosepadrão: "false"-
As consultas também vão mostrar o motivo pelo qual os módulos foram resolvidos para a versão atual (se houver mudanças). O padrão é "true" apenas para a consulta de explicação.
Tags:
terminal_output
- Opções que afetam a verbosidade, o formato ou o local do registro em log:
--[no]verbose_visibility_errorspadrão: "false"-
Se ativados, os erros de visibilidade incluem mais informações de diagnóstico.
- Opções que especificam ou alteram uma entrada genérica para um comando do Bazel que não se enquadra em outras categorias:
--flag_alias=<a 'name=value' flag alias>vários usos são acumulados-
Define um nome abreviado para uma flag do Starlark. Ele usa um único par de chave-valor no formato "<chave>=<valor>" como argumento.
Tags:
changes_inputs,non_configurable
- Opções diversas, não categorizadas de outra forma:
--deleted_packages=<comma-separated list of package names>vários usos são acumulados-
Uma lista separada por vírgulas de nomes de pacotes que o sistema de build vai considerar inexistentes, mesmo que estejam visíveis em algum lugar no caminho do pacote. Use essa opção ao excluir um subpacote "x/y" de um pacote "x" existente. Por exemplo, depois de excluir x/y/BUILD no cliente, o sistema de build poderá reclamar se encontrar um rótulo "//x:y/z" se ele ainda for fornecido por outra entrada package_path. Especificar --deleted_packages x/y evita esse problema.
--[no]fetchpadrão: "true"-
Permite que o comando busque dependências externas. Se definido como "false", o comando vai usar qualquer versão em cache da dependência. Se não houver nenhuma, o comando vai falhar.
--package_path=<colon-separated list of options>padrão: "%workspace%"-
Uma lista separada por dois-pontos de onde procurar pacotes. Os elementos que começam com "%workspace%" são relativos ao espaço de trabalho envolvido. Se for omitido ou estiver vazio, o padrão será a saída de "bazel info default-package-path".
--[no]show_loading_progresspadrão: "true"-
Se ativada, faz com que o Bazel imprima mensagens "Carregando pacote:".
Opções de Print_action
Herda todas as opções de build.
- Opções diversas, não categorizadas de outra forma:
--print_action_mnemonics=<a string>vários usos são acumulados-
Lista quais mnemônicos usar para filtrar os dados de print_action. Se ficar vazio, não haverá filtragem.
Opções de consulta
- Opções que controlam a execução do build:
--[no]experimental_remotable_source_manifestspadrão: "false"-
Se as ações do manifesto de origem podem ser executadas remotamente
--[no]experimental_strict_fileset_outputpadrão: "false"-
Se essa opção estiver ativada, os conjuntos de arquivos vão tratar todos os artefatos de saída como arquivos regulares. Eles não vão percorrer diretórios nem serão sensíveis a symlinks.
Tags:
execution,experimental --[no]incompatible_modify_execution_info_additivepadrão: "true"-
Quando ativada, a transmissão de várias flags --modify_execution_info é cumulativa. Quando desativada, apenas a última flag é considerada.
Tags:
execution,affects_outputs,loading_and_analysis,incompatible_change --[no]keep_going[-k] padrão: "false"-
Continue o máximo possível após um erro. Embora o destino com falha e aqueles que dependem dele não possam ser analisados, outros pré-requisitos desses destinos podem ser.
Tags:
eagerness_to_exit --loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">padrão: "auto"-
Número de linhas de execução paralelas a serem usadas na fase de carregamento/análise. Recebe um número inteiro ou uma palavra-chave ("auto", "HOST_CPUS", "HOST_RAM"), opcionalmente seguida por uma operação ([-|]<float>), por exemplo, "auto", "HOST_CPUS.5". "auto" define um padrão razoável com base nos recursos do host. Precisa ser pelo menos 1.
--modify_execution_info=<regex=[+-]key,regex=[+-]key,...>vários usos são acumulados-
Adicione ou remova chaves das informações de execução de uma ação com base no mnemônico dela. Aplicável apenas a ações que oferecem suporte a informações de execução. Muitas ações comuns oferecem suporte a informações de execução, por exemplo, Genrule, CppCompile, Javac, StarlarkAction e TestRunner. Ao especificar vários valores, a ordem é importante porque muitas expressões regulares podem ser aplicadas ao mesmo mnemônico.
Sintaxe: "regex=[+-]key,regex=[+-]key,...".
Exemplos: '.=+x,.=-y,.=+z' adiciona "x" e "z" e remove "y" das informações de execução de todas as ações. "Genrule=+requires-x" adiciona "requires-x" às informações de execução de todas as ações Genrule. '(?!Genrule).=-requires-x' remove 'requires-x' das informações de execução de todas as ações que não são Genrule.
--[no]use_target_platform_for_testspadrão: "false"-
Se for "true", use a plataforma de destino para executar testes em vez do grupo de execução de teste.
Tags:
execution
- Opções que configuram o conjunto de ferramentas usado para a execução de ações:
--[no]incompatible_bazel_test_exec_run_underpadrão: "true"-
Se ativado, "bazel test --run_under=//:runner" vai criar "//:runner" na configuração de execução. Se estiver desativado, ele vai criar "//:runner" na configuração de destino. O Bazel executa testes em máquinas de execução, então o primeiro é mais correto. Isso não afeta "bazel run", que sempre cria "`--run_under=//foo" na configuração de destino.
- Opções que controlam a saída do comando:
--[no]build_runfile_linkspadrão: "true"-
Se for verdadeiro, vai criar florestas de symlink de runfiles para todos os destinos. Se for "false", grave-os apenas quando exigido por uma ação, teste ou comando de execução local.
Tags:
affects_outputs --[no]build_runfile_manifestspadrão: "true"-
Se verdadeiro, grava manifestos de runfiles para todos os destinos. Se for "false", omita-os. Os testes locais não serão executados quando for "false".
Tags:
affects_outputs --[no]incompatible_always_include_files_in_datapadrão: "true"-
Se for verdadeiro, as regras nativas vão adicionar <code>DefaultInfo.files</code> de dependências de dados aos runfiles, o que corresponde ao comportamento recomendado para regras do Starlark (https://bazel.build/extending/rules#runfiles_features_to_avoid).
--[no]incompatible_compact_repo_mapping_manifestpadrão: "false"-
Se ativado, o arquivo <binary>.repo_mapping vai emitir o mapeamento de repositório de uma extensão de módulo apenas uma vez, em vez de uma vez para cada repositório gerado pela extensão que contribui com runfiles.
--incompatible_disable_select_on=<comma-separated set of options>padrão: ""-
Lista de flags para as quais o uso em select() está desativado.
Tags:
loading_and_analysis,incompatible_change,non_configurable --[no]incompatible_filegroup_runfiles_for_datapadrão: "true"-
Se for verdadeiro, os runfiles dos destinos listados no atributo "srcs" estarão disponíveis para os destinos que consomem o filegroup como uma dependência de dados.
Tags:
incompatible_change
- Opções que permitem ao usuário configurar a saída pretendida, afetando o valor dela, e não a existência:
--action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable>vários usos são acumulados-
Especifica o conjunto de variáveis de ambiente disponíveis para ações com configuração de destino. As variáveis podem ser especificadas por <code>name</code>, em que o valor é extraído do ambiente de invocação, pelo par <code>name=value</code>, que define o valor independente do ambiente de invocação, ou por <code>=name</code>, que desativa a variável com esse nome. Essa opção pode ser usada várias vezes. Para opções fornecidas para a mesma variável, a mais recente vence. Para variáveis diferentes, as opções são acumuladas. <br> A menos que <code>--incompatible_repo_env_ignores_action_env</code> seja verdadeiro, todos os pares <code>name=value</code> estarão disponíveis para as regras do repositório.
Tags:
action_command_lines --allowed_cpu_values=<comma-separated set of options>padrão: ""-
Valores permitidos para a flag "--cpu".
Tags:
changes_inputs,affects_outputs --[no]collect_code_coveragepadrão: "false"-
Se especificado, o Bazel vai instrumentar o código (usando instrumentação off-line sempre que possível) e coletar informações de cobertura durante os testes. Apenas os destinos que correspondem a --instrumentation_filter serão afetados. Normalmente, essa opção não deve ser especificada diretamente. Em vez disso, use o comando "bazel coverage".
Tags:
affects_outputs --compilation_mode=<fastbuild, dbg or opt>[-c] padrão: "fastbuild"-
Especifique o modo em que o binário será criado. Valores: "fastbuild", "dbg", "opt".
--cpu=<a string>padrão: ""-
Descontinuada: essa flag não é usada internamente pelo Blaze, embora haja mapeamentos de plataforma legados para permitir a compatibilidade com versões anteriores. Não use essa flag. Em vez disso, use --platforms com uma definição de plataforma adequada.
Tags:
changes_inputs,affects_outputs --define=<a 'name=value' assignment>vários usos são acumulados-
Cada opção "--define" especifica uma atribuição para uma variável de build. Em caso de vários valores para uma variável, o último vence.
Tags:
changes_inputs,affects_outputs --[no]enable_runfilespadrão: "auto"-
Ative a árvore de symlink de runfiles. Por padrão, ela fica desativada no Windows e ativada em outras plataformas.
Tags:
affects_outputs --exec_aspects=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de aspectos a serem aplicados a destinos configurados por execução, sejam eles de nível superior ou não. Este é um recurso experimental e está sujeito a mudanças.
Tags:
loading_and_analysis --experimental_action_listener=<a build target label>vários usos são acumulados-
Obsoleto, substituído por "aspectos". Use action_listener para anexar uma extra_action a ações de build atuais.
Tags:
execution,experimental --[no]experimental_collect_code_coverage_for_generated_filespadrão: "false"-
Se especificado, o Bazel também vai gerar informações de cobertura de coleta para arquivos gerados.
Tags:
affects_outputs,experimental --experimental_output_paths=<off or strip>padrão: "off"-
Qual modelo usar para onde as regras da árvore de saída gravam as saídas, principalmente para builds multiplataforma / multiconfiguração. Esse recurso é altamente experimental. Consulte https://github.com/bazelbuild/bazel/issues/6526 para mais detalhes. As ações do Starlark podem ativar o mapeamento de caminhos adicionando a chave "supports-path-mapping" ao dicionário "execution_requirements".
Tags:
loses_incremental_state,bazel_internal_configuration,affects_outputs,execution --experimental_override_platform_cpu_name=<a 'label=value' assignment>vários usos são acumulados-
Cada entrada precisa estar no formato "label=value", em que "label" se refere a uma plataforma e "value" é o nome abreviado desejado para substituir o nome da CPU da plataforma na variável de make $(TARGET_CPU) e no caminho de saída. Usado somente quando --experimental_platform_in_output_dir, --incompatible_target_cpu_from_platform ou --incompatible_bep_cpu_from_platform é verdadeiro. Tem a maior prioridade de nomenclatura.
Tags:
affects_outputs,experimental --[no]experimental_platform_in_output_dirpadrão: "false"-
Se for "true", um nome abreviado para a plataforma de destino será usado no nome do diretório de saída em vez da CPU. Se for "auto", isso só será aplicado à configuração de execução. O esquema exato é experimental e está sujeito a mudanças. Primeiro, no caso raro em que a opção "--platforms" não tem exatamente um valor, um hash da opção "platforms" é usado. Em seguida, se um nome abreviado para a plataforma atual foi registrado por --experimental_override_name_platform_in_output_dir, esse nome abreviado será usado. Em seguida, se --experimental_use_platforms_in_output_dir_legacy_heuristic estiver definido, use um nome abreviado com base no rótulo da plataforma atual. Por fim, um hash da opção de plataforma é usado como último recurso.
Tags:
affects_outputs,experimental --[no]experimental_use_platforms_in_output_dir_legacy_heuristicpadrão: "true"-
Use essa flag apenas como parte de uma estratégia de migração ou teste sugerida. A heurística tem deficiências conhecidas. Por isso, recomendamos migrar para usar apenas --experimental_override_name_platform_in_output_dir.
Tags:
affects_outputs,experimental --features=<a string>vários usos são acumulados-
Os recursos especificados serão ativados ou desativados por padrão para destinos criados na configuração de destino. Especificar -<recurso> desativa o recurso. Recursos negativos sempre substituem os positivos. Consulte também --host_features
Tags:
changes_inputs,affects_outputs --host_action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable>vários usos são acumulados-
Especifica o conjunto de variáveis de ambiente disponíveis para ações com configurações de execução. As variáveis podem ser especificadas por nome, caso em que o valor será extraído do ambiente de invocação, pelo par nome=valor, que define o valor independente do ambiente de invocação, ou por <code>=name</code>, que desativa a variável desse nome. Essa opção pode ser usada várias vezes. Para opções fornecidas para a mesma variável, a mais recente vence. Para variáveis diferentes, as opções são acumuladas.
Tags:
action_command_lines --host_compilation_mode=<fastbuild, dbg or opt>padrão: "opt"-
Especifique o modo em que as ferramentas usadas durante a criação serão criadas. Valores: "fastbuild", "dbg", "opt".
--host_cpu=<a string>padrão: ""-
A CPU do host.
Tags:
changes_inputs,affects_outputs --host_features=<a string>vários usos são acumulados-
Os recursos especificados serão ativados ou desativados por padrão para destinos criados na configuração de execução. Especificar -<recurso> desativa o recurso. Recursos negativos sempre substituem os positivos.
Tags:
changes_inputs,affects_outputs --[no]incompatible_auto_exec_groupspadrão: "false"-
Quando ativado, um grupo de execução é criado automaticamente para cada cadeia de ferramentas usada por uma regra. Para que isso funcione, a regra precisa especificar o parâmetro
toolchainnas ações dela. Para mais informações, consulte https://github.com/bazelbuild/bazel/issues/17134. --[no]incompatible_merge_genfiles_directorypadrão: "true"-
Se for verdadeiro, o diretório "genfiles" será incorporado ao diretório "bin".
--[no]incompatible_target_cpu_from_platformpadrão: "true"-
Se especificado, o valor da restrição de CPU (@platforms//cpu:cpu) da plataforma de destino será usado para definir a variável de criação $(TARGET_CPU).
--[no]instrument_test_targetspadrão: "false"-
Quando a cobertura está ativada, especifica se as regras de teste de instrumentação devem ser consideradas. Quando definido, as regras de teste incluídas por --instrumentation_filter são instrumentadas. Caso contrário, as regras de teste são sempre excluídas da instrumentação de cobertura.
Tags:
affects_outputs --instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>padrão: "-/javatests[/:],-/test/java[/:]"-
Quando a cobertura está ativada, apenas as regras com nomes incluídos pelo filtro especificado baseado em regex são instrumentadas. As regras com o prefixo "-" são excluídas. Somente regras que não são de teste são instrumentadas, a menos que a flag --instrument_test_targets esteja ativada.
Tags:
affects_outputs --platform_suffix=<a string>padrão: consulte a descrição-
Especifica um sufixo a ser adicionado ao diretório de configuração.
Tags:
loses_incremental_state,affects_outputs,loading_and_analysis --run_under=<a prefix in front of command>padrão: consulte a descrição-
Prefixo a ser inserido antes dos executáveis dos comandos "test" e "run". Se o valor for "foo -bar" e a linha de comando de execução for "test_binary -baz", a linha de comando final será "foo -bar test_binary -baz".Isso também pode ser um rótulo para um destino executável. Alguns exemplos são: "valgrind", "strace", "strace -c", "valgrind --quiet --num-callers=20", "//package:target", "//package:target --options".
Tags:
action_command_lines --[no]stamppadrão: "false"-
Adicionar carimbo aos binários com a data, o nome de usuário, o nome do host, as informações do espaço de trabalho etc.
Tags:
affects_outputs
- Opções que afetam a rigidez com que o Bazel aplica entradas de build válidas (definições de regras, combinações de flags etc.):
--[no]check_visibilitypadrão: "true"-
Se desativado, os erros de visibilidade nas dependências de destino serão rebaixados para avisos.
--[no]enforce_constraintspadrão: "true"-
Verifica os ambientes com que cada destino é compatível e informa erros se algum destino tiver dependências que não oferecem suporte aos mesmos ambientes.
Tags:
build_file_semantics --[no]experimental_enforce_transitive_visibilitypadrão: "false"-
Se verdadeiro, permite que package()s definam o atributo transitive_visibility para restringir quais pacotes podem depender deles.
Tags:
build_file_semantics,experimental --[no]incompatible_check_testonly_for_output_filespadrão: "false"-
Se ativado, verifique testonly para destinos de pré-requisito que são arquivos de saída pesquisando o testonly da regra geradora. Isso corresponde à verificação de visibilidade.
--[no]strict_filesetspadrão: "false"-
Se essa opção estiver ativada, os conjuntos de arquivos que cruzam os limites do pacote serão informados como erros.
--target_environment=<a build target label>vários usos são acumulados-
Declara o ambiente de destino deste build. Precisa ser uma referência de rótulo a uma regra de "ambiente". Se especificado, todos os destinos de nível superior precisam ser compatíveis com esse ambiente.
Tags:
changes_inputs
- Essa opção afeta a semântica da linguagem Starlark ou a API de build acessível a arquivos BUILD, .bzl ou WORKSPACE.:
--[no]incompatible_config_setting_private_default_visibilitypadrão: "false"-
Se "incompatible_enforce_config_setting_visibility=false", isso não terá efeito. Caso contrário, se essa flag for "false", qualquer config_setting sem um atributo de visibilidade explícito será //visibility:public. Se essa flag for "true", "config_setting" vai seguir a mesma lógica de visibilidade de todas as outras regras. Consulte https://github.com/bazelbuild/bazel/issues/12933.
--[no]incompatible_enforce_config_setting_visibilitypadrão: "true"-
Se for "true", aplique as restrições de visibilidade de "config_setting". Se for "false", todas as config_setting serão visíveis para todos os destinos. Consulte https://github.com/bazelbuild/bazel/issues/12932.
- Opções que regem o comportamento do ambiente de teste ou do executor de testes:
--[no]allow_analysis_failurespadrão: "false"-
Se for "true", uma falha na análise de um destino de regra vai resultar na propagação de uma instância de "AnalysisFailureInfo" contendo a descrição do erro, em vez de resultar em uma falha de build.
Tags:
loading_and_analysis,experimental - Padrão de
--analysis_testing_deps_limit=<an integer>: "2000" -
Define o número máximo de dependências transitivas usando um atributo de regra com uma transição de configuração for_analysis_testing. Exceder esse limite vai resultar em um erro de regra.
Tags:
loading_and_analysis
- Opções relacionadas à saída e à semântica da consulta:
--aspect_deps=<off, conservative or precise>padrão: "conservative"-
Como resolver dependências de aspectos quando o formato de saída é um dos seguintes: {xml,proto,record}. "off" significa que nenhuma dependência de aspecto é resolvida. "conservative" (o padrão) significa que todas as dependências de aspecto declaradas são adicionadas, independente de terem recebido a classe de regra de dependências diretas. "precise" significa que apenas os aspectos possivelmente ativos são adicionados, considerando a classe de regra das dependências diretas. O modo preciso exige o carregamento de outros pacotes para avaliar uma única meta, o que o torna mais lento do que os outros modos. Além disso, mesmo o modo preciso não é completamente preciso: a decisão de calcular um aspecto é tomada na fase de análise, que não é executada durante "bazel query".
Tags:
build_file_semantics --[no]consistent_labelspadrão: "false"-
Se ativado, todo comando de consulta vai emitir rótulos como se a função <code>str</code> do Starlark fosse aplicada a uma instância <code>Label</code>. Isso é útil para ferramentas que precisam corresponder à saída de diferentes comandos de consulta e/ou rótulos emitidos por regras. Se não estiver ativado, os formatadores de saída poderão emitir nomes de repositórios aparentes (em relação ao repositório principal) para tornar a saída mais legível.
Tags:
terminal_output --[no]experimental_explicit_aspectspadrão: "false"-
aquery, cquery: se as ações geradas por aspectos devem ser incluídas na saída. query: no-op (os aspectos são sempre seguidos).
Tags:
terminal_output --[no]experimental_graphless_querypadrão: "auto"-
Se for verdadeiro, vai usar uma implementação de consulta que não faz uma cópia do gráfico. A nova implementação só oferece suporte a --order_output=no e a um subconjunto de formatadores de saída.
--graph:conditional_edges_limit=<an integer>padrão: "4"-
O número máximo de rótulos de condição a serem mostrados. -1 significa que não há truncamento e 0 significa que não há anotação. Essa opção só é aplicável a --output=graph.
Tags:
terminal_output --[no]graph:factoredpadrão: "true"-
Se for "verdadeiro", o gráfico será emitido "fatorado", ou seja, nós topologicamente equivalentes serão mesclados e os rótulos concatenados. Essa opção só é aplicável a --output=graph.
Tags:
terminal_output --graph:node_limit=<an integer>padrão: "512"-
O comprimento máximo da string de rótulo para um nó de gráfico na saída. Rótulos mais longos serão truncados. -1 significa que não haverá truncamento. Essa opção só é aplicável a --output=graph.
Tags:
terminal_output --[no]implicit_depspadrão: "true"-
Se ativadas, as dependências implícitas serão incluídas no gráfico de dependências em que a consulta opera. Uma dependência implícita é aquela que não é especificada explicitamente no arquivo BUILD, mas é adicionada pelo Bazel. Para cquery, essa opção controla a filtragem de toolchains resolvidas.
Tags:
build_file_semantics --[no]include_aspectspadrão: "true"-
aquery, cquery: se as ações geradas por aspectos devem ser incluídas na saída. query: no-op (os aspectos são sempre seguidos).
Tags:
terminal_output --[no]incompatible_lexicographical_outputpadrão: "true"-
Se essa opção for definida, a saída "--order_output=auto" será classificada em ordem lexicográfica.
--[no]incompatible_package_group_includes_double_slashpadrão: "true"-
Se ativado, ao gerar o atributo
packagesde package_group, o//inicial não será omitido. --[no]infer_universe_scopepadrão: "false"-
Se definido e --universe_scope não estiver definido, um valor de --universe_scope será inferido como a lista de padrões de destino exclusivos na expressão de consulta. O valor --universe_scope inferido para uma expressão de consulta que usa funções com escopo de universo (por exemplo,
allrdeps) pode não ser o que você quer. Portanto, use essa opção apenas se souber o que está fazendo. Acesse https://bazel.build/reference/query#sky-query para ver detalhes e exemplos. Se --universe_scope estiver definido, o valor dessa opção será ignorado. Observação: essa opção se aplica apenas aquery(ou seja, nãocquery).Tags:
loading_and_analysis --[no]line_terminator_nullpadrão: "false"-
Se cada formato é encerrado com \0 em vez de uma nova linha.
Tags:
terminal_output --[no]nodep_depspadrão: "true"-
Se ativada, as dependências dos atributos "nodep" serão incluídas no gráfico de dependências em que a consulta opera. Um exemplo comum de atributo "nodep" é "visibility". Execute e analise a saída de
info build-languagepara saber mais sobre todos os atributos "nodep" na linguagem de build.Tags:
build_file_semantics --noorder_results-
Mostra os resultados em ordem de dependência (padrão) ou sem ordem. A saída não ordenada é mais rápida, mas só é compatível quando --output não é minrank, maxrank ou graph.
Expande para:
--order_output=noTags:
terminal_output --null-
Se cada formato é encerrado com \0 em vez de uma nova linha.
Expande para:
--line_terminator_null=trueTags:
terminal_output --order_output=<no, deps, auto or full>padrão: "auto"-
Mostra os resultados sem ordem (no), com ordem de dependência (deps) ou totalmente ordenados (full). O padrão é "auto", o que significa que os resultados são gerados com ordenação por dependência ou total, dependendo do formatador de saída (por dependência para proto, minrank, maxrank e gráfico, total para todos os outros). Quando a saída está totalmente ordenada, os nós são impressos em uma ordem totalmente determinística (total). Primeiro, todos os nós são classificados em ordem alfabética. Em seguida, cada nó na lista é usado como o início de uma pesquisa em profundidade pós-ordem em que as arestas de saída para nós não visitados são percorridas em ordem alfabética dos nós sucessores. Por fim, os nós são impressos na ordem inversa em que foram visitados.
Tags:
terminal_output --order_results-
Mostra os resultados em ordem de dependência (padrão) ou sem ordem. A saída não ordenada é mais rápida, mas só é compatível quando --output não é minrank, maxrank ou graph.
Expande para:
--order_output=autoTags:
terminal_output - Padrão de
--output=<a string>: "label" -
O formato em que os resultados da consulta precisam ser impressos. Os valores permitidos para a consulta são: build, graph, streamed_jsonproto, label, label_kind, location, maxrank, minrank, package, proto, streamed_proto, xml.
Tags:
terminal_output --output_file=<a string>padrão: ""-
Quando especificado, os resultados da consulta são gravados diretamente nesse arquivo, e nada é impresso no stream de saída padrão (stdout) do Bazel. Em comparativos, isso geralmente é mais rápido do que <code>bazel query > file</code>.
Tags:
terminal_output --[no]proto:default_valuespadrão: "true"-
Se for "true", os atributos cujo valor não for especificado explicitamente no arquivo BUILD serão incluídos. Caso contrário, eles serão omitidos. Essa opção é válida para --output=proto
Tags:
terminal_output --[no]proto:definition_stackpadrão: "false"-
Preencha o campo proto "definition_stack", que registra para cada instância de regra a pilha de chamadas do Starlark no momento em que a classe da regra foi definida.
Tags:
terminal_output --[no]proto:flatten_selectspadrão: "true"-
Se ativado, os atributos configuráveis criados por select() serão simplificados. Para tipos de lista, a representação simplificada é uma lista que contém cada valor do mapa de seleção exatamente uma vez. Os tipos escalares são nivelados como nulos.
Tags:
build_file_semantics --[no]proto:include_attribute_source_aspectspadrão: "false"-
Preencha o campo proto source_aspect_name de cada atributo com o aspecto de origem de onde ele veio (string vazia se não veio de nenhum).
Tags:
terminal_output --[no]proto:include_starlark_rule_envpadrão: "true"-
Use o ambiente starlark no valor do atributo $internal_attr_hash gerado. Isso garante que a definição da regra do Starlark (e as importações transitivas dela) façam parte desse identificador.
Tags:
terminal_output --[no]proto:include_synthetic_attribute_hashpadrão: "false"-
Se o atributo $internal_attr_hash deve ser calculado e preenchido.
Tags:
terminal_output --[no]proto:instantiation_stackpadrão: "false"-
Preencha a pilha de chamadas de instanciação de cada regra. Isso exige que a pilha esteja presente
Tags:
terminal_output --[no]proto:locationspadrão: "true"-
Determina se as informações de local devem ser geradas na saída proto.
Tags:
terminal_output - Padrão de
--proto:output_rule_attrs=<comma-separated list of options>: "all" -
Lista separada por vírgulas de atributos a serem incluídos na saída. O padrão é todos os atributos. Defina como uma string vazia para não gerar nenhum atributo. Essa opção é válida para --output=proto.
Tags:
terminal_output --[no]proto:rule_classespadrão: "false"-
Preencha o campo "rule_class_key" de cada regra e, para a primeira regra com um determinado "rule_class_key", preencha também o campo proto "rule_class_info". O campo "rule_class_key" identifica exclusivamente uma classe de regra, e o campo "rule_class_info" é uma definição de API de classe de regra no formato Stardoc.
Tags:
terminal_output --[no]proto:rule_inputs_and_outputspadrão: "true"-
Se os campos "rule_input" e "rule_output" devem ser preenchidos.
Tags:
terminal_output --query_file=<a string>padrão: ""-
Se definido, a consulta vai ler o arquivo nomeado aqui, em vez da linha de comando. É um erro especificar um arquivo aqui e uma consulta de linha de comando.
Tags:
changes_inputs --[no]relative_locationspadrão: "false"-
Se for "true", o local dos arquivos BUILD nas saídas XML e proto será relativo. Por padrão, a saída de local é um caminho absoluto e não é consistente em todas as máquinas. Defina essa opção como "true" para ter um resultado consistente em todas as máquinas.
Tags:
terminal_output --[no]strict_test_suitepadrão: "false"-
Se for "true", a expressão tests() vai gerar um erro se encontrar uma test_suite que contenha destinos que não são de teste.
--[no]tool_depspadrão: "true"-
Consulta: se desativado, as dependências da "configuração de execução" não serão incluídas no gráfico de dependências em que a consulta opera. Uma aresta de dependência de "configuração de execução", como a de qualquer regra "proto_library" para o compilador de protocolo, geralmente aponta para uma ferramenta executada durante a build, em vez de uma parte do mesmo programa "target". Cquery: se desativado, filtra todos os destinos configurados que cruzam uma transição de execução do destino de nível superior que descobriu esse destino configurado. Isso significa que, se o destino de nível superior estiver na configuração de destino, somente os destinos configurados que também estiverem na configuração de destino serão retornados. Se o destino de nível superior estiver na configuração de execução, somente os destinos configurados para execução serão retornados. Essa opção NÃO exclui toolchains resolvidas.
Tags:
build_file_semantics --universe_scope=<comma-separated list of options>padrão: ""-
Um conjunto de padrões de destino separados por vírgulas (aditivos e subtrativos). A consulta pode ser realizada no universo definido pelo fechamento transitivo das metas especificadas. Essa opção é usada para os comandos "query" e "cquery". Para cquery, a entrada dessa opção são os destinos em que todas as respostas são criadas. Portanto, essa opção pode afetar configurações e transições. Se essa opção não for especificada, os destinos de nível superior serão considerados os destinos analisados da expressão de consulta. Observação: para cquery, não especificar essa opção pode fazer com que o build seja interrompido se os destinos analisados da expressão de consulta não puderem ser criados com opções de nível superior.
Tags:
loading_and_analysis --[no]xml:default_valuespadrão: "false"-
Se for "true", os atributos de regra cujo valor não for especificado explicitamente no arquivo BUILD serão impressos. Caso contrário, eles serão omitidos.
Tags:
terminal_output --[no]xml:line_numberspadrão: "true"-
Se for "true", a saída XML vai conter números de linha. Desativar essa opção pode facilitar a leitura das diferenças. Essa opção só é aplicável a --output=xml.
Tags:
terminal_output
- Opções que afetam a verbosidade, o formato ou o local do registro em log:
--[no]verbose_visibility_errorspadrão: "false"-
Se ativados, os erros de visibilidade incluem mais informações de diagnóstico.
- Opções que especificam ou alteram uma entrada genérica para um comando do Bazel que não se enquadra em outras categorias:
--flag_alias=<a 'name=value' flag alias>vários usos são acumulados-
Define um nome abreviado para uma flag do Starlark. Ele usa um único par de chave-valor no formato "<chave>=<valor>" como argumento.
Tags:
changes_inputs,non_configurable
- Opções diversas, não categorizadas de outra forma:
--deleted_packages=<comma-separated list of package names>vários usos são acumulados-
Uma lista separada por vírgulas de nomes de pacotes que o sistema de build vai considerar inexistentes, mesmo que estejam visíveis em algum lugar no caminho do pacote. Use essa opção ao excluir um subpacote "x/y" de um pacote "x" existente. Por exemplo, depois de excluir x/y/BUILD no cliente, o sistema de build poderá reclamar se encontrar um rótulo "//x:y/z" se ele ainda for fornecido por outra entrada package_path. Especificar --deleted_packages x/y evita esse problema.
--[no]fetchpadrão: "true"-
Permite que o comando busque dependências externas. Se definido como "false", o comando vai usar qualquer versão em cache da dependência. Se não houver nenhuma, o comando vai falhar.
--package_path=<colon-separated list of options>padrão: "%workspace%"-
Uma lista separada por dois-pontos de onde procurar pacotes. Os elementos que começam com "%workspace%" são relativos ao espaço de trabalho envolvido. Se for omitido ou estiver vazio, o padrão será a saída de "bazel info default-package-path".
--[no]show_loading_progresspadrão: "true"-
Se ativada, faz com que o Bazel imprima mensagens "Carregando pacote:".
Opções de execução
Herda todas as opções de build.
- Opções que aparecem antes do comando e são analisadas pelo cliente:
--[no]portable_pathspadrão: "false"-
Se for verdadeiro, inclui caminhos para substituir em ExecRequest e tornar os caminhos resultantes portáteis.
Tags:
affects_outputs --[no]runpadrão: "true"-
Se for "false", pule a execução da linha de comando criada para o destino de build. Essa flag é ignorada em todos os builds --script_path.
Tags:
affects_outputs --run_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable>vários usos são acumulados-
Especifica o conjunto de variáveis de ambiente disponíveis para a execução do destino. As variáveis podem ser especificadas por nome. Nesse caso, o valor será extraído do ambiente de invocação, do par <code>name=value</code>, que define o valor independente do ambiente de invocação, ou de <code>=name</code>, que remove a variável com esse nome. Essa opção pode ser usada várias vezes. Para opções fornecidas para a mesma variável, a mais recente vence. Para variáveis diferentes, as opções são acumuladas. O destino executado geralmente vê todo o ambiente do host, exceto as variáveis que foram explicitamente desdefinidas.
Tags:
affects_outputs
- Opções que permitem ao usuário configurar a saída pretendida, afetando o valor dela, e não a existência:
--script_path=<a path>padrão: consulte a descrição-
Se definido, grava um script shell no arquivo especificado que invoca o destino. Se essa opção for definida, o destino não será executado pelo bazel. Use "bazel run --script_path=foo //foo && ./foo" para invocar o destino "//foo". Isso difere de "bazel run //foo" porque o bloqueio do bazel é liberado e o executável é conectado ao stdin do terminal.
Tags:
affects_outputs,execution
Opções de desligamento
- Opções que controlam a saída do comando:
--iff_heap_size_greater_than=<an integer>padrão: "0"-
Se não for zero, o desligamento só vai ocorrer se a memória total (em MB) consumida pela JVM exceder esse valor.
Opções de teste
Herda todas as opções de build.
- Opções que afetam a verbosidade, o formato ou o local do registro em log:
--[no]print_relative_test_log_pathspadrão: "false"-
Se for verdadeiro, ao imprimir o caminho para um registro de teste, use o caminho relativo que usa o link simbólico de conveniência "testlogs". Observação: uma invocação subsequente de "build"/"test"/etc. com uma configuração diferente pode mudar o destino desse link simbólico, tornando o caminho impresso anteriormente inútil.
Tags:
affects_outputs --[no]test_verbose_timeout_warningspadrão: "false"-
Se for "true", vai imprimir avisos adicionais quando o tempo real de execução do teste não corresponder ao tempo limite definido pelo teste (implícito ou explícito).
Tags:
affects_outputs --[no]verbose_test_summarypadrão: "true"-
Se for verdadeiro, imprima informações adicionais (tempo, número de execuções com falha etc.) no resumo do teste.
Tags:
affects_outputs
Opções de fornecedor
Herda todas as opções de test.
- Opções que controlam a execução do build:
--[no]keep_going[-k] padrão: "false"-
Continue o máximo possível após um erro. Embora o destino com falha e aqueles que dependem dele não possam ser analisados, outros pré-requisitos desses destinos podem ser.
Tags:
eagerness_to_exit --loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">padrão: "auto"-
Número de linhas de execução paralelas a serem usadas na fase de carregamento/análise. Recebe um número inteiro ou uma palavra-chave ("auto", "HOST_CPUS", "HOST_RAM"), opcionalmente seguida por uma operação ([-|]<float>), por exemplo, "auto", "HOST_CPUS.5". "auto" define um padrão razoável com base nos recursos do host. Precisa ser pelo menos 1.
- Essa opção afeta a semântica da linguagem Starlark ou a API de build acessível a arquivos BUILD, .bzl ou WORKSPACE.:
--[no]incompatible_config_setting_private_default_visibilitypadrão: "false"-
Se "incompatible_enforce_config_setting_visibility=false", isso não terá efeito. Caso contrário, se essa flag for "false", qualquer config_setting sem um atributo de visibilidade explícito será //visibility:public. Se essa flag for "true", "config_setting" vai seguir a mesma lógica de visibilidade de todas as outras regras. Consulte https://github.com/bazelbuild/bazel/issues/12933.
--[no]incompatible_enforce_config_setting_visibilitypadrão: "true"-
Se for "true", aplique as restrições de visibilidade de "config_setting". Se for "false", todas as config_setting serão visíveis para todos os destinos. Consulte https://github.com/bazelbuild/bazel/issues/12932.
- Opções relacionadas à saída e à semântica do Bzlmod:
--repo=<a string>vários usos são acumulados-
Somente fornecedores do repositório especificado, que pode ser
@apparent_repo_nameou@@canonical_repo_name. Essa opção pode ser definida várias vezes.Tags:
changes_inputs
- Opções diversas, não categorizadas de outra forma:
--deleted_packages=<comma-separated list of package names>vários usos são acumulados-
Uma lista separada por vírgulas de nomes de pacotes que o sistema de build vai considerar inexistentes, mesmo que estejam visíveis em algum lugar no caminho do pacote. Use essa opção ao excluir um subpacote "x/y" de um pacote "x" existente. Por exemplo, depois de excluir x/y/BUILD no cliente, o sistema de build poderá reclamar se encontrar um rótulo "//x:y/z" se ele ainda for fornecido por outra entrada package_path. Especificar --deleted_packages x/y evita esse problema.
--[no]fetchpadrão: "true"-
Permite que o comando busque dependências externas. Se definido como "false", o comando vai usar qualquer versão em cache da dependência. Se não houver nenhuma, o comando vai falhar.
--package_path=<colon-separated list of options>padrão: "%workspace%"-
Uma lista separada por dois-pontos de onde procurar pacotes. Os elementos que começam com "%workspace%" são relativos ao espaço de trabalho envolvido. Se for omitido ou estiver vazio, o padrão será a saída de "bazel info default-package-path".
--[no]show_loading_progresspadrão: "true"-
Se ativada, faz com que o Bazel imprima mensagens "Carregando pacote:".
- Opções que controlam a execução do build:
--[no]experimental_persistent_aar_extractorpadrão: "false"-
Ative o extrator aar permanente usando workers.
Tags:
execution,experimental --[no]experimental_remotable_source_manifestspadrão: "false"-
Se as ações do manifesto de origem podem ser executadas remotamente
--[no]experimental_split_coverage_postprocessingpadrão: "false"-
Se for verdadeiro, o Bazel vai executar o pós-processamento de cobertura para o teste em uma nova geração.
Tags:
execution,experimental --[no]experimental_strict_fileset_outputpadrão: "false"-
Se essa opção estiver ativada, os conjuntos de arquivos vão tratar todos os artefatos de saída como arquivos regulares. Eles não vão percorrer diretórios nem serão sensíveis a symlinks.
Tags:
execution,experimental --[no]incompatible_modify_execution_info_additivepadrão: "true"-
Quando ativada, a transmissão de várias flags --modify_execution_info é cumulativa. Quando desativada, apenas a última flag é considerada.
Tags:
execution,affects_outputs,loading_and_analysis,incompatible_change --modify_execution_info=<regex=[+-]key,regex=[+-]key,...>vários usos são acumulados-
Adicione ou remova chaves das informações de execução de uma ação com base no mnemônico dela. Aplicável apenas a ações que oferecem suporte a informações de execução. Muitas ações comuns oferecem suporte a informações de execução, por exemplo, Genrule, CppCompile, Javac, StarlarkAction e TestRunner. Ao especificar vários valores, a ordem é importante porque muitas expressões regulares podem ser aplicadas ao mesmo mnemônico.
Sintaxe: "regex=[+-]key,regex=[+-]key,...".
Exemplos: '.=+x,.=-y,.=+z' adiciona "x" e "z" e remove "y" das informações de execução de todas as ações. "Genrule=+requires-x" adiciona "requires-x" às informações de execução de todas as ações Genrule. '(?!Genrule).=-requires-x' remove 'requires-x' das informações de execução de todas as ações que não são Genrule.
--persistent_android_dex_desugar-
Ative ações persistentes de dex e dessugar do Android usando workers.
Expande para:
--internal_persistent_android_dex_desugar
--strategy=Desugar=worker
--strategy=DexBuilder=worker --persistent_android_resource_processor-
Ative o processador de recursos persistentes do Android usando workers.
Expande para:
--internal_persistent_busybox_tools
--strategy=AaptPackage=worker
--strategy=AndroidResourceParser=worker
--strategy=AndroidResourceValidator=worker
--strategy=AndroidResourceCompiler=worker
--strategy=RClassGenerator=worker
--strategy=AndroidResourceLink=worker
--strategy=AndroidAapt2=worker
--strategy=AndroidAssetMerger=worker
--strategy=AndroidResourceMerger=worker
--strategy=AndroidCompiledResourceMerger=worker
--strategy=ManifestMerger=worker
--strategy=AndroidManifestMerger=worker
--strategy=Aapt2Optimize=worker
--strategy=AARGenerator=worker
--strategy=ProcessDatabinding=worker
--strategy=GenerateDataBindingBaseClasses=worker --persistent_multiplex_android_dex_desugar-
Ative ações persistentes e multiplexadas de dex e dessugar do Android usando workers.
Expande para:
--persistent_android_dex_desugar
--internal_persistent_multiplex_android_dex_desugar --persistent_multiplex_android_resource_processor-
Ative o processador de recursos do Android multiplexado persistente usando workers.
Expande para:
--persistent_android_resource_processor
--modify_execution_info=AaptPackage=+supports-multiplex-workers
--modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
--modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
--modify_execution_info=RClassGenerator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
--modify_execution_info=AndroidAapt2=+supports-multiplex-workers
--modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
--modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
--modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
--modify_execution_info=ManifestMerger=+supports-multiplex-workers
--modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
--modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
--modify_execution_info=AARGenerator=+supports-multiplex-workers --persistent_multiplex_android_tools-
Ativar ferramentas Android persistentes e multiplexadas (dexing, desugaring, processamento de recursos).
Expande para:
--internal_persistent_multiplex_busybox_tools
--persistent_multiplex_android_resource_processor
--persistent_multiplex_android_dex_desugar --[no]use_target_platform_for_testspadrão: "false"-
Se for "true", use a plataforma de destino para executar testes em vez do grupo de execução de teste.
Tags:
execution
- Opções que configuram o conjunto de ferramentas usado para a execução de ações:
--android_compiler=<a string>padrão: consulte a descrição-
O compilador de destino do Android.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state --android_manifest_merger=<legacy, android or force_android>padrão: "android"-
Seleciona o combinador de manifestos a ser usado para regras android_binary. Flag para ajudar na transição do combinador legado para o combinador do manifesto do Android.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state --android_platforms=<a build target label>padrão: ""-
Define as plataformas usadas pelas segmentações android_binary. Se várias plataformas forem especificadas, o binário será um APK fat, que contém binários nativos para cada plataforma de destino especificada.
Tags:
changes_inputs,loading_and_analysis,loses_incremental_state --cc_output_directory_tag=<a string>padrão: ""-
Especifica um sufixo a ser adicionado ao diretório de configuração.
Tags:
affects_outputs --compiler=<a string>padrão: consulte a descrição-
O compilador C++ a ser usado para compilar o destino.
Tags:
loading_and_analysis,execution --coverage_output_generator=<a build target label>default: "@bazel_tools//tools/test:lcov_merger"-
Local do binário usado para pós-processar relatórios de cobertura bruta. Precisa ser uma meta binária. O padrão é "//tools/test:lcov_merger".
--coverage_report_generator=<a build target label>default: "@bazel_tools//tools/test:coverage_report_generator"-
Local do binário usado para gerar relatórios de cobertura. Precisa ser uma meta binária. O padrão é "//tools/test:coverage_report_generator".
--coverage_support=<a build target label>default: "@bazel_tools//tools/test:coverage_support"-
Localização dos arquivos de suporte necessários nas entradas de todas as ações de teste que coletam cobertura de código. O padrão é "//tools/test:coverage_support".
--custom_malloc=<a build target label>padrão: consulte a descrição-
Especifica uma implementação de malloc personalizada. Essa configuração substitui os atributos malloc nas regras de build.
Tags:
changes_inputs,affects_outputs --[no]experimental_include_xcode_execution_requirementspadrão: "false"-
Se definido, adicione um requisito de execução "requires-xcode:{version}" a todas as ações do Xcode. Se a versão do Xcode tiver um rótulo hifenizado, adicione também um requisito de execução "requires-xcode-label:{version_label}".
Tags:
loses_incremental_state,loading_and_analysis,execution,experimental --[no]experimental_prefer_mutual_xcodepadrão: "true"-
Se for "true", use o Xcode mais recente disponível local e remotamente. Se for "false" ou se não houver versões disponíveis em comum, use a versão local do Xcode selecionada com xcode-select.
--extra_execution_platforms=<comma-separated list of options>padrão: ""-
As plataformas disponíveis como plataformas de execução para realizar ações. As plataformas podem ser especificadas por segmentação exata ou como um padrão de segmentação. Essas plataformas serão consideradas antes daquelas declaradas no arquivo WORKSPACE por register_execution_platforms(). Essa opção só pode ser definida uma vez. Instâncias posteriores vão substituir as configurações de flag anteriores.
Tags:
execution --extra_toolchains=<comma-separated list of options>vários usos são acumulados-
As regras da cadeia de ferramentas a serem consideradas durante a resolução da cadeia de ferramentas. As toolchains podem ser especificadas por destino exato ou como um padrão de destino. Esses conjuntos de ferramentas serão considerados antes daqueles declarados no arquivo WORKSPACE por register_toolchains().
--grte_top=<a label>padrão: consulte a descrição-
Um rótulo para uma biblioteca libc registrada. O valor padrão é selecionado pela cadeia de ferramentas crosstool, e quase nunca é necessário substituir esse valor.
--host_compiler=<a string>padrão: consulte a descrição-
Flag de nenhuma operação. Será removido em uma versão futura.
Tags:
loading_and_analysis,execution --host_grte_top=<a label>padrão: consulte a descrição-
Se especificada, essa configuração vai substituir o diretório de nível superior da libc (--grte_top) para a configuração de execução.
--host_platform=<a build target label>default: "@bazel_tools//tools:host_platform"-
O rótulo de uma regra de plataforma que descreve o sistema host.
--[no]incompatible_bazel_test_exec_run_underpadrão: "true"-
Se ativado, "bazel test --run_under=//:runner" vai criar "//:runner" na configuração de execução. Se estiver desativado, ele vai criar "//:runner" na configuração de destino. O Bazel executa testes em máquinas de execução, então o primeiro é mais correto. Isso não afeta "bazel run", que sempre cria "`--run_under=//foo" na configuração de destino.
--[no]incompatible_builtin_objc_strip_actionpadrão: "true"-
Se uma ação de remoção deve ser emitida como parte da vinculação objc.
--[no]incompatible_dont_enable_host_nonhost_crosstool_featurespadrão: "true"-
Se for "true", o Bazel não vai ativar os recursos "host" e "nonhost" na cadeia de ferramentas do C++ (consulte https://github.com/bazelbuild/bazel/issues/7407 para mais informações).
--[no]incompatible_enable_apple_toolchain_resolutionpadrão: "false"-
Use a resolução da cadeia de ferramentas para selecionar o SDK da Apple para regras da Apple (Starlark e nativas).
--[no]incompatible_remove_legacy_whole_archivepadrão: "true"-
Se for "true", o Bazel não vai vincular dependências de biblioteca como um arquivo inteiro por padrão. Consulte https://github.com/bazelbuild/bazel/issues/7362 para instruções de migração.
--[no]incompatible_strip_executable_safelypadrão: "false"-
Se for verdadeiro, a ação de remoção para executáveis usará a flag -x, que não interrompe a resolução dinâmica de símbolos.
-
Use objetos compartilhados de interface se forem compatíveis com o conjunto de ferramentas. Todas as toolchains ELF são compatíveis com essa configuração.
Tags:
loading_and_analysis,affects_outputs,affects_outputs --ios_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Especifica a versão do SDK para iOS a ser usada para criar aplicativos iOS. Se não for especificado, usará a versão padrão do SDK para iOS de "xcode_version".
Tags:
loses_incremental_state --macos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Especifica a versão do SDK do macOS a ser usada para criar aplicativos desse sistema operacional. Se não for especificado, usará a versão padrão do SDK do macOS de "xcode_version".
Tags:
loses_incremental_state --minimum_os_version=<a string>padrão: consulte a descrição-
A versão mínima do SO que sua compilação segmenta.
--platform_mappings=<a main workspace-relative path>padrão: ""-
O local de um arquivo de mapeamento que descreve qual plataforma usar se nenhuma estiver definida ou quais flags definir quando uma plataforma já existir. Precisa ser relativo à raiz do espaço de trabalho principal. O padrão é "platform_mappings", um arquivo diretamente na raiz do espaço de trabalho.
Tags:
affects_outputs,changes_inputs,loading_and_analysis,non_configurable --platforms=<a build target label>padrão: ""-
Os rótulos das regras de plataforma que descrevem as plataformas de destino para o comando atual.
--python_path=<a string>padrão: consulte a descrição-
O caminho absoluto do interpretador Python invocado para executar destinos Python na plataforma de destino. Obsoleto. Desativado por --incompatible_use_python_toolchains.
--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Especifica a versão do SDK do tvOS a ser usada para criar aplicativos desse sistema operacional. Se não for especificado, usará a versão padrão do SDK do tvOS de "xcode_version".
Tags:
loses_incremental_state --[no]use_platforms_in_apple_crosstool_transitionpadrão: "false"-
Faz com que apple_crosstool_transition volte a usar o valor da flag
--platformsem vez do--cpulegado quando necessário.Tags:
loading_and_analysis --watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Especifica a versão do SDK do watchOS a ser usada para criar aplicativos do watchOS. Se não for especificado, usará a versão padrão do SDK do watchOS de "xcode_version".
Tags:
loses_incremental_state --xcode_version=<a string>padrão: consulte a descrição-
Se especificado, usa o Xcode da versão fornecida para ações de build relevantes. Se não for especificado, vai usar a versão padrão do executor do Xcode.
Tags:
loses_incremental_state --xcode_version_config=<a build target label>default: "@bazel_tools//tools/cpp:host_xcodes"-
O rótulo da regra xcode_config a ser usada para selecionar a versão do Xcode na configuração de build.
- Opções que controlam a saída do comando:
--[no]apple_generate_dsympadrão: "false"-
Se é necessário gerar arquivos de símbolos de depuração (.dSYM).
--[no]build_runfile_linkspadrão: "true"-
Se for verdadeiro, vai criar florestas de symlink de runfiles para todos os destinos. Se for "false", grave-os apenas quando exigido por uma ação, teste ou comando de execução local.
Tags:
affects_outputs --[no]build_runfile_manifestspadrão: "true"-
Se verdadeiro, grava manifestos de runfiles para todos os destinos. Se for "false", omita-os. Os testes locais não serão executados quando for "false".
Tags:
affects_outputs --[no]build_test_dwppadrão: "false"-
Se ativado, ao criar testes em C++ de forma estática e com fusão, o arquivo .dwp do binário de teste também será criado automaticamente.
--cc_proto_library_header_suffixes=<comma-separated set of options>padrão: ".pb.h"-
Define os sufixos dos arquivos de cabeçalho que uma cc_proto_library cria.
- Padrão de
--cc_proto_library_source_suffixes=<comma-separated set of options>: ".pb.cc" -
Define os sufixos dos arquivos de origem que uma cc_proto_library cria.
--[no]experimental_proto_descriptor_sets_include_source_infopadrão: "false"-
Executa ações extras para versões alternativas da API Java em uma proto_library.
--[no]experimental_save_feature_statepadrão: "false"-
Salve o estado dos recursos ativados e solicitados como uma saída da compilação.
Tags:
affects_outputs,experimental --fission=<a set of compilation modes>padrão: "no"-
Especifica quais modos de compilação usam a fissão para compilações e vinculações em C++. Pode ser qualquer combinação de {'fastbuild', 'dbg', 'opt'} ou os valores especiais 'yes' para ativar todos os modos e 'no' para desativar todos os modos.
Tags:
loading_and_analysis,action_command_lines,affects_outputs --[no]incompatible_always_include_files_in_datapadrão: "true"-
Se for verdadeiro, as regras nativas vão adicionar <code>DefaultInfo.files</code> de dependências de dados aos runfiles, o que corresponde ao comportamento recomendado para regras do Starlark (https://bazel.build/extending/rules#runfiles_features_to_avoid).
--[no]incompatible_compact_repo_mapping_manifestpadrão: "false"-
Se ativado, o arquivo <binary>.repo_mapping vai emitir o mapeamento de repositório de uma extensão de módulo apenas uma vez, em vez de uma vez para cada repositório gerado pela extensão que contribui com runfiles.
--incompatible_disable_select_on=<comma-separated set of options>padrão: ""-
Lista de flags para as quais o uso em select() está desativado.
Tags:
loading_and_analysis,incompatible_change,non_configurable --[no]incompatible_filegroup_runfiles_for_datapadrão: "true"-
Se for verdadeiro, os runfiles dos destinos listados no atributo "srcs" estarão disponíveis para os destinos que consomem o filegroup como uma dependência de dados.
Tags:
incompatible_change --[no]objc_generate_linkmappadrão: "false"-
Especifica se um arquivo linkmap será gerado.
Tags:
affects_outputs --[no]save_tempspadrão: "false"-
Se definido, as saídas temporárias do gcc serão salvas. Eles incluem arquivos .s (código de assembler), .i (C pré-processado) e .ii (C++ pré-processado).
Tags:
affects_outputs
- Opções que permitem ao usuário configurar a saída pretendida, afetando o valor dela, e não a existência:
--action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable>vários usos são acumulados-
Especifica o conjunto de variáveis de ambiente disponíveis para ações com configuração de destino. As variáveis podem ser especificadas por <code>name</code>, em que o valor é extraído do ambiente de invocação, pelo par <code>name=value</code>, que define o valor independente do ambiente de invocação, ou por <code>=name</code>, que desativa a variável com esse nome. Essa opção pode ser usada várias vezes. Para opções fornecidas para a mesma variável, a mais recente vence. Para variáveis diferentes, as opções são acumuladas. <br> A menos que <code>--incompatible_repo_env_ignores_action_env</code> seja verdadeiro, todos os pares <code>name=value</code> estarão disponíveis para as regras do repositório.
Tags:
action_command_lines --allowed_cpu_values=<comma-separated set of options>padrão: ""-
Valores permitidos para a flag "--cpu".
Tags:
changes_inputs,affects_outputs --[no]android_databinding_use_androidxpadrão: "true"-
Gere arquivos de vinculação de dados compatíveis com o AndroidX. Isso só é usado com a vinculação de dados v2. Essa flag não faz nada.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --[no]android_databinding_use_v3_4_argspadrão: "true"-
Use a vinculação de dados do Android v2 com o argumento 3.4.0. Essa flag não faz nada.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --android_dynamic_mode=<off, default or fully>padrão: "off"-
Determina se as dependências C++ das regras do Android serão vinculadas dinamicamente quando um cc_binary não criar explicitamente uma biblioteca compartilhada. "default" significa que o bazel vai escolher se a vinculação será dinâmica. "Totalmente" significa que todas as bibliotecas serão vinculadas dinamicamente. "off" significa que todas as bibliotecas serão vinculadas principalmente no modo estático.
- Padrão de
--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency>: "alphabetical" -
Define a ordem dos manifestos transmitidos à ferramenta de mescla de manifestos para binários do Android. ALPHABETICAL significa que os manifestos são classificados por caminho em relação ao execroot. ALPHABETICAL_BY_CONFIGURATION significa que os manifestos são classificados por caminhos relativos ao diretório de configuração no diretório de saída. DEPENDENCY significa que os manifestos são ordenados com o manifesto de cada biblioteca antes dos manifestos das dependências dela.
Tags:
action_command_lines,execution --[no]android_resource_shrinkingpadrão: "false"-
Ativa a redução de recursos para APKs android_binary que usam o ProGuard.
--[no]build_python_zippadrão: "auto"-
Criar zip executável do Python; ativado no Windows, desativado em outras plataformas
Tags:
affects_outputs --catalyst_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar binários do Apple Catalyst.
--[no]collect_code_coveragepadrão: "false"-
Se especificado, o Bazel vai instrumentar o código (usando instrumentação off-line sempre que possível) e coletar informações de cobertura durante os testes. Apenas os destinos que correspondem a --instrumentation_filter serão afetados. Normalmente, essa opção não deve ser especificada diretamente. Em vez disso, use o comando "bazel coverage".
Tags:
affects_outputs --compilation_mode=<fastbuild, dbg or opt>[-c] padrão: "fastbuild"-
Especifique o modo em que o binário será criado. Valores: "fastbuild", "dbg", "opt".
--conlyopt=<a string>vários usos são acumulados-
Opção adicional para transmitir ao gcc ao compilar arquivos de origem C.
--copt=<a string>vários usos são acumulados-
Outras opções para transmitir ao gcc.
--cpu=<a string>padrão: ""-
Descontinuada: essa flag não é usada internamente pelo Blaze, embora haja mapeamentos de plataforma legados para permitir a compatibilidade com versões anteriores. Não use essa flag. Em vez disso, use --platforms com uma definição de plataforma adequada.
Tags:
changes_inputs,affects_outputs --cs_fdo_absolute_path=<a string>padrão: consulte a descrição-
Use informações de perfil do CSFDO para otimizar a compilação. Especifique o nome do caminho absoluto do arquivo ZIP que contém o arquivo de perfil, um arquivo de perfil LLVM bruto ou indexado.
Tags:
affects_outputs --cs_fdo_instrument=<a string>padrão: consulte a descrição-
Gere binários com instrumentação FDO sensível ao contexto. Com o compilador Clang/LLVM, ele também aceita o nome do diretório em que os arquivos de perfil brutos serão despejados durante a execução.
Tags:
affects_outputs --cs_fdo_profile=<a build target label>padrão: consulte a descrição-
O cs_fdo_profile que representa o perfil sensível ao contexto a ser usado para otimização.
Tags:
affects_outputs --cxxopt=<a string>vários usos são acumulados-
Opção extra para transmitir ao gcc ao compilar arquivos de origem C++.
--define=<a 'name=value' assignment>vários usos são acumulados-
Cada opção "--define" especifica uma atribuição para uma variável de build. Em caso de vários valores para uma variável, o último vence.
Tags:
changes_inputs,affects_outputs --dynamic_mode=<off, default or fully>padrão: "default"-
Determina se os binários C++ serão vinculados dinamicamente. "default" significa que o Bazel vai escolher se a vinculação será dinâmica. "Totalmente" significa que todas as bibliotecas serão vinculadas dinamicamente. "off" significa que todas as bibliotecas serão vinculadas principalmente no modo estático.
--[no]enable_propeller_optimize_absolute_pathspadrão: "true"-
Se definido, qualquer uso de caminhos absolutos para a otimização do Propeller vai gerar um erro.
Tags:
affects_outputs --[no]enable_remaining_fdo_absolute_pathspadrão: "true"-
Se definido, qualquer uso de caminhos absolutos para FDO vai gerar um erro.
Tags:
affects_outputs --[no]enable_runfilespadrão: "auto"-
Ative a árvore de symlink de runfiles. Por padrão, ela fica desativada no Windows e ativada em outras plataformas.
Tags:
affects_outputs --exec_aspects=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de aspectos a serem aplicados a destinos configurados por execução, sejam eles de nível superior ou não. Este é um recurso experimental e está sujeito a mudanças.
Tags:
loading_and_analysis --experimental_action_listener=<a build target label>vários usos são acumulados-
Obsoleto, substituído por "aspectos". Use action_listener para anexar uma extra_action a ações de build atuais.
Tags:
execution,experimental --[no]experimental_android_compress_java_resourcespadrão: "false"-
Compactar recursos Java em APKs
--[no]experimental_android_databinding_v2padrão: "true"-
Use a vinculação de dados do Android v2. Essa flag não faz nada.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --[no]experimental_android_resource_shrinkingpadrão: "false"-
Ativa a redução de recursos para APKs android_binary que usam o ProGuard.
--[no]experimental_android_rewrite_dexes_with_rexpadrão: "false"-
usar a ferramenta rex para reescrever arquivos dex
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --[no]experimental_collect_code_coverage_for_generated_filespadrão: "false"-
Se especificado, o Bazel também vai gerar informações de cobertura de coleta para arquivos gerados.
Tags:
affects_outputs,experimental --experimental_objc_fastbuild_options=<comma-separated list of options>padrão: "-O0,-DDEBUG=1"-
Usa essas strings como opções do compilador objc fastbuild.
Tags:
action_command_lines --[no]experimental_omitfppadrão: "false"-
Se for verdadeiro, use libunwind para desenrolar a pilha e compile com -fomit-frame-pointer e -fasynchronous-unwind-tables.
--experimental_output_paths=<off or strip>padrão: "off"-
Qual modelo usar para onde as regras da árvore de saída gravam as saídas, principalmente para builds multiplataforma / multiconfiguração. Esse recurso é altamente experimental. Consulte https://github.com/bazelbuild/bazel/issues/6526 para mais detalhes. As ações do Starlark podem ativar o mapeamento de caminhos adicionando a chave "supports-path-mapping" ao dicionário "execution_requirements".
Tags:
loses_incremental_state,bazel_internal_configuration,affects_outputs,execution --experimental_override_platform_cpu_name=<a 'label=value' assignment>vários usos são acumulados-
Cada entrada precisa estar no formato "label=value", em que "label" se refere a uma plataforma e "value" é o nome abreviado desejado para substituir o nome da CPU da plataforma na variável de make $(TARGET_CPU) e no caminho de saída. Usado somente quando --experimental_platform_in_output_dir, --incompatible_target_cpu_from_platform ou --incompatible_bep_cpu_from_platform é verdadeiro. Tem a maior prioridade de nomenclatura.
Tags:
affects_outputs,experimental --[no]experimental_platform_in_output_dirpadrão: "false"-
Se for "true", um nome abreviado para a plataforma de destino será usado no nome do diretório de saída em vez da CPU. Se for "auto", isso só será aplicado à configuração de execução. O esquema exato é experimental e está sujeito a mudanças. Primeiro, no caso raro em que a opção "--platforms" não tem exatamente um valor, um hash da opção "platforms" é usado. Em seguida, se um nome abreviado para a plataforma atual foi registrado por --experimental_override_name_platform_in_output_dir, esse nome abreviado será usado. Em seguida, se --experimental_use_platforms_in_output_dir_legacy_heuristic estiver definido, use um nome abreviado com base no rótulo da plataforma atual. Por fim, um hash da opção de plataforma é usado como último recurso.
Tags:
affects_outputs,experimental --[no]experimental_py_binaries_include_labelpadrão: "false"-
Os destinos py_binary incluem o rótulo mesmo quando a inclusão de carimbos está desativada.
Tags:
affects_outputs,experimental --[no]experimental_use_llvm_covmappadrão: "false"-
Se especificado, o Bazel vai gerar informações de mapa de cobertura llvm-cov em vez de gcov quando collect_code_coverage estiver ativado.
Tags:
changes_inputs,affects_outputs,loading_and_analysis,experimental --[no]experimental_use_platforms_in_output_dir_legacy_heuristicpadrão: "true"-
Use essa flag apenas como parte de uma estratégia de migração ou teste sugerida. A heurística tem deficiências conhecidas. Por isso, recomendamos migrar para usar apenas --experimental_override_name_platform_in_output_dir.
Tags:
affects_outputs,experimental --fdo_instrument=<a string>padrão: consulte a descrição-
Gere binários com instrumentação FDO. Com o compilador Clang/LLVM, ele também aceita o nome do diretório em que os arquivos de perfil brutos serão despejados durante a execução.
Tags:
affects_outputs --fdo_optimize=<a string>padrão: consulte a descrição-
Use informações de perfil da FDO para otimizar a compilação. Especifique o nome de um arquivo zip que contenha uma árvore de arquivos .gcda, um arquivo afdo com um perfil automático ou um arquivo de perfil LLVM. Essa flag também aceita arquivos especificados como rótulos (por exemplo,
//foo/bar:file.afdo. Talvez seja necessário adicionar uma diretivaexports_filesao pacote correspondente) e rótulos que apontam para destinosfdo_profile. Essa flag será substituída pela regrafdo_profile.Tags:
affects_outputs --fdo_prefetch_hints=<a build target label>padrão: consulte a descrição-
Use dicas de pré-busca de cache.
Tags:
affects_outputs --fdo_profile=<a build target label>padrão: consulte a descrição-
O fdo_profile que representa o perfil a ser usado para otimização.
Tags:
affects_outputs --features=<a string>vários usos são acumulados-
Os recursos especificados serão ativados ou desativados por padrão para destinos criados na configuração de destino. Especificar -<recurso> desativa o recurso. Recursos negativos sempre substituem os positivos. Consulte também --host_features
Tags:
changes_inputs,affects_outputs --[no]force_picpadrão: "false"-
Se ativada, todas as compilações em C++ produzem código independente de posição ("-fPIC"), as vinculações preferem bibliotecas pré-criadas PIC em vez de bibliotecas não PIC, e as vinculações produzem executáveis independentes de posição ("-pie").
--host_action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable>vários usos são acumulados-
Especifica o conjunto de variáveis de ambiente disponíveis para ações com configurações de execução. As variáveis podem ser especificadas por nome, caso em que o valor será extraído do ambiente de invocação, pelo par nome=valor, que define o valor independente do ambiente de invocação, ou por <code>=name</code>, que desativa a variável desse nome. Essa opção pode ser usada várias vezes. Para opções fornecidas para a mesma variável, a mais recente vence. Para variáveis diferentes, as opções são acumuladas.
Tags:
action_command_lines --host_compilation_mode=<fastbuild, dbg or opt>padrão: "opt"-
Especifique o modo em que as ferramentas usadas durante a criação serão criadas. Valores: "fastbuild", "dbg", "opt".
--host_conlyopt=<a string>vários usos são acumulados-
Opção extra para transmitir ao compilador C ao compilar arquivos de origem C (mas não C++) nas configurações de execução.
--host_copt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas ao compilador C para ferramentas criadas nas configurações de execução.
--host_cpu=<a string>padrão: ""-
A CPU do host.
Tags:
changes_inputs,affects_outputs --host_cxxopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas ao compilador C++ para ferramentas criadas nas configurações de execução.
--host_features=<a string>vários usos são acumulados-
Os recursos especificados serão ativados ou desativados por padrão para destinos criados na configuração de execução. Especificar -<recurso> desativa o recurso. Recursos negativos sempre substituem os positivos.
Tags:
changes_inputs,affects_outputs --host_linkopt=<a string>vários usos são acumulados-
Opção extra para transmitir ao vinculador ao vincular ferramentas nas configurações de execução.
--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do macOS para destinos de host. Se não for especificado, usará "macos_sdk_version".
Tags:
loses_incremental_state --host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>vários usos são acumulados-
Outras opções para transmitir seletivamente ao compilador C/C++ ao compilar determinados arquivos nas configurações de execução. Essa opção pode ser transmitida várias vezes. Sintaxe: regex_filter@option_1,option_2,...,option_n. Em que regex_filter representa uma lista de padrões de expressões regulares de inclusão e exclusão (consulte também --instrumentation_filter). option_1 a option_n representam opções arbitrárias de linha de comando. Se uma opção tiver uma vírgula, ela precisa ser colocada entre aspas com uma barra invertida. As opções podem conter @. Somente o primeiro @ é usado para dividir a string. Exemplo: --host_per_file_copt=//foo/.*.cc,-//foo/bar.cc@-O0 adiciona a opção de linha de comando -O0 à linha de comando do gcc de todos os arquivos cc em //foo/, exceto bar.cc.
--[no]incompatible_auto_exec_groupspadrão: "false"-
Quando ativado, um grupo de execução é criado automaticamente para cada cadeia de ferramentas usada por uma regra. Para que isso funcione, a regra precisa especificar o parâmetro
toolchainnas ações dela. Para mais informações, consulte https://github.com/bazelbuild/bazel/issues/17134. --[no]incompatible_merge_genfiles_directorypadrão: "true"-
Se for verdadeiro, o diretório "genfiles" será incorporado ao diretório "bin".
--[no]incompatible_target_cpu_from_platformpadrão: "true"-
Se especificado, o valor da restrição de CPU (@platforms//cpu:cpu) da plataforma de destino será usado para definir a variável de criação $(TARGET_CPU).
--[no]instrument_test_targetspadrão: "false"-
Quando a cobertura está ativada, especifica se as regras de teste de instrumentação devem ser consideradas. Quando definido, as regras de teste incluídas por --instrumentation_filter são instrumentadas. Caso contrário, as regras de teste são sempre excluídas da instrumentação de cobertura.
Tags:
affects_outputs --instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>padrão: "-/javatests[/:],-/test/java[/:]"-
Quando a cobertura está ativada, apenas as regras com nomes incluídos pelo filtro especificado baseado em regex são instrumentadas. As regras com o prefixo "-" são excluídas. Somente regras que não são de teste são instrumentadas, a menos que a flag --instrument_test_targets esteja ativada.
Tags:
affects_outputs --ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do iOS para simuladores e dispositivos de destino. Se não for especificado, usará "ios_sdk_version".
Tags:
loses_incremental_state --ios_multi_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar um ios_application. O resultado é um binário universal que contém todas as arquiteturas especificadas.
--[no]legacy_whole_archivepadrão: "true"-
Obsoleto, substituído por --incompatible_remove_legacy_whole_archive. Consulte https://github.com/bazelbuild/bazel/issues/7362 para mais detalhes. Quando ativada, use --whole-archive para regras cc_binary que tenham linkshared=True e linkstatic=True ou "-static" em linkopts. Isso é apenas para compatibilidade com versões anteriores. Uma alternativa melhor é usar alwayslink=1 quando necessário.
--linkopt=<a string>vários usos são acumulados-
Opção extra a ser transmitida para o gcc ao vincular.
--ltobackendopt=<a string>vários usos são acumulados-
Opção adicional para transmitir à etapa de back-end do LTO (em --features=thin_lto).
--ltoindexopt=<a string>vários usos são acumulados-
Opção adicional para transmitir à etapa de indexação do LTO (em --features=thin_lto).
--macos_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para as quais criar binários do Apple macOS.
--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do macOS para destinos. Se não for especificado, usará "macos_sdk_version".
Tags:
loses_incremental_state --memprof_profile=<a build target label>padrão: consulte a descrição-
Usar o perfil memprof.
Tags:
affects_outputs --[no]objc_debug_with_GLIBCXXpadrão: "false"-
Se definido e o modo de compilação for "dbg", defina GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC e GLIBCPP_CONCEPT_CHECKS.
Tags:
action_command_lines --[no]objc_enable_binary_strippingpadrão: "false"-
Se é necessário realizar remoções de símbolos e código morto em binários vinculados. A remoção de binários será realizada se esta flag e --compilation_mode=opt forem especificadas.
Tags:
action_command_lines --objccopt=<a string>vários usos são acumulados-
Opções extras a serem transmitidas para o gcc ao compilar arquivos de origem Objective-C/C++.
Tags:
action_command_lines --per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>vários usos são acumulados-
Outras opções para transmitir seletivamente ao gcc ao compilar determinados arquivos. Essa opção pode ser transmitida várias vezes. Sintaxe: regex_filter@option_1,option_2,...,option_n. Em que regex_filter representa uma lista de padrões de expressões regulares de inclusão e exclusão (consulte também --instrumentation_filter). option_1 a option_n representam opções arbitrárias de linha de comando. Se uma opção tiver uma vírgula, ela precisa ser colocada entre aspas com uma barra invertida. As opções podem conter @. Somente o primeiro @ é usado para dividir a string. Exemplo: --per_file_copt=//foo/.*.cc,-//foo/bar.cc@-O0 adiciona a opção de linha de comando -O0 à linha de comando gcc de todos os arquivos cc em //foo/, exceto bar.cc.
--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>vários usos são acumulados-
Outras opções para transmitir seletivamente ao back-end do LTO (em --features=thin_lto) ao compilar determinados objetos de back-end. Essa opção pode ser transmitida várias vezes. Sintaxe: regex_filter@option_1,option_2,...,option_n. Em que regex_filter representa uma lista de padrões de expressão regular de inclusão e exclusão, e option_1 a option_n representam opções arbitrárias de linha de comando. Se uma opção tiver uma vírgula, ela precisa ser colocada entre aspas com uma barra invertida. As opções podem conter @. Somente o primeiro @ é usado para dividir a string. Exemplo: --per_file_ltobackendopt=//foo/.*.o,-//foo/bar.o@-O0 adiciona a opção de linha de comando -O0 à linha de comando do back-end LTO de todos os arquivos o em //foo/, exceto bar.o.
--platform_suffix=<a string>padrão: consulte a descrição-
Especifica um sufixo a ser adicionado ao diretório de configuração.
Tags:
loses_incremental_state,affects_outputs,loading_and_analysis --propeller_optimize=<a build target label>padrão: consulte a descrição-
Use as informações do perfil do Propeller para otimizar o destino do build.Um perfil do Propeller precisa consistir em pelo menos um de dois arquivos: um perfil cc e um perfil ld. Essa flag aceita um rótulo de build que precisa se referir aos arquivos de entrada do perfil do Propeller. Por exemplo, o arquivo BUILD que define o rótulo, em a/b/BUILD:propeller_optimize( name = "propeller_profile", cc_profile = "propeller_cc_profile.txt", ld_profile = "propeller_ld_profile.txt",)Talvez seja necessário adicionar uma diretiva exports_files ao pacote correspondente para tornar esses arquivos visíveis ao Bazel. A opção precisa ser usada como: --propeller_optimize=//a/b:propeller_profile
--propeller_optimize_absolute_cc_profile=<a string>padrão: consulte a descrição-
Nome do caminho absoluto do arquivo cc_profile para builds otimizados do Propeller.
Tags:
affects_outputs --propeller_optimize_absolute_ld_profile=<a string>padrão: consulte a descrição-
Nome do caminho absoluto do arquivo ld_profile para builds otimizados do Propeller.
Tags:
affects_outputs --run_under=<a prefix in front of command>padrão: consulte a descrição-
Prefixo a ser inserido antes dos executáveis dos comandos "test" e "run". Se o valor for "foo -bar" e a linha de comando de execução for "test_binary -baz", a linha de comando final será "foo -bar test_binary -baz".Isso também pode ser um rótulo para um destino executável. Alguns exemplos são: "valgrind", "strace", "strace -c", "valgrind --quiet --num-callers=20", "//package:target", "//package:target --options".
Tags:
action_command_lines -
Se for "true", as bibliotecas nativas com funcionalidade idêntica serão compartilhadas entre diferentes destinos.
--[no]stamppadrão: "false"-
Adicionar carimbo aos binários com a data, o nome de usuário, o nome do host, as informações do espaço de trabalho etc.
Tags:
affects_outputs - Padrão de
--strip=<always, sometimes or never>: "sometimes" -
Especifica se os binários e as bibliotecas compartilhadas devem ser removidos (usando "-Wl,--strip-debug"). O valor padrão "sometimes" significa remover se --compilation_mode=fastbuild.
Tags:
affects_outputs --stripopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas para a remoção ao gerar um binário "<name>.stripped".
--tvos_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar binários do Apple tvOS.
--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do tvOS para simuladores e dispositivos de destino. Se não for especificado, usará "tvos_sdk_version".
Tags:
loses_incremental_state --visionos_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar binários do Apple visionOS.
--watchos_cpus=<comma-separated list of options>vários usos são acumulados-
Lista separada por vírgulas de arquiteturas para criar binários do Apple watchOS.
--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
Versão mínima compatível do watchOS para simuladores e dispositivos de destino. Se não for especificado, usará "watchos_sdk_version".
Tags:
loses_incremental_state --xbinary_fdo=<a build target label>padrão: consulte a descrição-
Use informações de perfil do XbinaryFDO para otimizar a compilação. Especifique o nome do perfil binário cruzado padrão. Quando a opção é usada com --fdo_instrument/--fdo_optimize/--fdo_profile, essas opções sempre prevalecem como se xbinary_fdo nunca fosse especificado.
Tags:
affects_outputs
- Opções que afetam a rigidez com que o Bazel aplica entradas de build válidas (definições de regras, combinações de flags etc.):
--[no]check_visibilitypadrão: "true"-
Se desativado, os erros de visibilidade nas dependências de destino serão rebaixados para avisos.
--[no]desugar_for_androidpadrão: "true"-
Define se o bytecode Java 8 deve ser simplificado antes da conversão para DEX.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state --[no]desugar_java8_libspadrão: "false"-
Se as bibliotecas Java 8 compatíveis devem ser incluídas em apps para dispositivos legados.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state,experimental --[no]enforce_constraintspadrão: "true"-
Verifica os ambientes com que cada destino é compatível e informa erros se algum destino tiver dependências que não oferecem suporte aos mesmos ambientes.
Tags:
build_file_semantics --[no]experimental_check_desugar_depspadrão: "true"-
Se é necessário verificar novamente a dessugarização correta no nível binário do Android.
--[no]experimental_enforce_transitive_visibilitypadrão: "false"-
Se verdadeiro, permite que package()s definam o atributo transitive_visibility para restringir quais pacotes podem depender deles.
Tags:
build_file_semantics,experimental --experimental_one_version_enforcement=<off, warning or error>padrão: "OFF"-
Quando ativada, essa opção exige que uma regra java_binary não contenha mais de uma versão do mesmo arquivo de classe no classpath. Essa aplicação pode interromper o build ou apenas resultar em avisos.
Tags:
loading_and_analysis --experimental_strict_java_deps=<off, warn, error, strict or default>padrão: "default"-
Se for verdadeiro, verifica se um destino Java declara explicitamente todos os destinos usados diretamente como dependências.
--[no]incompatible_check_testonly_for_output_filespadrão: "false"-
Se ativado, verifique testonly para destinos de pré-requisito que são arquivos de saída pesquisando o testonly da regra geradora. Isso corresponde à verificação de visibilidade.
--[no]incompatible_disable_native_android_rulespadrão: "false"-
Se ativada, o uso direto das regras nativas do Android será desativado. Use as regras do Starlark Android em https://github.com/bazelbuild/rules_android
--[no]incompatible_disable_native_apple_binary_rulepadrão: "false"-
Não faz nada. Mantido aqui para compatibilidade com versões anteriores.
--[no]one_version_enforcement_on_java_testspadrão: "true"-
Quando ativada e com experimental_one_version_enforcement definido como um valor diferente de NONE, impõe uma versão em destinos java_test. Essa flag pode ser desativada para melhorar a performance do teste incremental, mas isso pode fazer com que possíveis violações de uma versão sejam perdidas.
Tags:
loading_and_analysis --python_native_rules_allowlist=<a build target label>padrão: consulte a descrição-
Uma lista de permissões (destino package_group) a ser usada ao aplicar --incompatible_python_disallow_native_rules.
Tags:
loading_and_analysis --[no]strict_filesetspadrão: "false"-
Se essa opção estiver ativada, os conjuntos de arquivos que cruzam os limites do pacote serão informados como erros.
--strict_proto_deps=<off, warn, error, strict or default>padrão: "error"-
A menos que esteja OFF, verifica se um destino proto_library declara explicitamente todos os destinos usados diretamente como dependências.
Tags:
build_file_semantics,eagerness_to_exit,incompatible_change --strict_public_imports=<off, warn, error, strict or default>padrão: "off"-
A menos que esteja OFF, verifica se um destino proto_library declara explicitamente como exportados todos os destinos usados em "import public".
Tags:
build_file_semantics,eagerness_to_exit,incompatible_change --[no]strict_system_includespadrão: "false"-
Se for "true", os cabeçalhos encontrados por caminhos de inclusão do sistema (-isystem) também precisarão ser declarados.
--target_environment=<a build target label>vários usos são acumulados-
Declara o ambiente de destino deste build. Precisa ser uma referência de rótulo a uma regra de "ambiente". Se especificado, todos os destinos de nível superior precisam ser compatíveis com esse ambiente.
Tags:
changes_inputs
- Opções que afetam as saídas de assinatura de um build:
--apk_signing_method=<v1, v2, v1_v2 or v4>padrão: "v1_v2"-
Implementação a ser usada para assinar APKs
Tags:
action_command_lines,affects_outputs,loading_and_analysis --[no]device_debug_entitlementspadrão: "true"-
Se definido e o modo de compilação não for "opt", os apps objc vão incluir direitos de depuração ao assinar.
Tags:
changes_inputs --ios_signing_cert_name=<a string>padrão: consulte a descrição-
Nome do certificado a ser usado para assinatura do iOS. Se não for definido, vai voltar ao perfil de provisionamento. Pode ser a preferência de identidade do chaveiro do certificado ou (substring) do nome comum do certificado, conforme a página de manual do codesign (IDENTIDADES DE ASSINATURA).
Tags:
action_command_lines
- Essa opção afeta a semântica da linguagem Starlark ou a API de build acessível a arquivos BUILD, .bzl ou WORKSPACE.:
--[no]incompatible_disallow_sdk_frameworks_attributespadrão: "false"-
Se for "true", não permita os atributos sdk_frameworks e weak_sdk_frameworks em objc_library e objc_import.
--[no]incompatible_objc_alwayslink_by_defaultpadrão: "false"-
Se for verdadeiro, defina o valor padrão como verdadeiro para atributos alwayslink em objc_library e objc_import.
--[no]incompatible_python_disallow_native_rulespadrão: "false"-
Quando verdadeiro, um erro ocorre ao usar as regras py_* integradas. Em vez disso, as regras rule_python devem ser usadas. Consulte https://github.com/bazelbuild/bazel/issues/17773 para mais informações e instruções de migração.
- Opções que regem o comportamento do ambiente de teste ou do executor de testes:
--[no]allow_analysis_failurespadrão: "false"-
Se for "true", uma falha na análise de um destino de regra vai resultar na propagação de uma instância de "AnalysisFailureInfo" contendo a descrição do erro, em vez de resultar em uma falha de build.
Tags:
loading_and_analysis,experimental - Padrão de
--analysis_testing_deps_limit=<an integer>: "2000" -
Define o número máximo de dependências transitivas usando um atributo de regra com uma transição de configuração for_analysis_testing. Exceder esse limite vai resultar em um erro de regra.
Tags:
loading_and_analysis --[no]break_build_on_parallel_dex2oat_failurepadrão: "false"-
Se for "true", as falhas na ação dex2oat vão interromper o build em vez de executar dex2oat durante o tempo de execução do teste.
Tags:
loading_and_analysis,experimental --default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100>vários usos são acumulados-
Substitua a quantidade padrão de recursos para testes. O formato esperado é <resource>=<value>. Se um único número positivo for especificado como <value>, ele vai substituir os recursos padrão para todos os tamanhos de teste. Se quatro números separados por vírgulas forem especificados, eles vão substituir a quantidade de recursos para os tamanhos de teste pequeno, médio, grande e enorme, respectivamente. Os valores também podem ser HOST_RAM/HOST_CPU, seguidos opcionalmente por [-|]<float> (por exemplo, memory=HOST_RAM.1,HOST_RAM*.2,HOST_RAM*.3,HOST_RAM*.4). Os recursos de teste padrão especificados por essa flag são substituídos por recursos explícitos especificados em tags.
--[no]experimental_android_use_parallel_dex2oatpadrão: "false"-
Use dex2oat em paralelo para acelerar o android_test.
Tags:
loading_and_analysis,host_machine_resource_optimizations,experimental --[no]ios_memleakspadrão: "false"-
Ativa a verificação de vazamentos de memória em destinos ios_test.
Tags:
action_command_lines --ios_simulator_device=<a string>padrão: consulte a descrição-
O dispositivo a ser simulado ao executar um aplicativo iOS no simulador, por exemplo, "iPhone 6". Para conferir uma lista de dispositivos, execute "xcrun simctl list devicetypes" na máquina em que o simulador será executado.
Tags:
test_runner --ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>padrão: consulte a descrição-
A versão do iOS a ser executada no simulador durante a execução ou o teste. Isso é ignorado para regras ios_test se um dispositivo de destino for especificado na regra.
Tags:
test_runner --runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once>vários usos são acumulados-
Especifica o número de vezes que cada teste será executado. Se alguma dessas tentativas falhar por qualquer motivo, todo o teste será considerado falho. Normalmente, o valor especificado é apenas um número inteiro. Exemplo: --runs_per_test=3 vai executar todos os testes três vezes. Sintaxe alternativa: regex_filter@runs_per_test. Em que runs_per_test representa um valor inteiro e regex_filter representa uma lista de padrões de expressões regulares de inclusão e exclusão (consulte também --instrumentation_filter). Exemplo: --runs_per_test=//foo/.,-//foo/bar/.@3 executa todos os testes em //foo/, exceto aqueles em foo/bar, três vezes. Essa opção pode ser transmitida várias vezes. O argumento transmitido mais recentemente que corresponde tem precedência. Se nada corresponder, o teste será executado apenas uma vez.
--test_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable>vários usos são acumulados-
Especifica outras variáveis de ambiente a serem injetadas no ambiente do executor de testes. As variáveis podem ser especificadas por <code>name</code>, nesse caso, o valor será lido do ambiente do cliente Bazel, ou pelo par <code>name=value</code>. As variáveis definidas anteriormente podem ser desdefinidas usando <code>=name</code>. Essa opção pode ser usada várias vezes para especificar várias variáveis. Usado apenas pelo comando "bazel test".
Tags:
test_runner --test_timeout=<a single integer or comma-separated list of 4 integers>padrão: "-1"-
Substitui os valores padrão de tempo limite de teste para tempos limite de teste (em segundos). Se um único valor inteiro positivo for especificado, ele vai substituir todas as categorias. Se quatro números inteiros separados por vírgulas forem especificados, eles vão substituir os tempos limite para curto, moderado, longo e eterno (nessa ordem). Em qualquer uma das formas, um valor de -1 informa ao Blaze para usar os tempos limite padrão para essa categoria.
--[no]zip_undeclared_test_outputspadrão: "false"-
Se for "true", as saídas de teste não declaradas serão arquivadas em um arquivo ZIP.
Tags:
test_runner
- Opções que acionam otimizações do tempo de build:
--[no]experimental_filter_library_jar_with_program_jarpadrão: "false"-
Filtre o ProGuard ProgramJar para remover todas as classes também presentes no LibraryJar.
Tags:
action_command_lines,experimental --[no]experimental_inmemory_dotd_filespadrão: "true"-
Se ativada, os arquivos .d do C++ serão transmitidos na memória diretamente dos nós de build remoto em vez de serem gravados em disco.
Tags:
loading_and_analysis,execution,affects_outputs,experimental --[no]experimental_inmemory_jdeps_filespadrão: "true"-
Se ativada, os arquivos de dependência (.jdeps) gerados de compilações Java serão transmitidos na memória diretamente dos nós de build remoto em vez de serem gravados no disco.
Tags:
loading_and_analysis,execution,affects_outputs,experimental --[no]experimental_retain_test_configuration_across_testonlypadrão: "false"-
Quando ativada, a flag --trim_test_configuration não vai remover a configuração de teste para regras marcadas como testonly=1. Isso reduz problemas de conflito de ações quando regras que não são de teste dependem de regras cc_test. Não tem efeito se "--trim_test_configuration" for "false".
Tags:
loading_and_analysis,loses_incremental_state,experimental --[no]experimental_unsupported_and_brittle_include_scanningpadrão: "false"-
Indica se é necessário restringir as entradas à compilação em C/C++ analisando as linhas #include dos arquivos de entrada. Isso pode melhorar a performance e a incrementalidade, diminuindo o tamanho das árvores de entrada de compilação. No entanto, ele também pode interromper builds porque o scanner de inclusão não implementa totalmente a semântica do pré-processador C. Em particular, ele não entende diretivas #include dinâmicas e ignora a lógica condicional do pré-processador. Use por sua conta e risco. Todos os problemas relacionados a essa denúncia que forem enviados serão encerrados.
Tags:
loading_and_analysis,execution,changes_inputs,experimental --[no]incremental_dexingpadrão: "true"-
Faz a maior parte do trabalho de dexing separadamente para cada arquivo Jar.
Tags:
affects_outputs,loading_and_analysis,loses_incremental_state --[no]objc_use_dotd_pruningpadrão: "true"-
Se definido, os arquivos .d emitidos pelo clang serão usados para remover o conjunto de entradas transmitidas para compilações objc.
--[no]process_headers_in_dependenciespadrão: "false"-
Ao criar um destino //a:a, processe os cabeçalhos em todos os destinos de que //a:a depende (se o processamento de cabeçalho estiver ativado para a cadeia de ferramentas).
Tags:
execution --[no]trim_test_configurationpadrão: "true"-
Quando ativada, as opções relacionadas a testes serão limpas abaixo do nível superior do build. Quando essa flag está ativa, os testes não podem ser criados como dependências de regras que não são de teste, mas as mudanças nas opções relacionadas a testes não fazem com que as regras que não são de teste sejam analisadas novamente.
- Opções que afetam a verbosidade, o formato ou o local do registro em log:
- Padrão de
--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>: "-.*" -
Imprime informações de depuração durante a resolução da cadeia de ferramentas. A flag usa uma regex, que é verificada em relação a tipos de cadeia de ferramentas e destinos específicos para ver qual depurar. É possível separar várias expressões regulares com vírgulas, e cada uma delas é verificada separadamente. Observação: a saída dessa flag é muito complexa e provavelmente só será útil para especialistas em resolução de toolchain.
Tags:
terminal_output --[no]verbose_visibility_errorspadrão: "false"-
Se ativados, os erros de visibilidade incluem mais informações de diagnóstico.
- Opções que especificam ou alteram uma entrada genérica para um comando do Bazel que não se enquadra em outras categorias:
--flag_alias=<a 'name=value' flag alias>vários usos são acumulados-
Define um nome abreviado para uma flag do Starlark. Ele usa um único par de chave-valor no formato "<chave>=<valor>" como argumento.
Tags:
changes_inputs,non_configurable --[no]incompatible_default_to_explicit_init_pypadrão: "false"-
Essa flag muda o comportamento padrão para que os arquivos init.py não sejam mais criados automaticamente nos arquivos de execução de destinos Python. Precisamente, quando um destino py_binary ou py_test tem legacy_create_init definido como "auto" (o padrão), ele é tratado como falso se e somente se essa flag estiver definida. Consulte https://github.com/bazelbuild/bazel/issues/10076.
- Opções diversas, não categorizadas de outra forma:
--[no]cache_test_results[-t] padrão: "auto"-
Se definido como "auto", o Bazel vai executar novamente um teste somente se: (1) o Bazel detectar mudanças no teste ou nas dependências dele, (2) o teste for marcado como externo, (3) várias execuções de teste forem solicitadas com --runs_per_test ou(4) o teste falhou anteriormente. Se definido como "yes", o Bazel armazena em cache todos os resultados de testes, exceto aqueles marcados como externos. Se definido como "no", o Bazel não armazena em cache nenhum resultado de teste.
- Padrão de
--[no]experimental_cancel_concurrent_tests: "never" -
Se for "on_failed" ou "on_passed", o Blaze vai cancelar os testes em execução simultânea na primeira execução com esse resultado. Isso só é útil em combinação com --runs_per_test_detects_flakes.
--[no]experimental_fetch_all_coverage_outputspadrão: "false"-
Se for verdadeiro, o Bazel vai buscar todo o diretório de dados de cobertura para cada teste durante uma execução de cobertura.
--[no]experimental_generate_llvm_lcovpadrão: "false"-
Se for verdadeiro, a cobertura do clang vai gerar um relatório LCOV.
- Padrão de
--experimental_java_classpath=<off, javabuilder, bazel or bazel_no_fallback>: "bazel" -
Ativa caminhos de classe reduzidos para compilações Java.
--[no]experimental_run_android_lint_on_java_rulespadrão: "false"-
Se as fontes java_* precisam ser validadas.
Tags:
affects_outputs,experimental --[no]explicit_java_test_depspadrão: "false"-
Especifique explicitamente uma dependência do JUnit ou do Hamcrest em um java_test em vez de obter acidentalmente das dependências do TestRunner. No momento, só funciona para bazel.
--host_java_launcher=<a build target label>padrão: consulte a descrição-
O iniciador Java usado por ferramentas executadas durante um build.
--host_javacopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas para o javac ao criar ferramentas executadas durante um build.
--host_jvmopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas para a VM Java ao criar ferramentas executadas durante o build. Essas opções serão adicionadas às opções de inicialização da VM de cada destino java_binary.
--[no]incompatible_check_sharding_supportpadrão: "true"-
Se for verdadeiro, o Bazel vai falhar em um teste fragmentado se o executor de testes não indicar que oferece suporte à fragmentação ao tocar no arquivo no caminho em TEST_SHARD_STATUS_FILE. Se for "false", um executor de testes que não oferece suporte a fragmentação vai fazer com que todos os testes sejam executados em cada fragmento.
Tags:
incompatible_change --[no]incompatible_exclusive_test_sandboxedpadrão: "true"-
Se for verdadeiro, os testes exclusivos serão executados com a estratégia em sandbox. Adicione a tag "local" para forçar uma execução de teste exclusiva localmente
Tags:
incompatible_change --[no]incompatible_strict_action_envpadrão: "false"-
Se for "true", o Bazel usará um ambiente com um valor estático para PATH e não vai herdar LD_LIBRARY_PATH. Use --action_env=ENV_VARIABLE se quiser herdar variáveis de ambiente específicas do cliente, mas observe que isso pode impedir o armazenamento em cache entre usuários se um cache compartilhado for usado.
--j2objc_translation_flags=<comma-separated list of options>vários usos são acumulados-
Outras opções a serem transmitidas para a ferramenta J2ObjC.
--java_debug-
Faz com que a máquina virtual Java de um teste Java aguarde uma conexão de um depurador compatível com JDWP (como jdb) antes de iniciar o teste. Implica -test_output=streamed.
Expande para:
--test_arg=--wrapper_script_flag=--debug
--test_output=streamed
--test_strategy=exclusive
--test_timeout=9999
--nocache_test_results --[no]java_depspadrão: "true"-
Gere informações de dependência (por enquanto, classpath de tempo de compilação) por destino Java.
--[no]java_header_compilationpadrão: "true"-
Compile ijars diretamente da origem.
--java_language_version=<a string>padrão: ""-
A versão da linguagem Java
--java_launcher=<a build target label>padrão: consulte a descrição-
O inicializador Java a ser usado ao criar binários Java. Se essa flag for definida como uma string vazia, o iniciador do JDK será usado. O atributo "launcher" substitui essa flag.
- Padrão de
--java_runtime_version=<a string>: "local_jdk" -
A versão do ambiente de execução do Java
--javacopt=<a string>vários usos são acumulados-
Outras opções para transmitir ao javac.
--jvmopt=<a string>vários usos são acumulados-
Outras opções a serem transmitidas para a VM Java. Essas opções serão adicionadas às opções de inicialização da VM de cada destino java_binary.
--legacy_main_dex_list_generator=<a build target label>padrão: consulte a descrição-
Especifica um binário a ser usado para gerar a lista de classes que precisam estar no dex principal ao compilar o multidex legado.
--optimizing_dexer=<a build target label>padrão: consulte a descrição-
Especifica um binário a ser usado para fazer dexing sem sharding.
--plugin=<a build target label>vários usos são acumulados-
Plug-ins a serem usados no build. No momento, funciona com java_plugin.
--proguard_top=<a build target label>padrão: consulte a descrição-
Especifica qual versão do ProGuard usar para remoção de código ao criar um binário Java.
--proto_compiler=<a build target label>default: "@bazel_tools//tools/proto:protoc"-
O rótulo do proto-compilador.
--[no]proto_profilepadrão: "true"-
Se o profile_path será transmitido ao compilador proto.
--proto_profile_path=<a build target label>padrão: consulte a descrição-
O perfil a ser transmitido ao compilador proto como profile_path. Se não for definido, mas --proto_profile for verdadeiro (o padrão), vai inferir o caminho de --fdo_optimize.
--proto_toolchain_for_cc=<a build target label>default: "@bazel_tools//tools/proto:cc_toolchain"-
Rótulo de proto_lang_toolchain() que descreve como compilar protos C++
--proto_toolchain_for_j2objc=<a build target label>padrão: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain"-
Rótulo de proto_lang_toolchain() que descreve como compilar protos j2objc.
--proto_toolchain_for_java=<a build target label>default: "@bazel_tools//tools/proto:java_toolchain"-
Rótulo de proto_lang_toolchain() que descreve como compilar protos Java.
--proto_toolchain_for_javalite=<a build target label>default: "@bazel_tools//tools/proto:javalite_toolchain"-
Rótulo de proto_lang_toolchain() que descreve como compilar protos do JavaLite.
--protocopt=<a string>vários usos são acumulados-
Outras opções para transmitir ao compilador protobuf.
Tags:
affects_outputs --[no]runs_per_test_detects_flakespadrão: "false"-
Se for "true", qualquer fragmento em que pelo menos uma execução/tentativa seja aprovada e pelo menos uma execução/tentativa falhe vai receber o status "FLAKY".
--shell_executable=<a path>padrão: consulte a descrição-
Caminho absoluto para o executável do shell que o Bazel vai usar. Se não estiver definido, mas a variável de ambiente BAZEL_SH estiver definida na primeira invocação do Bazel (que inicia um servidor do Bazel), o Bazel vai usar essa variável. Se nenhum dos dois estiver definido, o Bazel usará um caminho padrão codificado, dependendo do sistema operacional em que ele é executado (Windows: c:/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, todos os outros: /bin/bash). Usar um shell incompatível com bash pode causar falhas de build ou de tempo de execução dos binários gerados.
Tags:
loading_and_analysis --test_arg=<a string>vários usos são acumulados-
Especifica outras opções e argumentos que devem ser transmitidos para o executável de teste. Pode ser usado várias vezes para especificar vários argumentos. Se vários testes forem executados, cada um deles vai receber argumentos idênticos. Usado apenas pelo comando "bazel test".
--test_filter=<a string>padrão: consulte a descrição-
Especifica um filtro para encaminhar ao framework de teste. Usado para limitar os testes executados. Isso não afeta quais destinos são criados.
--test_result_expiration=<an integer>padrão: "-1"-
Essa opção foi descontinuada e não tem efeito.
--[no]test_runner_fail_fastpadrão: "false"-
Encaminha a opção de falha rápida para o executor de testes. O executor de testes precisa interromper a execução na primeira falha.
--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce>padrão: "explicit"-
Especifique a estratégia para o sharding de teste: "explicit" para usar o sharding somente se o atributo "shard_count" BUILD estiver presente. "disabled" para nunca usar o sharding de teste. "forced=k" para forçar "k" fragmentos para teste, independente do atributo "shard_count" BUILD.
--tool_java_language_version=<a string>padrão: ""-
A versão da linguagem Java usada para executar as ferramentas necessárias durante um build.
--tool_java_runtime_version=<a string>padrão: "remotejdk_11"-
A versão do ambiente de execução Java usada para executar ferramentas durante o build.
--[no]use_ijarspadrão: "true"-
Se ativada, essa opção faz com que a compilação Java use jars de interface. Isso resulta em uma compilação incremental mais rápida, mas as mensagens de erro podem ser diferentes.
Opções de versão
- Opções que permitem ao usuário configurar a saída pretendida, afetando o valor dela, e não a existência:
--[no]gnu_formatpadrão: "false"-
Se definido, grava a versão em stdout usando as convenções descritas nos padrões GNU.
Tags:
affects_outputs,execution
Tags de efeito da opção
unknown |
Essa opção tem um efeito desconhecido ou não documentado. |
no_op |
Essa opção não tem efeito. |
loses_incremental_state |
Mudar o valor dessa opção pode causar uma perda significativa do estado incremental, o que deixa os builds mais lentos. O estado pode ser perdido devido a uma reinicialização do servidor ou à invalidação de uma grande parte do gráfico de dependências. |
changes_inputs |
Essa opção muda ativamente as entradas que o Bazel considera para o build, como restrições do sistema de arquivos, versões do repositório ou outras opções. |
affects_outputs |
Essa opção afeta as saídas do Bazel. Essa tag é intencionalmente ampla, pode incluir efeitos transitivos e não especifica o tipo de saída que afeta. |
build_file_semantics |
Essa opção afeta a semântica dos arquivos BUILD ou .bzl. |
bazel_internal_configuration |
Essa opção afeta as configurações da máquina interna do Bazel. Essa tag não significa, por si só, que os artefatos de build foram afetados. |
loading_and_analysis |
Essa opção afeta o carregamento e a análise de dependências, além da criação do gráfico de dependência. |
execution |
Essa opção afeta a fase de execução, como opções relacionadas a sandbox ou execução remota. |
host_machine_resource_optimizations |
Essa opção aciona uma otimização que pode ser específica da máquina e não tem garantia de funcionar em todas as máquinas. A otimização pode incluir uma troca com outros aspectos de performance, como custo de memória ou CPU. |
eagerness_to_exit |
Essa opção muda a rapidez com que o Bazel sai de uma falha, em que existe uma escolha entre continuar apesar da falha e encerrar a invocação. |
bazel_monitoring |
Essa opção é usada para monitorar o comportamento e a performance do Bazel. |
terminal_output |
Essa opção afeta a saída do terminal do Bazel. |
action_command_lines |
Essa opção muda os argumentos da linha de comando de uma ou mais ações de build. |
test_runner |
Essa opção muda o ambiente do testrunner do build. |
Tags de metadados de opção
experimental |
Essa opção aciona um recurso experimental sem garantias de funcionalidade. |
incompatible_change |
Essa opção causa uma mudança interruptiva. Use essa opção para testar se você está pronto para a migração ou ter acesso antecipado ao novo recurso |
deprecated |
O uso dessa opção foi suspenso. Talvez o recurso afetado esteja descontinuado ou outro método de fornecer as informações seja preferível. |
non_configurable |
Essa opção não pode ser alterada em uma transição nem usada em uma instrução select(). |