Ação
Um comando para ser 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 os argumentos de linha de comando, a chave de ação, as variáveis de ambiente e os artefatos de entrada/saída declarados.
Confira também:Documentação de regras
Cache de ações
Um cache em disco que armazena um mapeamento de ações executadas para as saídas criadas por eles. A chave de cache é conhecida como a chave de ação. Um componente principal do modelo de incrementabilidade do Bazel. O cache é armazenado no diretório base de saída e resiste a reinicializações do servidor do Bazel.
Gráfico de ações
Um gráfico na memória de ações e 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), bem como artefatos
intermediários/finais gerados que não são mencionados nos arquivos BUILD
. Projetado durante a fase de análise e usado durante a fase de execução.
Consulta do gráfico de ações (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 em metadados de ação, que podem incluir o comando a ser executado na ação, flags do compilador, locais da biblioteca ou cabeçalhos do sistema, dependendo da ação. Permite que o Bazel armazene em cache ou invalide ações individuais de maneira determinista.
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ó precisa ser gerado por no máximo uma ação.
Um artefato que corresponde a um destino de arquivo pode ser tratado por um rótulo.
Aspecto
Um mecanismo para que as regras criem ações adicionais nas
dependências. Por exemplo, se o destino A depende de B, é possível aplicar um aspecto em
A que passa para cima uma borda de dependência até B e executa ações adicionais em B
para gerar e coletar outros arquivos de saída. Essas outras ações 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 ambientes de desenvolvimento integrado e criar ações de inspeção.
Consulte também: Documentação de aspectos
Aspecto relacionado
um mecanismo de composição em que os aspectos podem ser aplicados aos resultados
de outros. Por exemplo, um aspecto que gera informações para uso pelos
ambientes de desenvolvimento integrado pode ser aplicado sobre um aspecto que gera arquivos .java
com base em um
proto.
Para que um aspecto A
seja aplicado sobre o 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, as dependências e as opções personalizadas do compilador de um destino. Os atributos
específicos disponíveis para uma determinada meta dependem do tipo de regra.
.bazelrc
O arquivo de configuração do Bazel é usado para alterar os valores padrão de sinalizações
de inicialização e sinalizações de comando e definir grupos
comuns de opções que podem ser configurados juntos na linha de comando do Bazel usando
uma sinalização --config
. O Bazel pode combinar configurações de vários arquivos do Bazel
(em todo o sistema, por espaço de trabalho, por usuário ou de 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 monorepositório dele.
Arquivo BUILD
BUILD
é o arquivo de configuração principal que informa ao Bazel quais saídas de software
a serem criadas, quais são as dependências e como criá-las. Ele usa um arquivo BUILD
como entrada e o usa 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
destinos criados por regras. O arquivo também pode ser nomeado como
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 escritas 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 transfere para executar uma compilação. Inclui nós como destinos, destinos configurados, ações e artefatos. Um build é considerado concluído quando todos os artefatos de que um conjunto de destinos solicitados depende são verificados como atualizados.
Configuração do build
Uma parte da configuração definida pelo Starlark. Transições podem definir configurações de build para mudar a configuração de um subgráfico. Quando exposto ao usuário como uma sinalização de linha de comando, também conhecida como sinalização de build.
Build limpo
Um build que não usa os resultados de builds anteriores. Esse processo geralmente é mais lento do que um build incremental, mas é considerado mais correto. O Bazel garante que as builds limpas e incrementais estejam sempre corretas.
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 todos os comandos, mas é interrompido automaticamente após um período de inatividade (ou explicitamente por meio do desligamento do Bazel). Dividir o 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 entre 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
.
Sinalizações de comando
Um conjunto de sinalizações específicas de um comando. As flags de comando são especificadas
após o comando (bazel build <command flags>
). Elas podem ser aplicáveis a
um ou mais comandos. Por exemplo, --configure
é uma sinalização exclusivamente para o comando bazel sync
, mas --keep_going
é aplicável a sync
, build
, test
e muito mais. As flags geralmente são usadas para fins de configuração.
Portanto, mudanças nos valores delas podem fazer com que o Bazel invalide os gráficos na
memória e reinicie a fase de análise.
Configuração
Informações fora das definições de regra que afetam 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 sinalizações de compilação de linha de comando. As transições podem criar outras configurações, como ferramentas de host ou compilação cruzada.
Consulte também: Configurações
Corte de configuração
O processo de incluir apenas as partes da configuração de que um
destino realmente precisa. Por exemplo, se você criar //:j
binário Java com dependência
C++ //:c
, é desnecessário incluir o valor de --javacopt
na
configuração de //:c
, porque a alteração de --javacopt
interrompe desnecessariamente o armazenamento em cache
do build em C++.
Consulta configurada (cquery)
Uma ferramenta de consulta que consulta destinos configurados (após a conclusão da fase de análise). Isso significa que select()
e sinalizações de build (como
--platforms
) são refletidas com precisão nos resultados.
Consulte também: documentação do cquery
Destino configurado
O resultado da avaliação de um destino 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 //:foo
cria para duas arquiteturas diferentes no mesmo
build, ele tem dois destinos configurados: <//:foo, x86>
e <//:foo, arm>
.
Correção
Um build está correto quando a saída dele reflete fielmente o estado das entradas transitivas. Para criar builds corretos, o Bazel tenta ser hermético, reproduzível e tornar a análise de build e a execução de ações determinísticas.
Dependência
Uma borda direcionada entre dois destinos. Um //:foo
de destino terá uma dependência
de destino no destino //:bar
se os valores do atributo de //:foo
contiverem 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 determinados contextos, ele também pode se referir a uma dependência externa. Consulte módulos.
Desativar
Uma estrutura de dados para coletar dados em dependências transitivas. Otimizada para que a mesclagem de dependências seja eficiente em termos de tempo e espaço, porque é comum ter depósitos muito grandes (centenas de milhares de arquivos). Implementado para se referir recursivamente a outros depsets por motivos de eficiência de espaço. As implementações de regra não podem "nivelar" os provisionamentos convertendo-os em listas, a menos que a regra esteja no nível superior do gráfico de build. Nivelar grandes desativações causa um consumo enorme de memória. Também conhecidos como conjuntos aninhados na implementação interna do Bazel.
Consulte também: Documentação do Depset
Cache de disco
Um armazenamento de blobs local no 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 contendo arquivos que o Bazel pesquisaria da Internet usando regras de repositório. Permite que os builds sejam executados de forma totalmente off-line.
Execução dinâmica
Uma estratégia de execução que seleciona entre a execução local e remota com base em várias heurísticas e usa os resultados de execução do método bem-sucedido mais rápido. Certas ações são executadas localmente mais rapidamente (por exemplo, vinculação) e outras são mais rápidas remotamente (por exemplo, compilação altamente carregável em paralelo). Uma estratégia de execução dinâmica pode fornecer os melhores tempos de compilação 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: local, remotamente, dinamicamente, em sandbox, Docker e assim por diante.
Raiz de execução
Um diretório no diretório da base de saída do espaço de trabalho,
em que ações locais são executadas em builds
que não estão em sandbox. O conteúdo do diretório são principalmente 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
trânsito de pacotes de que depende um build. Acessível com bazel info
execution_root
na linha de comando.
Arquivo
Consulte Artifact.
Hermética
Um build é hermético quando não há influências externas nas operações de build e teste, o que ajuda a garantir que os resultados sejam deterministas e corretos. Por exemplo, as versões herméticas normalmente proíbem o acesso da 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ência 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
Identificador para 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 próprio destino. 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
(link em inglês) para
criar pacotes. Macros e determinadas funções, como glob()
, são avaliadas nessa fase. Intercalado com a segunda fase do build, a fase de análise, para criar um gráfico de destino.
Macro
Um mecanismo para compor várias declarações de meta de regra em uma única função Starlark. Permite reutilizar padrões de declaração de regra
comuns em arquivos BUILD
. Expandido para as declarações de meta de regra subjacente durante a fase de carregamento.
Consulte também: documentação sobre macros
Mnemônicos
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. As mnemônicas podem ser usadas como
identificadores para seleções de estratégia de criação. Alguns exemplos de mnemônicas de ação
são Javac
das regras do Java, CppCompile
das regras de C++ e
AndroidManifestMerger
das regras do Android.
Módulo
Um projeto Bazel que pode ter várias versões, cada uma das quais pode ter dependências em outros módulos. Isso é análogo a conceitos conhecidos em outros sistemas de gerenciamento de dependências, como um artefato Maven, um pacote npm, um módulo Go ou uma caixa Cargo. Os módulos são a espinha dorsal do sistema de gerenciamento de dependências externas do Bazel.
Cada módulo tem o suporte de 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), as dependências diretas e vários outros dados, incluindo registros de conjunto de ferramentas
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 Bazel
Extensão do módulo
Uma parte da lógica que pode ser executada para gerar repos lendo as entradas de todo o gráfico de dependências do módulo e invocando regras do repo. As extensões de módulo têm recursos semelhantes às regras de repositório, permitindo que elas acessem a Internet, realizem E/S de arquivos e assim por diante.
Consulte também: Extensões de módulo
Regras nativas
Regras, que são 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
). Regras definidas pelo usuário
(não nativas) são criadas usando Starlark.
Base de saída
Um diretório específico de workspace para armazenar arquivos de saída do Bazel. Usado para separar saídas da árvore de origem do espaço de trabalho (o repositório principal). Localizados na raiz do usuário de saída.
Grupos de saída
Um grupo de arquivos que precisa ser criado quando o Bazel termina a criação de um
destino. As regras colocam as saídas habituais 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 é aquele 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 explicitamente especificados em
arquivos BUILD
(regra filegroup
) ou na linha de comando
(sinalização --output_groups
).
Raiz do usuário de saída
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. Impede conflitos 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 destinos definido por um arquivo BUILD
. O nome de um pacote é o caminho do arquivo BUILD
relativo à raiz do repo. Um pacote pode conter subdiretórios ou subdiretórios que contêm arquivos BUILD
,
formando assim uma hierarquia de pacotes.
Grupo de pacotes
Um destino que representa um conjunto de pacotes. Geralmente usado em valores de
atributos 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 compilação de máquinas são executadas em plataformas ("exec") e os destinos das máquinas são criados para ("plataformas de destino").
Provedor
Um esquema que descreve uma unidade de informações a ser transmitida entre
destinos de regras e relações de dependência. Normalmente, isso
contém informações como opções de compilador, arquivos de origem ou saída transitivos
e metadados de build. Usado com frequência em conjunto com depsets para armazenar com eficiência os dados transitivos acumulados. Um exemplo de provedor integrado
é DefaultInfo
.
Consulte também: Documentação do provedor
Consulta (conceito)
O processo de analisar um gráfico de build para entender as propriedades de destino e as estruturas de dependência. O Bazel aceita três variantes de consulta: query, cquery e aquery.
consulta (comando)
Uma ferramenta de consulta que opera na fase pós-de carregamento do gráfico de destino do build. Esse processo é relativamente rápido,
mas não analisa os efeitos de select()
, flags de build,
artefatos nem ações de build.
Confira também: Instruções de consulta, 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 uma compilação do Bazel. Geralmente encurtado para apenas repo.
Um arquivo de marcador de limite do repo pode ser MODULE.bazel
(indicando que ele representa um módulo do Bazel), REPO.bazel
ou, em contextos legados, WORKSPACE
ou WORKSPACE.bazel
. Qualquer arquivo de marcador de limite de repo significa o limite de um repo. 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 repo 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 nomes aparentes potencialmente diferentes quando visualizados de outros repositórios.
Consulte também: Visão geral das dependências externas
Cache do repositório
Um cache endereçável de conteúdo compartilhado de arquivos transferidos por download pelo Bazel para builds,
compartilhável em espaços de trabalho. Ativa os builds off-line após o
download inicial. Comumente usado para armazenar em cache arquivos transferidos por download usando regras de
repositório, como http_archive
, e APIs de regra de repositório, como
repository_ctx.download
. Os arquivos serã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. Geralmente encurtado para apenas regra repo.
As regras de repo 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 repo 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 contenha arquivos de origem da
Internet.
Consulte também:documentação de regras de repo
Reprodutibilidade
A propriedade de um build ou teste de que um conjunto de entradas para o build ou teste sempre produz o mesmo conjunto de saídas todas as vezes, independentemente do tempo, método ou ambiente. Isso não significa necessariamente que as saídas estão corretas ou que são esperadas.
Regra
Um esquema para definir metas de regras em um arquivo BUILD
, como cc_library
. Da perspectiva de um autor de arquivo BUILD
, uma regra consiste em
um conjunto de atributos e lógica de caixa preta. A lógica informa à
meta de regra como produzir artefatos de saída e transmitir informações para
outros destinos de regra. Da perspectiva dos autores do .bzl
, as regras são a
principal maneira de estender o Bazel para oferecer suporte a novas linguagens de programação e
ambientes.
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 realizadas na fase de execução.
Confira também:Documentação de regras
Meta da regra
Um destino que é uma instância de uma regra. Contrasta com destinos de arquivo e grupos de pacotes. Não confunda com rule.
Arquivos de execução
As dependências do ambiente de execução de um destino executável. Geralmente, 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 ambiente de execução do teste. Antes da invocação do executável (durante o teste do Bazel), o Bazel prepara a árvore de arquivos de execução junto com o executável de teste de acordo com a estrutura do diretório de origem.
Confira também:documentação de 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 do desempenho depende da plataforma. No Linux, isso não é significativo, mas no macOS pode tornar o sandbox inutilizável.
Skyframe
O Skyframe (em inglês) é o principal framework de avaliação paralela, funcional e incremental do Bazel.
Estampagem
Um recurso para incorporar mais informações a artefatos criados pelo Bazel. Por exemplo, isso pode ser usado para controle de origem, tempo de build
e outras informações relacionadas ao espaço de trabalho ou ao ambiente para builds de lançamento.
Ative com a sinalização --workspace_status_command
e as regras compatíveis com o atributo de carimbo.
Lark
A linguagem de extensão para escrever regras e macros. Um subconjunto restrito do Python, sintática e gramaticalmente, destinado para fins de configuração e para melhor desempenho. Usa a extensão de arquivo .bzl
. Os arquivos BUILD
usam uma versão
ainda mais restrita do Starlark (como nenhuma definição de função def
), anteriormente
conhecida como Skylark.
Confira também: documentação da linguagem Starlark
Sinalizações de inicialização
O conjunto de sinalizações especificadas entre bazel
e o comando,
por exemplo, build --host_jvm_debug
do bazel. Essas sinalizações modificam a
configuração do servidor do Bazel. Portanto, qualquer modificação nas
flags de inicialização causa uma reinicialização do servidor. As sinalizações de inicialização não são específicas de nenhum comando.
Resposta
Um objeto definido em um arquivo BUILD
e identificado por um
rótulo. Os destinos representam as unidades edificáveis de um espaço de trabalho da perspectiva do usuário final.
Um destino declarado ao instanciar uma regra é chamado de destino da regra. Dependendo da regra, elas podem ser executadas (como
cc_binary
) ou testáveis (como cc_test
). Os destinos de regra normalmente dependem
de outros destinos usando os atributos deles (como deps
). Essas
dependências formam a base do gráfico de destino.
Além dos destinos de regra, também há destinos de arquivo e de
grupo de pacotes. Os destinos de arquivo correspondem a artefatos que são referenciados
em um arquivo BUILD
. Como 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 do build para formar destinos configurados.
Gráfico de destino
Um gráfico na memória de destinos e as dependências deles. produzido durante a fase de carregamento e usado como entrada para a fase de análise.
Padrão de destino
É uma forma de especificar um grupo de destinos na linha de comando. Os padrões
mais usados são :all
(todos os destinos de regra), :*
(todas as regras + destinos de arquivo),
...
(pacote atual e todos os subpacotes recursivamente). Pode ser usado em combinação. Por exemplo, //...:*
significa todos os destinos de regras e arquivos em todos os pacotes recursivamente a partir da raiz do espaço de trabalho.
Testes
A regra é destino instanciada pelas regras de teste e, portanto, contém um executável de teste. Um código de retorno zero da conclusão do executável indica que o teste foi bem-sucedido. O contrato exato entre o Bazel e os testes (como variáveis de ambiente de teste e 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/e linters. Um conjunto de ferramentas também pode variar de acordo com a plataforma, ou seja, os componentes de um conjunto de ferramentas do compilador Unix podem ser diferentes para a variante do Windows, mesmo que ele seja para a mesma linguagem. A seleção do conjunto de ferramentas correto para a plataforma é conhecida como resolução do conjunto de ferramentas.
Meta de nível superior
Um destino de build é de nível superior quando 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 nível superior, e //:bar
não será
de nível superior, embora os dois destinos precisem ser criados. Uma diferença importante
entre objetivos de nível superior e de nível superior é que as flags de
comando definidas na linha de comando do Bazel (ou por
.bazelrc) definem a configuração para destinos
de nível superior, mas podem ser modificadas por uma transição para destinos
que não são de nível superior.
Condição da
Um mapeamento do estado de configuration de um valor para outro. Permite que os destinos no gráfico de build tenham configurações diferentes, mesmo que tenham sido instanciados da mesma regra. Um uso comum de transições é com transições divididas, em que algumas 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.
Confira 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 da árvore como entrada ou saída.
Visibilidade
Um dos dois mecanismos para evitar dependências indesejadas no sistema de build:
visibilidade do destino para controlar se um destino pode depender
de outros destinos e visibilidade da carga para controlar se um arquivo BUILD
ou .bzl
pode carregar determinado arquivo .bzl
. Sem contexto, geralmente
"visibilidade" 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 "workspace" foram confundidos. O termo "workspace" é frequentemente usado para se referir ao repositório principal e às vezes usado até mesmo como sinônimo de "repositório". Para fins de esclarecimento, esse uso precisa ser evitado.