Glossário do Bazel

Relatar um problema Conferir código-fonte Por noite · 7,3 · 7,2 · 7,1 · 7,0 · 6,5

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.