Ação
Um comando a ser executado durante a compilação, por exemplo, uma chamada a um compilador que leva artifacts como entradas e produz outros artefatos como saídas. Inclui metadados, como os argumentos de linha de comando, a chave de ação, o ambiente variáveis e 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 o das saídas criadas. 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, assim, sobrevive às reinicializações do servidor do Bazel.
Gráfico de ações
Um gráfico na memória de ações e artefatos que
que essas ações leem e geram. O gráfico pode incluir artefatos que existem
arquivos de origem (por exemplo, no sistema de arquivos), assim como os
artefatos intermediários/finais que não são mencionados nos arquivos BUILD. Produção
durante a fase de análise e usada durante a execução
fase de testes.
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 criação se traduzem na as construções de trabalho reais fazem.
Tecla de ação
A chave de cache de uma ação. são calculados com base em metadados de ação, pode incluir o comando a ser executado na ação, flags do compilador, biblioteca locais ou cabeçalhos do sistema, dependendo da ação. Permite que o Bazel armazene em cache ou e invalidar ações individuais de maneira determinista.
Fase de análise
A segunda fase de um build. processa o gráfico de destino;
especificado em arquivos BUILD para produzir uma ação na memória
gráfico que determina a ordem das ações a serem executadas durante
fase de execução. Esta é a fase em que a regra
e as implementações 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ó deve 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 as regras criarem ações adicionais em seu
dependências. Por exemplo, se o destino A depende de B, é possível aplicar um aspecto
A que atravessa para cima uma borda de dependência até B e executa ações adicionais em B
para gerar e coletar mais arquivos de saída. Essas ações adicionais são
armazenados em cache e reutilizados entre destinos que exigem o mesmo aspecto. Criado com o
aspect() Função da API Starlark Build. Pode ser usado, por exemplo, para gerar
metadados para ambientes de desenvolvimento integrado e criar ações para inspeção.
Consulte também: Documentação de aspectos
Aspecto relacionado
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
Os ambientes de desenvolvimento integrado podem ser aplicados sobre um aspecto que gera arquivos .java de um
proto.
Para que um aspecto A seja aplicado sobre o aspecto B, os provedores que
B anuncia no próprio atributo provides
precisa corresponder ao que A declara que quer em 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 uma
arquivos de origem, dependências e opções personalizadas do compilador do destino. O método
os atributos 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 inicialização
sinalizações e sinalizações de comando, além de definir sinalizações
grupos de opções que podem ser definidos 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 em um local personalizado) e um
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 mono-repositório.
Arquivo BUILD
BUILD é o arquivo de configuração principal que informa ao Bazel quais softwares
e saídas para criar, quais são as dependências e como criá-las. Júlio
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 versões intermediárias e finais
saídas de software. Um arquivo BUILD marca um diretório e todos os subdiretórios que não são
contendo um arquivo BUILD como um pacote e pode conter
destinos 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 na mesma
diretório.
Arquivo .bzl
Arquivo que define regras, macros e constantes escritas
Starlark (link em inglês). Eles podem ser importados para o 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, configurados destinos, ações e artefatos. Um build é considerado concluído quando todos os artefatos em que um conjunto de os destinos solicitados dependem de estarem atualizados.
Configuração do build
Uma parte da configuração definida pelo Starlark. Transições podem definir configurações de build para alterar o subgráfico configuração do Terraform. Se exposto ao usuário como uma sinalização de linha de comando, também conhecida como flag 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 normalmente considerados mais correto. O Bazel garante builds limpos e incrementais estão sempre corretas.
Modelo cliente-servidor
O cliente de linha de comando bazel inicia automaticamente um servidor em segundo plano no
máquina local para executar comandos do Bazel. O servidor persiste
mas para automaticamente após um período de inatividade (ou explicitamente por meio de
o encerramento do Bazel). Dividir o Bazel em um servidor e um cliente ajuda a amortizar a JVM.
tempo de inicialização 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.
Sinalizações de comando
Um conjunto de sinalizações específicas de um comando. As flags de comando são especificadas
depois do comando (bazel build <command flags>). As flags podem ser aplicáveis a
um ou mais comandos. Por exemplo, --configure é uma sinalização exclusiva para o
bazel sync, mas --keep_going é aplicável a sync, build,
test e mais. As flags costumam ser usadas para configuração.
Portanto, mudanças nos valores de flag podem fazer com que o Bazel invalide a memória
gráficos e reiniciar a fase de análise.
Configuração
Informações fora das definições de regra que afetam como as regras são geradas. ações. Cada build tem pelo menos uma configuração que especifica plataforma de destino, variáveis de ambiente de ação e build de linha de comando de resposta. Transições podem criar como ferramentas host ou compilação cruzada.
Consulte também: Configurações
Corte de configuração
O processo de incluir apenas as partes da configuração que um
de que o alvo realmente precisa. Por exemplo, se você criar um binário //:j Java com C++.
//:c, é desnecessário incluir o valor de --javacopt no
de //:c, porque mudar --javacopt desnecessariamente causa falhas no C++
e criar capacidade de armazenamento em cache.
Consulta configurada (cquery)
Uma ferramenta de consulta que consulta os parâmetros configurados
metas (após a fase de análise
é concluída). Isso significa 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
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 dos e entradas transitivas. Para criar as compilações corretas, o Bazel se esforça para ser herméticas, reprodutíveis e criar versões análise e execução de ações determinista.
Dependência
Uma borda direcionada entre dois destinos. Um //:foo de destino tem um destino
dependência no destino //:bar se os valores de atributo de //:foo contiverem um
referência a //:bar. //:foo tem uma dependência de ação em //:bar se uma
em //:foo depende de um artefato de entrada criado por um
em //:bar.
Em determinados contextos, também pode se referir a uma dependência externa. ver módulos.
Desativar
Uma estrutura de dados para coletar dados em dependências transitivas. Otimizado para que a fusão de desvios é eficiente em tempo e espaço, porque é comum ter servidores muito grandes (centenas de milhares de arquivos). Implementado para consultar recursivamente outras descontinuações por motivos de eficiência de espaço. Regra as implementações não podem "nivelar" desativação, convertendo-os em listas, a menos que a regra está no nível superior do gráfico de build. Nivelar grandes desenvolvimentos incorre enorme consumo de memória. Também conhecidos como conjuntos aninhados no sistema interno implementação.
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 junto com um repositório de blobs remoto real.
Distdir
Um diretório somente leitura contendo arquivos que o Bazel buscaria no 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 execução local e remota com base em diversas heurísticas e usa os resultados da execução do modelo mais rápido . Certas ações são executadas mais rapidamente no local (por exemplo, e outras são mais rápidas e remotas (por exemplo, são altamente carregáveis em paralelo compilação). Uma estratégia de execução dinâmica pode oferecer a melhor tempos de build limpos e incrementais.
Fase de execução
A terceira fase de um build. Executa as ações na ação gráfico criado durante a fase de análise. Essas ações invocam executáveis (compiladores, scripts) para ler e gravar artifacts. As estratégias de geração controlam como essas ações são executadas: localmente, remotamente, dinamicamente, em sandbox, docker e assim por diante.
Raiz de execução
Um diretório na base de saída do espaço de trabalho
onde as ações locais são executadas
que não estão no sandbox. O conteúdo do diretório é 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 bazel-out
para armazenar as saídas. Preparado durante a fase de carregamento.
criando uma floresta de links simbólicos dos diretórios que representam os
o fechamento de pacotes dos quais depende um build. Acessível com bazel info
execution_root na linha de comando.
Arquivo
Consulte Artifact.
Hermeticity
Um build é hermético se não houver influências externas no build e no teste. operações, o que ajuda a garantir que os resultados sejam determinísticos correto. Por exemplo, builds herméticos normalmente não permitem a autenticação de rede a ações, restringir o acesso a entradas declaradas, usar carimbos de data/hora fixos fusos horários, restringir o acesso a variáveis de ambiente e usar 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 para esse tipo de build. Um build incremental é o oposto de um build limpo ser construído.
Rótulo
Identificador para um destino. Geralmente tem a forma
@repo//path/to/package:target, em que repo é o nome (aparente) do
repository que contém o destino, path/to/package é o caminho
ao diretório que contém o arquivo BUILD declarando o
target (esse diretório também é conhecido como pacote) e target
é o nome do próprio destino. Dependendo da situação, partes deste
pode ser omitida.
Consulte também: Rótulos
Fase de carregamento
A primeira fase de uma compilação em que o Bazel executa arquivos BUILD (link em inglês) para
criar pacotes. Macros e certas funções, como
glob() são avaliados nesta fase. Intercalado com a segunda fase do
criação, a fase de análise, para criar um destino
gráfico.
Macro
Um mecanismo para compor várias declarações de meta de regra juntas em
uma única função Starlark. Ativa a reutilização da declaração de regra comum
padrões em arquivos BUILD. Expandido para a segmentação da regra subjacente
de declarações durante a fase de carregamento.
Consulte também: documentação sobre macros
Mnemônicos
String curta e legível por humanos selecionada pelo autor da regra para entender rapidamente
o que uma ação na regra está fazendo. As mnemônicas podem ser usadas
identificadores para seleções de estratégias de origem. Alguns exemplos de mnemônicas 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 delas 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, uma Módulo Go ou uma caixa Cargo. Os módulos são a espinha dorsal da arquitetura de gerenciamento de dependências.
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
), suas dependências diretas e vários outros dados, incluindo o conjunto de ferramentas
registros e entrada de extensão do 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 entradas de todo o gráfico de dependência module e invocar o repo regras. As extensões de módulo têm recursos semelhantes aos repositórios de acesso, 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, 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 nativos) são criados 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 (a configuração repositório). 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
alvo. 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 cc_library
de destino). O grupo de saída padrão é aquele cujo
artifacts 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 a 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. Evita colisões de arquivos de saída se vários usuários estão construindo 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 conhecidas como bases de saída.
Pacote
O conjunto de destinos definido por um arquivo BUILD. Um
o nome do pacote é o caminho do arquivo BUILD relativo ao repo
raiz. Um pacote pode conter subdiretórios ou subdiretórios contendo BUILD
arquivos, formando assim uma hierarquia de pacotes.
Grupo de pacotes
Um destino que representa um conjunto de pacotes. Geralmente usados em visibility
.
Plataforma
Um "tipo de máquina" envolvidos em um build. Isso inclui a máquina em que o Bazel é executado (a plataforma "host"), as ferramentas de build 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
metas de regra junto com as relações de dependência. Normalmente, isso
contém informações como opções de compilador, arquivos de origem ou de saída transitivos,
e criar metadados. Usado frequentemente em conjunto com depsets para
armazenar de modo eficiente os dados transitivos acumulados. 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 propriedades de destino e estruturas de dependência. O Bazel oferece suporte a três variantes de consulta: query, cquery e aquery.
consulta (comando)
Uma ferramenta de consulta que opera sobre o pós-carregamento do build
fase gráfico de destino. Esse processo é relativamente rápido,
mas não consegue analisar os efeitos de select(), flags de build,
artefatos ou ações de criação.
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 o código-fonte que podem ser usados em uma versão do Bazel. Geralmente encurtado para apenas repo.
Um arquivo de marcador de limite do repositório pode ser MODULE.bazel, indicando 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 representará 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 MODULE.bazel.
arquivos, ou invocar regras de repositório em módulo
extensões. Eles podem ser buscados sob demanda
"mágico" local no disco.
Cada repositório tem um nome canônico exclusivo e constante e pode apparent quando visualizados em 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áveis entre espaços de trabalho. Ativa os builds off-line após o
download inicial. Comumente usado para armazenar em cache arquivos baixados por meio do repositório
regras, 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
especificado para o download.
Regra de repositório
Um esquema para definições de repositório que informa ao Bazel como materializar (ou
"fetch") um repositório. Geralmente encurtado para apenas regra repo.
As regras de repo são invocadas pelo Bazel internamente para definir os repositórios apoiados por
módulos ou pode ser invocado por extensões de módulo.
As regras de repositório podem acessar a Internet ou realizar E/S de arquivos. o repositório mais comum
regra é http_archive para fazer o download de um arquivo que contém arquivos de origem da
Internet.
Consulte também:documentação de regras de repo
Reprodutibilidade
A propriedade de um build ou teste que um conjunto de entradas do build ou teste vai sempre produzem o mesmo conjunto de saídas, independentemente do tempo, método, ou ambiente. Isso não significa necessariamente que os resultados sejam corrigir ou os resultados desejados.
Regra
Um esquema para definir metas de regras em um arquivo BUILD, como:
cc_library. Da perspectiva do autor de um arquivo BUILD, uma regra consiste em
um conjunto de atributos e lógica de caixa preta. A lógica diz
meta de regra como produzir artefatos de saída e transmitir informações para
outras segmentações de regra. Da perspectiva de .bzl autores, as regras são os
forma principal de estender o Bazel para dar suporte a novas linguagens de programação e
e ambientes de teste.
As regras são instanciadas para produzir destinos de regras no fase de carregamento. Na regra da fase de análise comunicam informações para suas dependências downstream na forma de provedores de serviços e registrar ações que descrevem como gerar os artefatos de saída. Essas ações são realizadas na classe de execução fase de testes.
Confira também:Documentação de regras
Meta da regra
Um destino que é uma instância de uma regra. Contrasta com os 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, os "Executável" é a saída executável de uma regra de teste, e os arquivos de execução são arquivos dependências de dados do teste. Antes da invocação do executável (durante 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 de diretórios 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 temporária, ajudando a garantir que ela não ler entradas não declaradas ou gravar saídas não declaradas. A sandbox melhora bastante 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 bancos de dados criados pelo Bazel
artifacts. Por exemplo, isso pode ser usado para controle de origem,
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 que
são compatíveis com o atributo carimbo.
Lark
A linguagem de extensão para escrever regras e macros. Um
subconjunto restrito do Python (sintática e gramaticalmente) voltado para o
a finalidade da configuração e para melhorar o desempenho. Usa o .bzl
.tf. Arquivos BUILD usam uma versão
versão 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 command,
Por exemplo, o build --host_jvm_debug do Bazel. Essas sinalizações modificam a
configuração do servidor do Bazel. Assim, qualquer modificação feita
os sinalizadores de inicialização fazem com que o servidor seja reiniciado. As flags de inicialização não são específicas
kubectl.
Destino
Um objeto que é definido em um arquivo BUILD e identificado por uma
rótulo. Os destinos representam as unidades edificáveis de um espaço de trabalho
do ponto de vista do usuário final.
Um destino declarado ao instanciar uma regra é chamada de regra
destino. Dependendo da regra, eles podem ser executados (como
cc_binary) ou testáveis (como cc_test). As metas de regra normalmente dependem
outros destinos usando os atributos deles (como deps); esses
dependências formam a base do gráfico de destino.
Além dos destinos de regras, há também destinos de arquivo e pacotes de pacotes
de destino. Os destinos de arquivo correspondem aos artefatos que são 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 o fase de análise, os destinos são associados ao módulo build personalizadas para formar os tipos configurados de destino.
Gráfico de destino
Um gráfico na memória de destinos e as dependências deles. produzido durante a fase de carregamento e usada como entrada para a análise fase de testes.
Padrão de destino
É uma forma de especificar um grupo de destinos na linha de comando. Comumente
os padrões usados são :all (todos os destinos de regras), :* (todos os destinos de regras + arquivos),
... (o pacote atual e todos os subpacotes recursivamente). Pode ser usado
em combinação, por exemplo, //...:* significa todos os destinos de regra e arquivo em todos
pacotes recursivamente 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 o sucesso do teste. O contrato exato entre o Bazel e os testes (como variáveis de ambiente, métodos de coleta de resultados de teste) é especificado na tag Enciclopédia.
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. Um conjunto de ferramentas também pode variar ou seja, os componentes de um conjunto de ferramentas do compilador Unix podem diferir para a Variante do Windows, mesmo que o conjunto de ferramentas seja para a mesma linguagem. Selecionando o conjunto de ferramentas correto para a plataforma é conhecido como resolução do conjunto de ferramentas.
Meta de nível superior
Um destino de build é de nível superior se for solicitado no comando do Bazel.
linha Por exemplo, se //:foo depender de //:bar e bazel build //:foo for
chamado, então, para este build, //:foo é de nível superior, e //:bar não é
e de alto nível, mas é necessário criar ambos os destinos. Uma diferença importante
entre metas de nível superior e outras metas é que o comando
flags definidas na linha de comando do Bazel (ou via
.bazelrc) vai definir a configuração dos recursos de nível superior
de destino, mas podem ser modificadas por uma transição para elementos que não são
de destino.
Transição
Um mapeamento do estado de configuration de um valor para outro. Permite que os destinos no gráfico de build tenham diferentes configurações, mesmo que tenham sido instanciadas da mesma regra. Um O uso comum das transições é com transições divididas, em que certas partes do o gráfico de destino é bifurcado com configurações distintas para cada garfo. Por exemplo, é possível criar um APK Android com binários nativos. compilado para ARM e x86 usando transições de divisão 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 não são artefatos, uma ação que opera neles precisa registre o artefato de árvore como entrada ou saída dele.
Visibilidade
Um dos dois mecanismos para evitar dependências indesejadas no sistema de compilação:
visibilidade do destino para controlar se um destino pode ser dependente
por outros alvos; e visibilidade de carregamento para controlar se um BUILD
ou .bzl pode carregar um determinado arquivo .bzl. Sem contexto, geralmente
"visibilidade" refere-se à 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 ambiente repositório.
Historicamente, os conceitos de "repositório" e "workspace" foram misturado; o termo "espaço de trabalho" tem sido usada muitas vezes para se referir ao principal repositório e às vezes usada até mesmo como sinônimo de "repositório". Tal uso devem ser evitados para fins de esclarecimento.