Ação
Um comando executado durante o build, por exemplo, uma chamada para um compilador que usa artefatos como entradas e produz outros artefatos como saídas. Inclui metadados como argumentos de linha de comando, chave de ação, variáveis de ambiente e artefatos de entrada/saída declarados.
Consulte também: documentação sobre regras
Cache de ações
Um cache no disco que armazena um mapeamento das ações executadas para as saídas criadas. A chave de cache é conhecida como chave de ação. Um componente principal do modelo de incrementalidade do Bazel. O cache é armazenado no diretório de saída de base e, portanto, sobrevive a reinicializações do servidor do Bazel.
Gráfico de ação
Um gráfico na memória de ações e os artefatos que
essas ações leem e geram. O gráfico pode incluir artefatos que existem como
arquivos de origem (por exemplo, no sistema de arquivos) e artefatos
intermediário/final gerados que não são mencionados nos arquivos BUILD. Produzido
durante a fase de análise e usado durante a fase de
execução.
Consulta de gráfico de ação (aquery)
Uma ferramenta de consulta que pode consultar ações de build. Isso permite analisar como as regras de build se traduzem nos builds de trabalho reais.
Tecla de ação
A chave de cache de uma ação. Calculado com base nos metadados da ação, que podem incluir o comando a ser executado na ação, sinalizações do compilador, locais de biblioteca ou cabeçalhos do sistema, dependendo da ação. Permite que o Bazel armazene em cache ou invalide ações individuais de forma determinística.
Fase de análise
A segunda fase de um build. Processa o gráfico de destino
especificado nos arquivos BUILD para produzir um gráfico
de ações na memória que determina a ordem das ações a serem executadas durante a
fase de execução. Essa é a fase em que as implementações
de regras são avaliadas.
Artefato
Um arquivo de origem ou um arquivo gerado. Também pode ser um diretório de arquivos, conhecido como artefatos de árvore.
Um artefato pode ser uma entrada para várias ações, mas só pode ser gerado por no máximo uma ação.
Um artefato que corresponde a um destino de arquivo pode ser endereçado por um rótulo.
Aspecto
Um mecanismo para regras criarem outras ações nas
dependências. Por exemplo, se o destino A depender de B, é possível aplicar um aspecto em
A que atravessa para cima uma borda de dependência para B e executa outras ações em B
para gerar e coletar outros arquivos de saída. Essas ações adicionais são
armazenadas em cache e reutilizadas entre destinos que exigem o mesmo aspecto. Criado com a
função aspect() da API Starlark Build. Pode ser usado, por exemplo, para gerar
metadados para IDEs e criar ações para linting.
Consulte também: documentação de aspectos
Aspect-on-aspect
Um mecanismo de composição em que aspectos podem ser aplicados aos resultados
de outros aspectos. Por exemplo, um aspecto que gera informações para uso por
IDEs pode ser aplicado em um aspecto que gera arquivos .java de um
proto.
Para que um aspecto A seja aplicado em cima do aspecto B, os provedores que
B anuncia no atributo provides
precisam corresponder ao que A declara que quer no atributo
required_aspect_providers.
Atributo
Um parâmetro de uma regra, usado para expressar informações de build por destino.
Os exemplos incluem srcs, deps e copts, que declaram respectivamente os
arquivos de origem, dependências e opções personalizadas do compilador de um destino. Os atributos
específicos disponíveis para um determinado destino dependem do tipo de regra.
.bazelrc
Arquivo de configuração do Bazel usado para mudar os valores padrão de flags
de inicialização e flags de comando e para definir grupos
comuns de opções que podem ser definidos juntos na linha de comando do Bazel usando
uma flag --config. O Bazel pode combinar configurações de vários arquivos bazelrc
(em todo o sistema, por espaço de trabalho, por usuário ou em um local personalizado), e um
arquivo bazelrc também pode importar configurações de outros arquivos bazelrc.
Blaze
A versão interna do Google do Bazel. O principal sistema de build do Google para o monorepo.
Arquivo BUILD
Um arquivo BUILD é o arquivo de configuração principal que informa ao Bazel quais saídas
de software criar, quais são as dependências e como criá-las. O Bazel
usa um arquivo BUILD como entrada para criar um gráfico de dependências
e derivar as ações que precisam ser concluídas para criar saídas de software intermediárias e finais. Um arquivo BUILD marca um diretório e todos os subdiretórios que não
contêm um arquivo BUILD como um pacote e pode conter
alvos criados por regras. O arquivo também pode ser nomeado
BUILD.bazel.
Arquivo BUILD.bazel
Consulte Arquivo BUILD. Tem precedência sobre um arquivo BUILD no mesmo
diretório.
Arquivo .bzl
Um arquivo que define regras, macros e constantes gravadas em
Starlark. Eles podem ser importados para arquivos
BUILD usando a função load().
Criar gráfico
O gráfico de dependência que o Bazel constrói e percorre para realizar um build. Inclui nós como destinos, destinos configurados, ações e artefatos. Um build é considerado concluído quando todos os artefatos em que um conjunto de alvos solicitados dependem são verificados como atualizados.
Configuração do build
Uma parte da configuração definida pelo Starlark. As Transições podem definir configurações de build para mudar a configuração de um subgrafo. Se exposto ao usuário como uma flag de linha de comando, também conhecida como flag de build.
Build limpo
Uma versão que não usa os resultados de versões anteriores. Isso geralmente é mais lento do que um build incremental, mas é comumente considerado mais correto. O Bazel garante que os builds limpos e incrementais sejam sempre corretos.
Modelo cliente-servidor
O cliente de linha de comando bazel inicia automaticamente um servidor em segundo plano na
máquina local para executar comandos do Bazel. O servidor persiste em
comandos, mas é interrompido automaticamente após um período de inatividade (ou explicitamente por
desligamento do Bazel). A divisão do Bazel em um servidor e um cliente ajuda a amortizar o tempo de inicialização da JVM
e oferece suporte a builds incrementais mais rápidos,
porque o gráfico de ações permanece na memória em todos os comandos.
Comando
Usado na linha de comando para invocar diferentes funções do Bazel, como bazel
build, bazel test, bazel run e bazel query.
Flags de comando
Um conjunto de flags específico para um comando. As flags de comando são especificadas
após o comando (bazel build <command flags>). Elas podem ser aplicadas a
um ou mais comandos. Por exemplo, --configure é uma flag exclusiva para o comando
bazel sync, mas --keep_going é aplicável a sync, build,
test e muito mais. As flags são usadas com frequência para fins de configuração.
Assim, mudanças nos valores de flags podem fazer com que o Bazel invalide gráficos na memória
e reinicie a fase de análise.
Configuração
Informações fora das definições de regra que afetam a forma como as regras geram ações. Cada build tem pelo menos uma configuração que especifica a plataforma de destino, as variáveis de ambiente de ação e as flags de build da linha de comando. As transições podem criar outras configurações, como para ferramentas de host ou compilação cruzada.
Consulte também: Configurações
Redução de configuração
O processo de incluir apenas as partes da configuração de que um
destino realmente precisa. Por exemplo, se você criar o binário Java //:j com a dependência
C++ //:c, será um desperdício incluir o valor de --javacopt na
configuração de //:c, porque mudar --javacopt quebra desnecessariamente a capacidade de
criar cache do C++.
Consulta configurada (cquery)
Uma ferramenta de consulta que consulta alvos
configurados (depois que a fase de análise
é concluída). Isso significa que select() e flags de build (como
--platforms) são refletidos com precisão nos resultados.
Consulte também:documentação da cquery
Destino configurado
O resultado da avaliação de um alvo com uma
configuração. A fase de análise produz
isso combinando as opções do build com os destinos que precisam ser criados.
Por exemplo, se o //:foo for criado para duas arquiteturas diferentes no mesmo
build, ele terá dois destinos configurados: <//:foo, x86> e <//:foo, arm>.
Correção
Um build está correto quando a saída reflete fielmente o estado das entradas transitivas. Para criar builds corretos, o Bazel se esforça para ser hermético, reproduzível e tornar a análise de build e a execução de ações determinísticas.
Dependência
Uma aresta dirigida entre duas metas. Um //:foo de destino tem uma dependência
de destino em //:bar de destino se os valores de atributo de //:foo contêm uma
referência a //:bar. //:foo tem uma dependência de ação em //:bar se uma
ação em //:foo depende de um artefato de entrada criado por uma
ação em //:bar.
Em alguns contextos, também pode se referir a uma dependência externa. Consulte módulos.
Depset
Uma estrutura de dados para coletar dados sobre dependências transitivas. Otimizado para que a mesclagem de depsets seja eficiente em termos de tempo e espaço, porque é comum ter depsets muito grandes (centenas de milhares de arquivos). Implementado para referenciar recursivamente outros depsets por motivos de eficiência de espaço. As implementações de regra não devem "achatar" depsets convertendo-os em listas, a menos que a regra esteja no nível superior do gráfico de build. A planificação de depsets grandes gera um consumo de memória enorme. Também conhecidos como conjuntos aninhados na implementação interna do Bazel.
Consulte também:documentação do Depset
Cache de disco
Uma loja de blobs local em disco para o recurso de armazenamento em cache remoto. Pode ser usado em conjunto com um repositório de blobs remoto real.
Distdir
Um diretório somente leitura que contém arquivos que o Bazel buscaria da Internet usando regras de repositório. Permite que os builds sejam executados totalmente off-line.
Execução dinâmica
Uma estratégia de execução que seleciona entre execução local e remota com base em várias heurísticas e usa os resultados de execução do método mais rápido. Algumas ações são executadas mais rapidamente localmente (por exemplo, vinculação) e outras são mais rápidas remotamente (por exemplo, compilação altamente paralelizável). Uma estratégia de execução dinâmica pode oferecer os melhores tempos de build incrementais e limpos possíveis.
Fase de execução
A terceira fase de um build. Executa as ações no gráfico de ações criado durante a fase de análise. Essas ações invocam executáveis (compiladores, scripts) para ler e gravar artefatos. As estratégias de geração controlam como essas ações são executadas: localmente, remotamente, dinamicamente, em sandbox, no Docker etc.
Raiz de execução
Um diretório no diretório base de saída do espaço de trabalho
em que as ações locais são executadas em builds que não são sandbox. O conteúdo do diretório é composto principalmente de links simbólicos
de artefatos de entrada do espaço de trabalho. A raiz de execução também
contém links simbólicos para repositórios externos como outras entradas e o diretório bazel-out
para armazenar saídas. Preparado durante a fase de carregamento
criando uma floresta de links simbólicos dos diretórios que representam o fechamento
transitivo dos pacotes de que um build depende. Acessível com bazel info
execution_root na linha de comando.
Arquivo
Consulte Artefato.
Hermeticity
Um build é hermético se não houver influências externas nas operações de build e teste, o que ajuda a garantir que os resultados sejam determinísticos e corretos. Por exemplo, builds herméticos geralmente não permitem o acesso de rede a ações, restringem o acesso a entradas declaradas, usam carimbos de data/hora e fusos horários fixos, restringem o acesso a variáveis de ambiente e usam sementes fixas para geradores de números aleatórios.
Build incremental
Um build incremental reutiliza os resultados de builds anteriores para reduzir o tempo de build e o uso de recursos. A verificação de dependências e o armazenamento em cache têm como objetivo produzir resultados corretos para esse tipo de build. Um build incremental é o oposto de um build limpo.
Rótulo
Um identificador de um destino. Geralmente tem o formato
@repo//path/to/package:target, em que repo é o nome (aparente) do
repositório que contém o destino, path/to/package é o caminho
para o diretório que contém o arquivo BUILD que declara o
destino (esse diretório também é conhecido como pacote) e target
é o nome do destino em si. Dependendo da situação, partes dessa
sintaxe podem ser omitidas.
Consulte também: Rótulos
Fase de carregamento
A primeira fase de um build em que o Bazel executa arquivos BUILD para
criar pacotes. As macros e algumas funções, como
glob(), são avaliadas nesta fase. Intercalada com a segunda fase do
build, a fase de análise, para criar um gráfico
de destino.
Macro legada
Um tipo de macro que é declarado como uma função
Starlark comum e que é executado como um efeito colateral da execução de um
arquivo BUILD.
As macros legadas podem fazer tudo o que uma função pode. Isso significa que elas podem ser convenientes,
mas também podem ser mais difíceis de ler, escrever e usar. Uma macro legada pode
mutar os argumentos de forma inesperada ou falhar quando receber um argumento select() ou mal
tipado.
Compare com as macros simbólicas.
Consulte também: Documentação de macros legados
Macro
Um mecanismo para compor várias declarações de destino de regra em
um único elemento acionável do Starlark. Permite reutilizar padrões de declaração de regras
comuns em arquivos BUILD. Foi expandido para as declarações de destino de regra
subjacente durante a fase de carregamento.
Há dois tipos: macros simbólicas (desde o Bazel 8) e macros legados.
Mnemonic
Uma string curta e legível por humanos selecionada por um autor de regra para entender rapidamente
o que uma ação na regra está fazendo. Os mnemônicos podem ser usados como
identificadores para seleções de estratégia de geração. Alguns exemplos de mnemônicos de ação
são Javac das regras do Java, CppCompile das regras do C++ e
AndroidManifestMerger das regras do Android.
Módulo
Um projeto do Bazel que pode ter várias versões, cada uma com dependências de outros módulos. Isso é análogo a conceitos conhecidos em outros sistemas de gerenciamento de dependências, como um artefato do Maven, um pacote do npm, um módulo do Go ou uma caixa do Cargo. Os módulos formam a estrutura do sistema de gerenciamento de dependências externas do Bazel.
Cada módulo é apoiado por um repo com um arquivo MODULE.bazel na raiz. Esse arquivo contém metadados sobre o próprio módulo (como nome e
versão), dependências diretas e vários outros dados, incluindo registros de
toolchain e entrada de extensão de módulo.
Os metadados do módulo são hospedados em registros do Bazel.
Consulte também: Módulos do Bazel
Extensão do módulo
Uma parte da lógica que pode ser executada para gerar repos lendo entradas do gráfico de dependência do módulo e invocando regras de repositório. As extensões de módulo têm recursos semelhantes às regras de repositório, permitindo que acessem a Internet, realizem E/S de arquivos e assim por diante.
Consulte também: Extensões de módulo
Regras nativas
Regras integradas ao Bazel e implementadas em Java. Essas regras
aparecem em arquivos .bzl como funções no módulo nativo (por
exemplo, native.cc_library ou native.java_library). As regras definidas pelo usuário
(não nativas) são criadas usando o Starlark.
Base de saída
Um diretório específico do workspace para armazenar arquivos de saída do Bazel. Usado para separar as saídas da árvore de origem do espaço de trabalho (o repositório principal). Localizado na raiz do usuário de saída.
Grupos de saída
Um grupo de arquivos que serão criados quando o Bazel terminar de criar um
destino. As regras colocam as saídas usuais no "grupo de saída padrão",
por exemplo, o arquivo .jar de um java_library, .a e .so para destinos cc_library. O grupo de saída padrão é o grupo de saída cujos
artefatos são criados quando um destino é solicitado na linha de comando.
As regras podem definir mais grupos de saída nomeados que podem ser especificados explicitamente em
arquivos BUILD (regra filegroup) ou na linha de comando
(indicador --output_groups).
Saída da raiz do usuário
Um diretório específico do usuário para armazenar as saídas do Bazel. O nome do diretório é derivado do nome de usuário do sistema do usuário. Evita colisões de arquivos de saída se vários usuários estiverem criando o mesmo projeto no sistema ao mesmo tempo. Contém subdiretórios correspondentes às saídas de build de espaços de trabalho individuais, também conhecidos como bases de saída.
Pacote
O conjunto de alvos definido por um arquivo BUILD. O
nome de um pacote é o caminho do arquivo BUILD em relação à raiz do
repositório. Um pacote pode conter subpacotes ou subdiretórios que contêm arquivos BUILD,
formando uma hierarquia de pacotes.
Grupo de pacotes
Um alvo que representa um conjunto de pacotes. Usado com frequência em valores de atributo
visibility.
Plataforma
Um "tipo de máquina" envolvido em um build. Isso inclui a máquina em que o Bazel é executado (a plataforma "host"), as ferramentas de build de máquinas em que as máquinas são executadas (plataformas "exec") e as máquinas para as quais as máquinas de destino são criadas (plataformas "de destino").
Provedor
Um esquema que descreve uma unidade de informações a serem transmitidas entre
alvos de regras com relações de dependência. Normalmente, ele
contém informações como opções do compilador, arquivos de origem ou de saída transitivos
e metadados de build. Usado com frequência em conjunto com depsets para
armazenar dados transitivos acumulados de maneira eficiente. Um exemplo de provedor integrado
é DefaultInfo.
Consulte também:Documentação do provedor
Consulta (conceito)
O processo de analisar um build graph para entender as propriedades e estruturas de dependência do alvo. O Bazel oferece suporte a três variantes de consulta: query, cquery e aquery.
consulta (comando)
Uma ferramenta de consulta que opera no gráfico de destino da fase
pós-carregamento do build. Isso é relativamente rápido,
mas não é possível analisar os efeitos de select(), build flags,
artefatos ou ações de build.
Consulte também: Como fazer consultas, Referência de consultas
Repositório
Uma árvore de diretórios com um arquivo de marcador de limite na raiz, contendo arquivos de origem que podem ser usados em um build do Bazel. Muitas vezes abreviado para repo.
Um arquivo de marcador de limite do repositório pode ser MODULE.bazel (sinaliza que esse repositório
representa um módulo do Bazel), REPO.bazel ou, em contextos legados, WORKSPACE ou
WORKSPACE.bazel. Qualquer arquivo de marcador de limite de repositório vai indicar o limite de um
repositório. Vários desses arquivos podem coexistir em um diretório.
O repositório principal é aquele em que o comando atual do Bazel está sendo executado.
Os repositórios externos são definidos especificando módulos em arquivos
MODULE.bazel ou invocando regras de repositório em extensões
de módulo. Elas podem ser buscadas sob demanda para um local
"mágico" predeterminado no disco.
Cada repositório tem um nome canônico exclusivo e constante e, possivelmente, nomes aparentes diferentes quando visualizados em outros repositórios.
Consulte também: Visão geral das dependências externas
Cache do repositório
Um cache compartilhado com endereço de conteúdo de arquivos transferidos por download pelo Bazel para builds,
compartilhável em espaços de trabalho. Ativa builds off-line após o
download inicial. É comumente usado para armazenar em cache arquivos transferidos por regras
de repositório, como http_archive, e APIs de regra de repositório, como
repository_ctx.download. Os arquivos são armazenados em cache somente se as somas de verificação SHA-256 forem
especificadas para o download.
Regra de repositório
Um esquema para definições de repositório que informa ao Bazel como materializar (ou
"buscar") um repositório. Muitas vezes abreviada para regra do repositório.
As regras de repositório são invocadas pelo Bazel internamente para definir repositórios com suporte de
módulos ou podem ser invocadas por extensões de módulo.
As regras de repositório podem acessar a Internet ou realizar E/S de arquivos. A regra de repositório
mais comum é http_archive para fazer o download de um arquivo que contém arquivos de origem da
Internet.
Consulte também:documentação sobre regras de repositório
Reprodutibilidade
A propriedade de um build ou teste que um conjunto de entradas para o build ou teste sempre produzirá o mesmo conjunto de saídas, independentemente do tempo, do método ou do ambiente. Isso não implica necessariamente que as saídas sejam corretas ou as saídas desejadas.
Regra
Um esquema para definir destinos de regras em um arquivo BUILD, como
cc_library. Do ponto de vista de um autor de arquivo BUILD, uma regra consiste em
um conjunto de atributos e lógica de caixa preta. A lógica informa ao
destino da regra como produzir artefatos de saída e transmitir informações para
outros destinos de regra. Do ponto de vista dos autores do .bzl, as regras são a
principal maneira de estender o Bazel para oferecer suporte a novas linguagens e
ambientes de programação.
As regras são instanciadas para produzir destinos de regras na fase de carregamento. Na fase de análise, os destinos de regra comunicam informações às dependências downstream na forma de provedores e registram ações que descrevem como gerar os artefatos de saída. Essas ações são executadas na fase de execução.
Consulte também: documentação sobre regras
Destino da regra
Um destino que é uma instância de uma regra. Contrasta com os destinos de arquivo e grupos de pacotes. Não confundir com regra.
Arquivos de execução
As dependências de tempo de execução de um destino executável. Normalmente, o executável é a saída executável de uma regra de teste, e os arquivos de execução são dependências de dados do tempo de execução do teste. Antes da invocação do executável (durante o teste do Bazel), o Bazel prepara a árvore de runfiles com o executável de teste de acordo com a estrutura do diretório de origem.
Consulte também:documentação sobre arquivos de execução
Sandbox
Uma técnica para isolar uma ação em execução dentro de uma raiz de execução restrita e temporária, ajudando a garantir que ela não leia entradas não declaradas nem grave saídas não declaradas. O sandbox melhora muito a hermeticidade, mas geralmente tem um custo de desempenho e requer suporte do sistema operacional. O custo de desempenho depende da plataforma. No Linux, isso não é significativo, mas no macOS, pode tornar o sandbox inutilizável.
Skyframe
O Skyframe é o framework de avaliação incremental, funcional e paralela do Bazel.
Estampagem
Um recurso para incorporar mais informações em
artefatos
criados pelo Bazel. Por exemplo, isso pode ser usado para controle de origem, tempo de build
e outras informações relacionadas ao ambiente ou ao espaço de trabalho para builds de lançamento.
Ative usando a flag --workspace_status_command e as regras que
oferecem suporte ao atributo de selo.
Starlark
A linguagem de extensão para escrever regras e macros. Um
subconjunto restrito do Python (sintaticamente e gramaticalmente) destinado à
configuração e a um melhor desempenho. Usa a extensão de arquivo .bzl. Os arquivos BUILD usam uma versão ainda mais
restrita do Starlark (como definições de função def), anteriormente
conhecido como Skylark.
Consulte também:documentação da linguagem Starlark
Flags de inicialização
O conjunto de flags especificado entre bazel e o comando,
por exemplo, bazel --host_jvm_debug build. Essas flags modificam a
configuração do servidor do Bazel. Portanto, qualquer modificação nas
flags de inicialização causa uma reinicialização do servidor. As flags de inicialização não são específicas de nenhum
comando.
Macro simbólica
Um tipo de macro declarado com um esquema de atributo semelhante a uma regra permite ocultar alvos declarados internamente do próprio pacote e impõe um padrão de nomenclatura previsível aos alvos declarados pela macro. Projetado para evitar alguns dos problemas encontrados em grandes bases de código de macros legados.
Consulte também: Documentação de macros simbólicas
Destino
Um objeto definido em um arquivo BUILD e identificado por um
rótulo. As metas representam as unidades que podem ser criadas em um espaço de trabalho da perspectiva do usuário final.
Um destino declarado pela instanciação de uma regra é chamado de destino
de regra. Dependendo da regra, elas podem ser executáveis (como
cc_binary) ou testáveis (como cc_test). Os destinos da regra geralmente dependem de
outros destinos pelos atributos (como deps). Essas
dependências formam a base do gráfico de destino.
Além dos destinos de regras, há também destinos de arquivos e de grupo de pacotes. Os destinos de arquivo correspondem a artefatos referenciados
em um arquivo BUILD. Como um caso especial, o arquivo BUILD de qualquer pacote é
sempre considerado um destino de arquivo de origem nesse pacote.
Os destinos são descobertos durante a fase de carregamento. Durante a fase de análise, os destinos são associados a configurações de build para formar destinos configurados.
Gráfico de destino
Um gráfico na memória de alvos e suas dependências. Produzido durante a fase de carregamento e usado como entrada para a fase de análise.
Padrão desejado
Uma maneira de especificar um grupo de alvos na linha de comando. Os padrões mais usados
são :all (todos os destinos de regra), :* (todos os destinos de regra + arquivo) e
... (pacote atual e todos os subpacotes recursivamente). Pode ser usado
em combinação. Por exemplo, //...:* significa que todas as regras e destinos de arquivo em todos
os pacotes são recursivamente da raiz do espaço de trabalho.
Testes
Destinos de regras instanciados a partir de regras de teste e, portanto, contêm um teste executável. Um código de retorno de zero da conclusão do executável indica o sucesso do teste. O contrato exato entre o Bazel e os testes (como variáveis de ambiente de teste, métodos de coleta de resultados de teste) é especificado na Enciclopédia de testes.
Conjunto de ferramentas
Um conjunto de ferramentas para criar saídas para uma linguagem. Normalmente, um conjunto de ferramentas inclui compiladores, vinculadores, intérpretes e/ou linters. Uma toolchain também pode variar de acordo com a plataforma, ou seja, os componentes de uma toolchain de compilador Unix podem ser diferentes para a variante do Windows, mesmo que a toolchain seja para o mesmo idioma. A seleção da cadeia de ferramentas certa para a plataforma é conhecida como resolução de cadeia de ferramentas.
Alvo de nível superior
Um destino de build é de nível superior se for solicitado na linha de comando
do Bazel. Por exemplo, se //:foo depender de //:bar e bazel build //:foo for
chamado, para esse build, //:foo será de alto nível e //:bar não será
de alto nível, embora ambos os destinos precisem ser criados. Uma diferença importante
entre os alvos de nível superior e os que não são de nível superior é que as flags
de comando definidas na linha de comando do Bazel (ou pelo
.bazelrc) definem a configuração para alvos de nível
superior, mas podem ser modificadas por uma transição para alvos que não são de nível
superior.
Transição
Um mapeamento do estado de configuração de um valor para outro. Permite que as metas no gráfico de build tenham configurações diferentes, mesmo que tenham sido instanciadas com a mesma regra. Um uso comum de transições é com transições divididas, em que determinadas partes do gráfico de destino são bifurcadas com configurações distintas para cada bifurcação. Por exemplo, é possível criar um APK do Android com binários nativos compilados para ARM e x86 usando transições divididas em um único build.
Consulte também:Transições definidas pelo usuário
Artefato de árvore
Um artefato que representa uma coleção de arquivos. Como esses arquivos não são artefatos, uma ação que opera neles precisa registrar o artefato de árvore como entrada ou saída.
Visibilidade
Um dos dois mecanismos para evitar dependências indesejadas no sistema de build:
visibilidade de destino para controlar se um destino pode ser usado
por outros destinos; e visibilidade de carregamento para controlar se um arquivo BUILD
ou .bzl pode carregar um determinado arquivo .bzl. Sem contexto, "visibilidade" geralmente se refere à visibilidade do alvo.
Consulte também: documentação sobre visibilidade
Espaço de trabalho
O ambiente compartilhado por todos os comandos do Bazel é executado no mesmo repositório principal.
Historicamente, os conceitos de "repositório" e "espaço de trabalho" foram confundidos. O termo "espaço de trabalho" foi usado com frequência para se referir ao repositório principal e, às vezes, até como sinônimo de "repositório". Esse uso deve ser evitado para maior clareza.