Nesta página, explicamos como criar um programa com o Bazel e a sintaxe do comando de build e a sintaxe do padrão de destino.
Guia de início rápido
Para executar o Bazel, acesse o diretório base workspace
ou qualquer um dos subdiretórios e digite bazel. Consulte build se precisar criar um novo espaço de trabalho.
bazel help
[Bazel release bazel version]
Usage: bazel command options ...
Comandos disponíveis
analyze-profile: analisa os dados do perfil do build.aquery: executa uma consulta no gráfico de ações pós-análise.build: cria os destinos especificados.canonicalize-flags: canoniza flags do Bazel.clean: remove os arquivos de saída e, opcionalmente, interrompe o servidor.cquery: executa uma consulta de gráfico de dependências de pós-análise.dump: despeja o estado interno do processo do servidor do Bazel.help: mostra a ajuda dos comandos ou do índice.info: mostra informações de tempo de execução sobre o servidor do Bazel.fetch: busca todas as dependências externas de um destino.mobile-install: instala apps em dispositivos móveis.query: executa uma consulta de gráfico de dependência.run: executa o destino especificado.shutdown: interrompe o servidor do Bazel.test: cria e executa os destinos de teste especificados.version: imprime informações da versão do Bazel.
Receber ajuda
bazel help command: mostra ajuda e opções paracommand.bazel helpstartup_options: opções para a JVM que hospeda o Bazel.bazel helptarget-syntax: explica a sintaxe para especificar metas.bazel help info-keys: mostra uma lista de chaves usadas pelo comando info.
A ferramenta bazel executa muitas funções, chamadas de comandos. Os mais usados são bazel build e bazel test. Navegue pelas mensagens de ajuda
on-line usando bazel help.
Criando um destino
Antes de iniciar um build, você precisa de um espaço de trabalho. Um espaço de trabalho é uma árvore de diretórios que contém todos os arquivos de origem necessários para criar seu aplicativo. Ele permite executar uma compilação a partir de um volume completamente somente leitura.
Para criar um programa com o Bazel, digite bazel build seguido do
destino que você quer criar.
bazel build //foo
Depois de emitir o comando para criar //foo, você vai ver uma saída semelhante a esta:
INFO: Analyzed target //foo:foo (14 packages loaded, 48 targets configured).
INFO: Found 1 target...
Target //foo:foo up-to-date:
bazel-bin/foo/foo
INFO: Elapsed time: 9.905s, Critical Path: 3.25s
INFO: Build completed successfully, 6 total actions
Primeiro, o Bazel carrega todos os pacotes no gráfico de dependência do destino. Isso
inclui dependências declaradas, arquivos listados diretamente no arquivo BUILD
do destino e dependências transitivas, arquivos listados nos arquivos BUILD das
dependências do destino. Depois de identificar todas as dependências, o Bazel analisa
as dependências para verificar a precisão e cria as ações de build. Por fim, o Bazel executa
os compiladores e outras ferramentas do build.
Durante a fase de execução da compilação, o Bazel imprime mensagens de progresso. As mensagens de progresso incluem a etapa de build atual (como compilador ou vinculador) à medida que ela é iniciada e o número concluído em relação ao número total de ações de build. À medida que a versão é iniciada, o número total de ações geralmente aumenta à medida que o Bazel descobre todo o gráfico de ações, mas o número se estabiliza em alguns segundos.
No final da compilação, o Bazel imprime os destinos solicitados, se eles foram ou
não criados com sucesso e, em caso afirmativo, onde os arquivos de saída podem ser
encontrados. Os scripts que executam builds podem analisar essa saída de maneira confiável. Consulte
--show_result para mais detalhes.
Se você digitar o mesmo comando novamente, o build terminará muito mais rápido.
bazel build //foo
INFO: Analyzed target //foo:foo (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //foo:foo up-to-date:
bazel-bin/foo/foo
INFO: Elapsed time: 0.144s, Critical Path: 0.00s
INFO: Build completed successfully, 1 total action
Essa é uma null build. Como nada mudou, não há pacotes para recarregar nem etapas de build para executar. Se algo mudasse em "foo" ou nas dependências, o Bazel executa novamente algumas ações de build ou conclui um build incremental.
Como criar vários destinos
O Bazel permite várias maneiras de especificar os destinos a serem criados. Coletivamente,
eles são conhecidos como padrões de destino. Essa sintaxe é usada em comandos como build, test ou query.
Enquanto rótulos são usados para especificar destinos
individuais, por exemplo, para declarar dependências em arquivos BUILD, os padrões de destino
do Bazel especificam vários destinos. Os padrões de destino são uma generalização da sintaxe do rótulo para conjuntos de destinos usando caracteres curinga. No caso mais simples, qualquer rótulo válido também é um padrão de destino válido, identificando um conjunto de exatamente um destino.
Todos os padrões de destino que começam com // são resolvidos em relação ao espaço de trabalho
atual.
//foo/bar:wiz |
Apenas o //foo/bar:wiz de destino. |
//foo/bar |
É equivalente a //foo/bar:bar. |
//foo/bar:all |
Todos os destinos de regra no pacote foo/bar. |
//foo/... |
Todos os destinos de regras em todos os pacotes abaixo do diretório foo. |
//foo/...:all |
Todos os destinos de regras em todos os pacotes abaixo do diretório foo. |
//foo/...:* |
Todos os destinos (regras e arquivos) em todos os pacotes abaixo do diretório foo. |
//foo/...:all-targets |
Todos os destinos (regras e arquivos) em todos os pacotes abaixo do diretório foo. |
//... |
Todos os destinos em pacotes no espaço de trabalho. Isso não inclui destinos de repositórios externos. |
//:all |
Todos os destinos no pacote de nível superior, se houver um arquivo "BUILD" na raiz do espaço de trabalho. |
Os padrões de destino que não começam com // são resolvidos em relação ao
diretório de trabalho atual. Estes exemplos pressupõem um diretório de trabalho de foo:
:foo |
Equivalente a //foo:foo. |
bar:wiz |
É equivalente a //foo/bar:wiz. |
bar/wiz |
Equivalente:
|
bar:all |
Equivalente a //foo/bar:all. |
:all |
Equivalente a //foo:all. |
...:all |
Equivalente a //foo/...:all. |
... |
Equivalente a //foo/...:all. |
bar/...:all |
Equivalente a //foo/bar/...:all. |
Por padrão, os links simbólicos de diretório são seguidos para padrões de destino recursivos, exceto aqueles que apontam para a base da saída, como os links simbólicos de conveniência que são criados no diretório raiz do espaço de trabalho.
Além disso, o Bazel não segue links simbólicos ao avaliar padrões de destino
recursivos em qualquer diretório que contenha um arquivo nomeado da seguinte maneira:
DONT_FOLLOW_SYMLINKS_WHEN_TRAVERSING_THIS_DIRECTORY_VIA_A_RECURSIVE_TARGET_PATTERN
foo/... é um caractere curinga sobre pacotes, indicando todos os pacotes recursivamente
abaixo do diretório foo (para todas as raízes do caminho do pacote). :all é um
caractere curinga sobre destinos, correspondendo a todas as regras em um pacote. Esses dois podem ser combinados, como em foo/...:all, e quando os dois caracteres curinga são usados, isso pode ser abreviado como foo/....
Além disso, :* (ou :all-targets) é um caractere curinga que corresponde a todos os destinos
nos pacotes correspondentes, incluindo arquivos que normalmente não são criados por nenhuma regra,
como arquivos _deploy.jar associados a regras java_binary.
Isso implica que :* denota um superconjunto de :all. Embora seja potencialmente
confuso, essa sintaxe permite que o conhecido caractere curinga :all seja usado para
builds comuns, em que a criação de destinos como _deploy.jar não é desejada.
Além disso, o Bazel permite que uma barra seja usada em vez dos dois-pontos exigidos pela
sintaxe do rótulo. Isso geralmente é conveniente ao usar a expansão de nome de arquivo Bash.
Por exemplo, foo/bar/wiz é equivalente a //foo/bar:wiz (se houver um
pacote foo/bar) ou a //foo:bar/wiz (se houver um pacote foo).
Muitos comandos do Bazel aceitam uma lista de padrões de destino como argumentos e todos
respeitam o operador de negação de prefixo -. Isso pode ser usado para subtrair um conjunto de
destinos do conjunto especificado pelos argumentos anteriores. Observe que isso significa
que a ordem é importante. Por exemplo:
bazel build foo/... bar/...
significa "criar todos os destinos abaixo de foo e todos os destinos abaixo de bar", enquanto
bazel build -- foo/... -foo/bar/...
significa "criar todos os destinos abaixo de foo, exceto aqueles abaixo de foo/bar". O argumento -- é necessário para evitar que os argumentos subsequentes que começam com - sejam interpretados como opções adicionais.
É importante ressaltar que subtrair destinos dessa maneira não
garante que eles não sejam criados, já que podem ser dependências de destinos
que não foram subtraídos. Por exemplo, se houvesse um //foo:all-apis de destino que, entre outros, dependesse de //foo/bar:api, este último seria criado como parte da criação do primeiro.
Os destinos com tags = ["manual"] não são incluídos nos padrões de caracteres curinga (..., :*, :all etc.) quando especificados em comandos como bazel build e bazel test. No entanto, eles estão incluídos em padrões de destino com caracteres curinga negativos, ou seja, serão subtraídos. Especifique esses destinos de teste com padrões explícitos na linha de comando se quiser que o Bazel os crie/teste. Por outro lado, bazel query não realiza
essa filtragem automaticamente, o que invalida o propósito do
bazel query.
Como buscar dependências externas
Por padrão, o Bazel faz o download e vincula dependências externas de dependências externas durante a
versão. No entanto, isso pode ser indesejável porque você quer saber
quando novas dependências externas são adicionadas ou porque quer
"pré-buscar" dependências (por exemplo, antes de um voo em que você vai ficar off-line). Para
evitar que novas dependências sejam adicionadas durante os builds, especifique a flag --fetch=false. Essa sinalização se aplica apenas
às regras de repositório que não apontam para um diretório no sistema de arquivos
local. Por exemplo, mudanças em local_repository, new_local_repository e regras de repositório do SDK e do NDK do Android
sempre vão entrar em vigor, independente do valor --fetch .
Se você não permitir a busca durante os builds, e o Bazel encontrar novas dependências externas, o build falhará.
É possível buscar dependências manualmente executando bazel fetch. Se
você bloquear a busca durante o build, execute bazel fetch:
- Antes de criar pela primeira vez.
- Depois de adicionar uma nova dependência externa.
Depois disso, não será necessário executá-lo novamente até que o arquivo "WORKSPACE" seja alterado.
fetch recebe uma lista de destinos para os quais buscar dependências. Por
exemplo, isso buscaria as dependências necessárias para criar //foo:bar
e //bar:baz:
bazel fetch //foo:bar //bar:baz
Para buscar todas as dependências externas de um espaço de trabalho, execute:
bazel fetch //...
Com o Bazel 7.1 ou mais recente, se você tiver o Bzlmod ativado, também é possível buscar todas as dependências externas executando
bazel fetch
Não é necessário executar a busca do bazel se você tiver todas as ferramentas que está
usando (de jars de biblioteca ao próprio JDK) na raiz do espaço de trabalho.
No entanto, se você estiver usando algo fora do diretório do espaço de trabalho, o Bazel
vai executar bazel fetch automaticamente antes de
bazel build.
O cache do repositório
Ele tenta evitar a busca do mesmo arquivo várias vezes, mesmo que ele
seja necessário em espaços de trabalho diferentes ou se a definição de um repositório
externo mudar, mas ainda precisar do mesmo arquivo para download. Para isso,
o Bazel armazena em cache todos os arquivos transferidos por download no cache do repositório, que, por padrão,
está localizado em ~/.cache/bazel/_bazel_$USER/cache/repos/v1/. O
local pode ser alterado pela opção --repository_cache. O cache é compartilhado entre todos os espaços de trabalho e versões instaladas do Bazel.
Uma entrada será retirada do cache se o Bazel souber com certeza que tem uma cópia do arquivo correto, ou seja, se a solicitação de download tiver uma soma SHA256 do arquivo especificado e um arquivo com esse hash estiver no cache. Portanto, especificar um hash para cada arquivo externo não é apenas uma boa ideia do ponto de vista da segurança, mas também ajuda a evitar downloads desnecessários.
A cada ocorrência em cache, o horário da modificação do arquivo no cache é atualizado. Dessa forma, é fácil determinar o último uso de um arquivo no diretório de cache, por exemplo, para limpar manualmente o cache. O cache nunca é limpo automaticamente, porque pode conter a cópia de um arquivo que não está mais disponível no upstream.
Diretórios de arquivos de distribuição
O diretório de distribuição é outro mecanismo do Bazel para evitar downloads desnecessários. O Bazel pesquisa os diretórios de distribuição antes do cache do repositório. A principal diferença é que o diretório de distribuição requer preparação manual.
Usando a opção
--distdir=/path/to-directory, você pode especificar outros diretórios somente leitura para procurar arquivos
em vez de buscá-los. Um arquivo será extraído desse diretório se o nome do arquivo
for igual ao nome de base do URL e, além disso, o hash do arquivo for
igual ao especificado na solicitação de download. Isso só funciona se o
hash de arquivo for especificado na declaração WORKSPACE.
Embora a condição no nome do arquivo não seja necessária para correção, ela reduz o número de arquivos candidatos a um por diretório especificado. Dessa forma, a especificação de diretórios de arquivos de distribuição permanece eficiente, mesmo que o número de arquivos nesses diretórios aumente.
Como executar o Bazel em um ambiente com isolamento físico
Para manter o tamanho do binário do Bazel pequeno, as dependências implícitas dele são buscadas na rede durante a primeira execução. Essas dependências implícitas contêm conjuntos de ferramentas e regras que podem não ser necessárias para todos. Por exemplo, as ferramentas do Android são desagrupadas e buscadas apenas ao criar projetos Android.
No entanto, essas dependências implícitas podem causar problemas ao executar o Bazel em um ambiente com isolamento físico, mesmo que você tenha disponibilizado todas as dependências do ESPAÇO DE TRABALHO. Para resolver isso, você pode preparar um diretório de distribuição contendo essas dependências em uma máquina com acesso à rede e, em seguida, transferi-las para o ambiente com isolamento físico usando uma abordagem off-line.
Para preparar o diretório de distribuição, use a
flag
--distdir. Você precisará fazer isso uma vez para cada nova versão binária do Bazel, já que
as dependências implícitas podem ser diferentes para cada versão.
Para criar essas dependências fora do ambiente com limite de distância, primeiro finalize a árvore de origem do Bazel com a versão correta:
git clone https://github.com/bazelbuild/bazel "$BAZEL_DIR"cd "$BAZEL_DIR"git checkout "$BAZEL_VERSION"
Em seguida, crie o tarball que contenha as dependências de ambiente de execução implícitas para essa versão específica do Bazel:
bazel build @additional_distfiles//:archives.tar
Exporte esse tarball para um diretório que possa ser copiado para o ambiente com isolamento térmico. Observe a sinalização --strip-components, porque --distdir pode ser
bastante minucioso com o nível de aninhamento de diretórios:
tar xvf bazel-bin/external/additional_distfiles/archives.tar \
-C "$NEW_DIRECTORY" --strip-components=3
Por fim, quando você usar o Bazel no ambiente com isolamento físico, transmita a sinalização --distdir
que aponta para o diretório. Por conveniência, você pode adicioná-lo como uma entrada
.bazelrc:
build --distdir=path/to/directory
Configurações do build e compilação cruzada
Todas as entradas que especificam o comportamento e o resultado de um determinado build podem ser
divididas em duas categorias distintas. O primeiro tipo são as informações intrínsecas
armazenadas nos arquivos BUILD do projeto: a regra de build, os
valores dos atributos e o conjunto completo de dependências transitivas.
O segundo tipo são os dados externos ou ambientais, fornecidos pelo usuário ou pela ferramenta de build: a escolha da arquitetura de destino, das opções de compilação e vinculação e de outras opções de configuração do conjunto de ferramentas. Nos referimos a um conjunto completo de dados ambientais como uma configuração.
Em qualquer build, pode haver mais de uma configuração. Considere uma
compilação cruzada, em que você cria um executável //foo:bin para uma arquitetura
de 64 bits, mas sua estação de trabalho é uma máquina de 32 bits. Claramente, a compilação exigirá a criação de //foo:bin usando um conjunto de ferramentas capaz de criar executáveis de 64 bits, mas o sistema de compilação também precisará criar várias ferramentas usadas durante o próprio build (por exemplo, ferramentas criadas a partir da origem e usadas posteriormente em, por exemplo, uma regra geral), e elas precisam ser criadas para execução na estação de trabalho. Assim,
podemos identificar duas configurações: a configuração "exec", que é usada
para criar ferramentas que são executadas durante o build, e a configuração de destino
(ou configuração de solicitação), mas dizemos "configuração de destino" com mais frequência, mesmo
que essa palavra já tenha muitos significados, que é usada para criar o
binário solicitado.
Normalmente, há muitas bibliotecas que são pré-requisitos do destino
de build solicitado (//foo:bin) e de uma ou mais ferramentas de execução, por exemplo, algumas
bibliotecas de base. Essas bibliotecas precisam ser criadas duas vezes, uma para a configuração
exec e outra para a configuração de destino. Ele garante que as duas variantes sejam criadas e que os arquivos derivados sejam mantidos separados para evitar interferências. Geralmente, esses destinos podem ser criados simultaneamente, porque são independentes. Se você receber mensagens de progresso
indicando que um determinado destino está sendo criado duas vezes, essa provavelmente é a
explicação.
A configuração "exec" é derivada da configuração de destino da seguinte maneira:
- Use a mesma versão do Crosstool (
--crosstool_top) conforme especificado na configuração da solicitação, a menos que--host_crosstool_topseja especificado. - Use o valor de
--host_cpupara--cpu(padrão:k8). - Use os mesmos valores dessas opções, conforme especificado na configuração da
solicitação:
--compiler,--use_ijars. Se--host_crosstool_topfor usado, o valor de--host_cpuserá usado para procurar umdefault_toolchainno Crosstool (ignorando--compiler) para a configuração exec. - Use o valor de
--host_javabasepara--javabase - Use o valor de
--host_java_toolchainpara--java_toolchain - Use builds otimizados para código C++ (
-c opt). - Não gera informações de depuração (
--copt=-g0). - Retira informações de depuração de executáveis e bibliotecas compartilhadas
(
--strip=always). - Coloque todos os arquivos derivados em um local especial, diferente daquele usado por qualquer configuração de solicitação possível.
- Suprimir a marcação de binários com dados de build (consulte as opções de
--embed_*). - Todos os outros valores permanecem com os valores padrão.
Há muitos motivos pelos quais pode ser preferível selecionar uma configuração exec distinta na configuração da solicitação. Mais importante:
Primeiro, ao usar binários otimizados e removidos, você reduz o tempo gasto vinculando e executando as ferramentas, o espaço em disco ocupado por elas e o tempo de E/S da rede em builds distribuídos.
Em segundo lugar, ao desacoplar as configurações "exec" e "request" em todos os builds, você evita recriações muito caras que resultariam de pequenas mudanças na configuração da solicitação (como alterar as opções de um vinculador), conforme descrito anteriormente.
Corrigir recriações incrementais
Um dos principais objetivos do projeto do Bazel é garantir recriações incrementais corretas. As ferramentas de build anteriores, especialmente aquelas baseadas no Make, fazem várias suposições incorretas na implementação de builds incrementais.
Primeiro, que os carimbos de data/hora dos arquivos aumentam monotonicamente. Esse é o caso comum, mas é muito fácil entrar em conflito com essa suposição. A sincronização com uma revisão anterior de um arquivo diminui o tempo de modificação desse arquivo. Os sistemas baseados em Make não serão recriados.
Em termos mais gerais, embora o Make detecte mudanças nos arquivos, ele não detecta mudanças
nos comandos. Se você mudar as opções transmitidas ao compilador em uma determinada etapa do build, o Make não vai executar o compilador novamente, e será necessário descartar manualmente
as saídas inválidas do build anterior usando make clean.
Além disso, o Make não é robusto contra o encerramento malsucedido de um dos subprocessos depois que ele começou a gravar no arquivo de saída. Embora a execução atual do Make falhe, a invocação seguinte do Make vai presumir que o arquivo de saída truncado é válido (porque é mais recente do que as entradas) e não será recriado. Da mesma forma, se o processo Make for encerrado, uma situação semelhante poderá ocorrer.
O Bazel evita essas suposições, entre outras. Ele mantém um banco de dados de todo o trabalho realizado anteriormente e só omite uma etapa de build se descobrir que o conjunto de arquivos de entrada (e os carimbos de data/hora) dessa etapa e o comando de compilação dessa etapa correspondem exatamente a um no banco de dados e se o conjunto de arquivos de saída (e os carimbos de data/hora) da entrada do banco de dados correspondem exatamente aos carimbos de data/hora dos arquivos no disco. Qualquer alteração nos arquivos de entrada, de saída ou no próprio comando fará com que a etapa de criação seja reexecutada.
A vantagem para os usuários de builds incrementais corretos é: menos tempo desperdiçado devido à
confusão. Além disso, menos tempo gasto aguardando recriações causadas pelo uso de make
clean, seja ela necessária ou preventiva.
Criar consistência e builds incrementais
Formalmente, definimos o estado de uma compilação como consistente quando todos os arquivos de saída esperados existem e o conteúdo deles está correto, conforme especificado pelas etapas ou regras necessárias para criá-los. Quando você edita um arquivo de origem, o estado do build é considerado inconsistente e permanece inconsistente até que você execute a ferramenta de build da próxima vez. Descrevemos essa situação como inconsistência instável, porque ela é apenas temporária e a consistência é restaurada ao executar a ferramenta de build.
Há outro tipo de inconsistência que é perniciosa: a inconsistência
estável. Se o build atingir um estado inconsistente estável, a invocação
bem-sucedida repetida da ferramenta de build não vai restaurar a consistência: o build
ficou "travado" e as saídas permanecerão incorretas. Os estados inconsistentes estáveis
são o principal motivo para os usuários do Make (e outras ferramentas de build) digitarem make clean.
Descobrir que a ferramenta de build falhou dessa maneira (e se recuperar dela) pode ser demorado e muito frustrante.
Conceitualmente, a maneira mais simples de ter um build consistente é descartar todas as saídas de build anteriores e começar de novo: tornar cada build limpo. Essa abordagem é obviamente muito demorada para ser prática (exceto talvez para engenheiros de lançamento). Portanto, para ser útil, a ferramenta de build precisa ser capaz de executar builds incrementais sem comprometer a consistência.
A análise de dependência incremental correta é difícil e, conforme descrito acima, muitas outras ferramentas de build não conseguem evitar estados inconsistentes estáveis durante os builds incrementais. Por outro lado, o Bazel oferece a seguinte garantia: após uma invocação bem-sucedida da ferramenta de build, em que você não fez edições, o build vai estar em um estado consistente. Se você editar os arquivos de origem durante uma build, o Bazel não garante a consistência do resultado da versão atual. mas garante que os resultados do próximo build restauram a consistência.)
Como em todas as garantias, há alguns detalhes: há algumas maneiras conhecidas de entrar em um estado inconsistente estável com o Bazel. Não garantiremos a investigação desses problemas que surjam de tentativas deliberadas de encontrar bugs na análise de dependência incremental, mas vamos investigar e fazer o possível para corrigir todos os estados inconsistentes estáveis que surgem com o uso normal ou "razoável" da ferramenta de build.
Se você detectar um estado inconsistente estável com o Bazel, informe um bug.
Execução no modo sandbox
Ele usa sandboxes para garantir que as ações sejam executadas de forma hermética e
correta. Ele executa spawns (ações) em sandboxes que
contêm apenas o conjunto mínimo de arquivos necessários para fazer o job. Atualmente, o sandbox funciona no Linux 3.12 ou mais recente com a opção CONFIG_USER_NS
ativada e também no macOS 10.11 ou mais recente.
O Bazel vai imprimir um aviso se o sistema não for compatível com o sandbox para alertar
que as versões não têm garantia de serem herméticas e podem afetar
o sistema host de maneiras desconhecidas. Para desativar esse aviso, transmita a
flag --ignore_unsupported_sandboxing para o Bazel.
Em algumas plataformas, como os nós de cluster do Google Kubernetes Engine ou o Debian, os namespaces de usuário são desativados por padrão devido a questões de segurança. Isso pode ser verificado analisando o arquivo
/proc/sys/kernel/unprivileged_userns_clone: se ele existir e contiver 0,
os namespaces do usuário poderão ser ativados com
sudo sysctl kernel.unprivileged_userns_clone=1.
Em alguns casos, o sandbox do Bazel não executa regras devido à configuração
do sistema. O sintoma geralmente é uma falha que gera uma mensagem semelhante a
namespace-sandbox.c:633: execvp(argv[0], argv): No such file or directory.
Nesse caso, tente desativar o sandbox para regras gerais com
--strategy=Genrule=standalone e para outras regras com
--spawn_strategy=standalone. Além disso, informe um bug no nosso Issue Tracker e mencione qual distribuição Linux você está usando para que possamos investigar e fornecer uma correção em uma versão posterior.
Fases de um build
No Bazel, um build ocorre em três fases distintas. Como usuário, entender a diferença entre elas fornece insights sobre as opções que controlam uma compilação (veja abaixo).
Fase de carregamento
O primeiro é o carregamento, durante o qual todos os arquivos BUILD necessários para os destinos iniciais e o fechamento transitivo de dependências são carregados, analisados, avaliados e armazenados em cache.
Para a primeira compilação após um servidor Bazel, a fase de carregamento normalmente leva muitos segundos, já que muitos arquivos BUILD são carregados do sistema de arquivos. Em builds subsequentes, especialmente se nenhum arquivo BUILD tiver sido alterado, o carregamento ocorre muito rapidamente.
Os erros relatados durante essa fase incluem: pacote não encontrado, destino não encontrado, erros léxicos e gramaticais em um arquivo BUILD e erros de avaliação.
Fase de análise
A segunda fase, análise, envolve a análise e validação semânticas de cada regra de compilação, a construção de um gráfico de dependência de compilação e a determinação de exatamente qual trabalho será feito em cada etapa.
Assim como o carregamento, a análise também leva vários segundos quando calculada por completo. No entanto, o Bazel armazena em cache o gráfico de dependência de um build para o próximo e analisa novamente o necessário, o que pode agilizar os builds incrementais caso os pacotes não tenham mudado desde o build anterior.
Os erros relatados neste estágio incluem: dependências inadequadas, entradas inválidas para uma regra e todas as mensagens de erro específicas da regra.
As fases de carregamento e análise são rápidas porque o Bazel evita E/S desnecessária de arquivos nessa etapa, lendo apenas arquivos BUILD para determinar o trabalho a ser feito. Isso ocorre por design e torna o Bazel uma boa base para ferramentas de análise, como o comando query do Bazel, que é implementado no topo da fase de carregamento.
Fase de execução
A terceira e última fase do build é a execução. Essa fase garante que as saídas de cada etapa do build sejam consistentes com as entradas, executando novamente as ferramentas de compilação/vinculação/etc. conforme necessário. É nessa etapa que o build passa a maior parte do tempo, variando de alguns segundos a mais de uma hora, no caso de um build grande. Os erros relatados durante essa fase incluem: arquivos de origem ausentes, erros em uma ferramenta executada por alguma ação de build ou falha de uma ferramenta para produzir o conjunto esperado de saídas.