Definições comuns

Informar um problema Acessar o código-fonte

Nesta seção, definimos vários termos e conceitos comuns a muitas funções ou regras de criação.

Conteúdo

Tokenização Bourne Shell

Alguns atributos de string de algumas regras são divididos em várias palavras de acordo com as regras de tokenização do shell Bourne: espaços sem aspas delimitam palavras separadas, e caracteres de aspas simples e duplas e barras invertidas são usados para impedir a tokenização.

Os atributos sujeitos a essa tokenização são explicitamente indicados como tal nas definições neste documento.

Os atributos sujeitos à expansão de variável "Make" e a tokenização de shell Bourne são normalmente usados para passar opções arbitrárias para compiladores e outras ferramentas. Exemplos desses atributos são cc_library.copts e java_library.javacopts. Juntas, essas substituições permitem que uma única variável de string se expanda em uma lista específica da configuração de palavras de opção.

Expansão de rótulos

Alguns atributos de string de poucas regras estão sujeitos à expansão de rótulo: se essas strings contiverem um rótulo válido como uma substring, como //mypkg:target, e esse rótulo for um pré-requisito declarado da regra atual, ele será expandido para o nome do caminho do arquivo representado pelo //mypkg:target de destino.

Os exemplos de atributos incluem genrule.cmd e cc_binary.linkopts. Os detalhes podem variar significativamente em cada caso, em relação a problemas como: se rótulos relativos são expandidos, como os rótulos que se expandem para vários arquivos são tratados etc. Consulte a documentação de atributos da regra para mais detalhes.

Atributos típicos definidos pela maioria das regras de compilação

Esta seção descreve os atributos que são definidos por muitas regras de build, mas não por todas.

Atributo Descrição
data

Lista de rótulos. O padrão é [].

Arquivos necessários para essa regra no momento da execução. Pode listar segmentações por arquivo ou regras. Geralmente, qualquer destino.

As saídas e os arquivos de execução padrão dos destinos no atributo data precisam aparecer na área *.runfiles de qualquer executável que seja saída por esse destino ou que tenha uma dependência de execução nesse destino. Isso pode incluir arquivos de dados ou binários usados quando o srcs desse destino é executado. Consulte a seção dependências de dados para mais informações sobre como usar e usar arquivos de dados.

As novas regras vão definir um atributo data se processarem entradas que possam usar outras no momento da execução. As funções de implementação das regras também precisam preencher os arquivos de execução do destino com base nas saídas e nos arquivos de execução de qualquer atributo data, bem como nos arquivos de execução de qualquer atributo de dependência que forneça código-fonte ou dependências de ambiente de execução.

deps

Lista de rótulos. O padrão é [].

Dependências para esse destino. Em geral, lista apenas os destinos de regra. Embora algumas regras permitam que os arquivos sejam listados diretamente em deps, isso precisa ser evitado sempre que possível.

As regras específicas do idioma geralmente limitam os destinos listados àqueles com provedores específicos.

A semântica precisa do que um destino significa depender de outra usando deps é específica para o tipo de regra, e a documentação específica da regra entra em mais detalhes. Para regras que processam código-fonte, deps geralmente especifica as dependências usadas pelo código em srcs.

Na maioria das vezes, uma dependência deps é usada para permitir que um módulo use símbolos definidos em outro módulo escrito na mesma linguagem de programação e compilado separadamente. As dependências entre idiomas também são permitidas em muitos casos. Por exemplo, um destino java_library pode depender do código C++ em um destino cc_library, listando o último no atributo deps. Consulte a definição de dependências para mais informações.

licenses

Lista de strings. Não configurável. O padrão é ["none"]

Uma lista de strings do tipo licença a serem usadas para esse destino específico. Ela faz parte de uma API de licenciamento descontinuada que o Bazel não usa mais. Não use isso.

srcs

Lista de rótulos. O padrão é [].

São os arquivos processados ou incluídos por essa regra. Geralmente, lista arquivos diretamente, mas pode listar destinos de regras (como filegroup ou genrule) para incluir as saídas padrão.

As regras específicas do idioma geralmente exigem que os arquivos listados tenham extensões específicas de arquivo.

Atributos comuns a todas as regras de build

Esta seção descreve os atributos que são adicionados implicitamente a todas as regras de build.

Atributo Descrição
compatible_with

Lista de rótulos, não configurável. O padrão é []

A lista de ambientes para os quais este destino pode ser criado, além dos ambientes compatíveis com o padrão.

Isso faz parte do sistema de restrições do Bazel, que permite que os usuários declarem quais destinos podem ou não depender uns dos outros. Por exemplo, binários implantáveis externamente não podem depender de bibliotecas com código secreto da empresa. Consulte ConstraintSemantics para mais detalhes.

deprecation

String nonconfigurable. O padrão é None

Uma mensagem de aviso explicativa associada ao destino. Normalmente, isso é usado para notificar os usuários de que um destino se tornou obsoleto ou foi substituído por outra regra, é particular para um pacote ou é considerado nocivo por algum motivo. É uma boa ideia incluir alguma referência (como uma página da Web, um número de bug ou exemplos de CLs de migração) para que seja possível descobrir facilmente quais alterações são necessárias para evitar a mensagem. Se houver um novo destino que possa ser usado como substituição, é uma boa ideia migrar todos os usuários do destino antigo.

Esse atributo não tem efeito na forma como as coisas são criadas, mas pode afetar a saída de diagnóstico de uma ferramenta de build. A ferramenta de build emite um aviso quando uma regra com um atributo deprecation depende de um destino em outro pacote.

As dependências intrapacotes estão isentas desse aviso, de modo que, por exemplo, a criação dos testes de uma regra descontinuada não encontre um aviso.

Se um destino descontinuado depender de outro destino descontinuado, nenhuma mensagem de aviso será emitida.

Depois que as pessoas pararem de usá-lo, a segmentação poderá ser removida.

distribs

Lista de strings. Não configurável. O padrão é []

Uma lista de strings de método de distribuição a serem usadas para este destino específico. Ela faz parte de uma API de licenciamento descontinuada que o Bazel não usa mais. Não use isso.

exec_compatible_with

Lista de rótulos, não configurável. O padrão é []

Uma lista de constraint_values que precisa estar presente na plataforma de execução para esse destino. Isso complementa as restrições já definidas pelo tipo de regra. As restrições são usadas para restringir a lista de plataformas de execução disponíveis. Para mais detalhes, consulte a descrição da resolução do conjunto de ferramentas.

exec_properties

Dicionário de strings. O padrão é {}

Um dicionário de strings que serão adicionadas ao exec_properties de uma plataforma selecionada para esse destino. Consulte o exec_properties da regra platform.

Se uma chave estiver presente nas propriedades no nível da plataforma e do destino, o valor será retirado do destino.

features

Lista de strings de recursos. O padrão é []

Um recurso é uma tag de string que pode ser ativada ou desativada em um destino. O significado de um recurso depende da própria regra.

Esse atributo features é combinado com o atributo features no nível do pacote. Por exemplo, se os recursos ["a", "b"] estiverem ativados no nível do pacote e o atributo features de um destino contiver ["-a", "c"], os recursos ativados para a regra serão "b" e "c". Confira um exemplo.

restricted_to

Lista de rótulos, não configurável. O padrão é []

A lista de ambientes para os quais esse destino pode ser criado em vez de ambientes compatíveis com o padrão.

Isso faz parte do sistema de restrições do Bazel. Consulte compatible_with para mais detalhes.

tags

Lista de strings. Não configurável. O padrão é []

Tags podem ser usadas em qualquer regra. Tags nas regras test_suite e teste são úteis para categorizar os testes. Tags em destinos que não são de teste são usadas para controlar a execução em sandbox de genrules e ações do Starlark e para análise por humanos e/ou ferramentas externas.

O Bazel modifica o comportamento do código de sandbox se encontrar as seguintes palavras-chave no atributo tags de qualquer destino de teste ou genrule, ou as chaves de execution_requirements para qualquer ação do Starlark.

  • A palavra-chave no-sandbox faz com que a ação ou o teste nunca sejam colocados no sandbox. Ela ainda pode ser armazenada em cache ou executada remotamente. Use no-cache ou no-remote para evitar uma ou ambas.
  • A palavra-chave no-cache faz com que a ação ou o teste nunca sejam armazenados em cache (localmente ou remotamente). Observação: para essa tag, o cache de disco é considerado um cache local, enquanto os caches HTTP e gRPC são considerados remotos. Outros caches, como o Skyframe ou o cache de ação persistente, não são afetados.
  • A palavra-chave no-remote-cache faz com que a ação ou o teste nunca sejam armazenados em cache remotamente, mas podem ser armazenados em cache localmente e podem ser executados remotamente. Observação: para essa tag, o cache de disco é considerado um cache local, enquanto os caches HTTP e gRPC são considerados remotos. Outros caches, como o Skyframe ou o cache de ação persistente, não são afetados. Se uma combinação de cache de disco local e remoto for usada (cache combinado), ele será tratado como remoto e desativado completamente, a menos que --incompatible_remote_results_ignore_disk seja definido. Nesse caso, os componentes locais serão usados.
  • A palavra-chave no-remote-exec faz com que a ação ou o teste nunca sejam executados remotamente (mas pode ser armazenado em cache remotamente).
  • A palavra-chave no-remote impede que a ação ou o teste sejam executados remotamente ou armazenados em cache remotamente. Isso equivale a usar no-remote-cache e no-remote-exec.
  • A palavra-chave no-remote-cache-upload desativa o upload de parte do armazenamento em cache remoto de um spawn. ele não desativa a execução remota.
  • A palavra-chave local impede que a ação ou o teste sejam armazenados em cache, executados remotamente ou executados dentro do sandbox. Para regras gerais e testes, a marcação da regra com o atributo local = True tem o mesmo efeito.
  • A palavra-chave requires-network permite acesso à rede externa dentro do sandbox. Essa tag só tem efeito quando o sandbox está ativado.
  • A palavra-chave block-network bloqueia o acesso à rede externa dentro do sandbox. Nesse caso, apenas a comunicação com o localhost é permitida. Essa tag só tem efeito se o sandbox estiver ativado.
  • requires-fakeroot executa o teste ou a ação como uid e gid 0 (ou seja, o usuário raiz). Isso só é compatível com Linux. Essa tag tem precedência sobre a opção de linha de comando --sandbox_fake_username.

As tags em testes geralmente são usadas para anotar o papel de um teste no processo de depuração e lançamento. Normalmente, as tags são mais úteis para testes C++ e Python, que não têm capacidade de anotação no ambiente de execução. O uso de tags e elementos de tamanho oferece flexibilidade na montagem de conjuntos de testes com base na política de check-in da base de código.

O Bazel modifica o comportamento de execução do teste se encontra as seguintes palavras-chave no atributo tags da regra de teste:

  • exclusive forçará a execução do teste no modo "exclusivo", garantindo que nenhum outro teste seja executado ao mesmo tempo. Esses testes serão executados em série após a conclusão de toda a atividade de build e dos testes não exclusivos. A execução remota está desativada para esses testes porque o Bazel não tem controle sobre o que é executado em uma máquina remota.
  • exclusive-if-local forçará a execução do teste no modo "exclusivo" se for executado localmente, mas executará o teste em paralelo se for executado remotamente.
  • A palavra-chave manual excluirá o destino da expansão de caracteres curinga de padrão de destino (..., :*, :all etc.) e regras test_suite que não listam o teste explicitamente ao calcular o conjunto de destinos de nível superior a serem criados/executados para os comandos build, test e coverage. Ele não afeta o caractere curinga de destino ou a expansão do pacote de testes em outros contextos, incluindo o comando query. Observe que manual não implica que um destino não pode ser criado/executado automaticamente por sistemas de compilação/teste contínuos. Por exemplo, pode ser desejável excluir um destino de bazel test ... porque exige flags específicas do Bazel, mas ainda inclui o destino em pré-envio ou em execuções de teste contínuas.
  • A palavra-chave external forçará a execução do teste incondicionalmente (independentemente do valor --cache_test_results).
Consulte as Convenções de tags na Enciclopédia de Teste para conferir mais convenções sobre tags anexadas aos destinos de teste.
target_compatible_with

Lista de rótulos. O padrão é [].

Uma lista de constraint_values que precisam estar presentes na plataforma para que esse destino seja considerado compatível. Isso é adicionado a todas as restrições já definidas pelo tipo de regra. Se a plataforma de destino não atender a todas as restrições listadas, o destino será considerado incompatible. Destinos incompatíveis são ignorados para criação e teste quando o padrão de destino é expandido (por exemplo, //..., :all). Quando especificados explicitamente na linha de comando, destinos incompatíveis fazem com que o Bazel imprima um erro e cause uma falha de compilação ou teste.

Os destinos que dependem transitivamente de destinos incompatíveis também são considerados incompatíveis. Elas também são ignoradas para criação e teste.

Uma lista vazia (que é o padrão) significa que o destino é compatível com todas as plataformas.

Todas as regras diferentes das regras do espaço de trabalho aceitam esse atributo. Para algumas regras, esse atributo não tem efeito. Por exemplo, especificar target_compatible_with para um cc_toolchain não é útil.

Consulte a página Plataformas para mais informações sobre a incompatibilidade de pular destinos.

testonly

Booleano, não configurável. O padrão é False, exceto para destinos de conjuntos de testes e testes.

Se for True, somente destinos somente de teste (como testes) poderão depender desse destino.

Igualmente, uma regra que não seja testonly não pode depender de nenhuma regra que seja testonly.

Os testes (regras *_test) e os conjuntos de testes (regras test_suite) são testonly por padrão.

Esse atributo significa que o destino não pode estar contido em binários lançados para produção.

Como o testonly é aplicado no tempo de compilação, não no ambiente de execução, e se propaga viralmente pela árvore de dependências, ele precisa ser aplicado de forma criteriosa. Por exemplo, stubs e fakes que são úteis para testes de unidade também podem ser úteis para testes de integração envolvendo os mesmos binários que serão lançados para produção e, portanto, provavelmente não podem ser marcados como somente teste. Por outro lado, as regras que são perigosas até mesmo para vincular, talvez por modificarem incondicionalmente o comportamento normal, precisam ser marcadas como somente teste.

toolchains

Lista de rótulos, não configurável. O padrão é []

O conjunto de destinos cujas Criar variáveis este destino tem permissão para acessar. Esses destinos são instâncias de regras que fornecem TemplateVariableInfo ou destinos especiais para tipos de conjunto de ferramentas integrados ao Bazel. São elas:

  • @bazel_tools//tools/cpp:current_cc_toolchain
  • @bazel_tools//tools/jdk:current_java_runtime

Observe que isso é diferente do conceito de resolução do conjunto de ferramentas, usado pelas implementações de regras para configuração dependente da plataforma. Não é possível usar esse atributo para determinar qual cc_toolchain ou java_toolchain específico um destino vai usar.

visibility

Lista de rótulos; não configurável. O padrão é default_visibility do pacote, se especificado, ou "//visibility:private" caso contrário

O atributo visibility em um destino controla se o destino pode ser usado em outros pacotes. Consulte a documentação sobre visibilidade.

Atributos comuns a todas as regras de teste (*_test)

Esta seção descreve os atributos comuns a todas as regras de teste.

Atributo Descrição
args

Lista de strings, sujeita à substituição $(location) e "Make variables" e à tokenização do shell Bourne. O padrão é []

Argumentos de linha de comando que o Bazel transmite para o destino quando executado com bazel test.

Esses argumentos são passados antes de qualquer valor --test_arg especificado na linha de comando bazel test.

env

Dicionário de strings. Os valores estão sujeitos à substituição $(location) e "Make variables". O padrão é {}

Especifica outras variáveis de ambiente a serem definidas quando o teste é executado por bazel test.

Esse atributo só se aplica a regras nativas, como cc_test, py_test e sh_test. Isso não se aplica a regras de teste definidas pelo Starlark. Para suas próprias regras do Starlark, adicione um atributo "env" e use-o para preencher um provedor TestEnvironment.

env_inherit

Lista de strings. O padrão é [].

Especifica outras variáveis de ambiente a serem herdadas do ambiente externo quando o teste é executado por bazel test.

Esse atributo só se aplica a regras nativas, como cc_test, py_test e sh_test. Isso não se aplica às regras de teste definidas pelo Starlark.

size

String "enormous", "large", "medium" ou "small"; não configurável. O padrão é "medium"

Especifica o "peso" de um destino de teste: quanto tempo/recursos é necessário para executar.

Os testes de unidade são considerados "pequenos", os de integração são "médios" e os testes de ponta a ponta são considerados "grandes" ou "enormes". O Bazel usa o tamanho para determinar um tempo limite padrão, que pode ser substituído usando o atributo timeout. O tempo limite é para todos os testes no destino BUILD, não para cada teste individual. Quando o teste é executado localmente, o size também é usado para fins de programação: o Bazel tenta respeitar --local_{ram,cpu}_resources e não sobrecarregar a máquina local executando muitos testes pesados ao mesmo tempo.

Os tamanhos dos testes correspondem aos seguintes tempos limite padrão e presumimos o uso máximo de recursos locais:

Tamanho RAM (em MB) CPU (em núcleos da CPU) Tempo limite padrão
pequeno 20 1 curto (1 minuto)
medium 100 1 moderado (5 minutos)
grande 300 1 longo (15 minutos)
enorme 800 1 Eterno (60 minutos)

A variável de ambiente TEST_SIZE será definida como o valor desse atributo ao gerar o teste.

timeout

String "short", "moderate", "long" ou "eternal"; não configurável. O padrão é derivado do atributo size do teste

O tempo que se espera que o teste seja executado antes de retornar.

Embora o atributo de tamanho de um teste controle a estimativa de recursos, o tempo limite de um teste pode ser definido de forma independente. Se não for especificado explicitamente, o tempo limite será baseado no tamanho do teste. O tempo limite do teste pode ser substituído pela sinalização --test_timeout, por exemplo, para execução em determinadas condições conhecidas por ser lentas. Os valores de tempo limite do teste correspondem aos seguintes períodos:

Valor de tempo limite Período
short 1 minuto
moderado 5 minutos
long 15 minutos
eterno 60 minutos

Para momentos diferentes dos acima, o tempo limite do teste pode ser substituído pela flag bazel --test_timeout, por exemplo, para execução manual em condições conhecidas por ser lentas. Os valores --test_timeout são em segundos. Por exemplo, --test_timeout=120 definirá o tempo limite do teste como dois minutos.

A variável de ambiente TEST_TIMEOUT será definida como o tempo limite do teste (em segundos) ao gerar o teste.

flaky

Booleano, não configurável. O padrão é False.

Marca o teste como instável.

Se definido, executa o teste até três vezes, marcando-o como falha apenas em caso de falha todas as vezes. Por padrão, esse atributo é definido como falso e o teste é executado apenas uma vez. O uso desse atributo geralmente não é recomendado. Os testes precisam ser aprovados de forma confiável quando as declarações deles são mantidas.

shard_count

Número inteiro não negativo menor ou igual a 50. O padrão é -1

Especifica o número de fragmentos paralelos a serem usados para executar o teste.

Se definido, esse valor substituirá qualquer heurística usada para determinar o número de fragmentos paralelos com que o teste será executado. Esse parâmetro pode ser necessário para ativar a fragmentação em algumas regras de teste. Consulte também --test_sharding_strategy.

Se a fragmentação de testes estiver ativada, a variável de ambiente TEST_TOTAL_SHARDS será definida com esse valor ao gerar o teste.

A fragmentação exige que o executor de testes ofereça suporte ao protocolo de fragmentação de testes. Caso contrário, ele provavelmente vai executar todos os testes em cada fragmento, o que não é o que você quer.

Consulte Testar fragmentação na enciclopédia de testes para ver mais detalhes sobre a fragmentação.

local

Booleano, não configurável. O padrão é False.

Força o teste a ser executado localmente, sem sandbox.

Definir essa opção como "True" (verdadeira) equivale a fornecer "local" como uma tag (tags=["local"]).

Atributos comuns a todas as regras binárias (*_binary)

Esta seção descreve os atributos comuns a todas as regras binárias.

Atributo Descrição
args

Lista de strings, sujeita à substituição $(location) e "Criar variável" e tokenização do shell Bourne, não configurável. O padrão é []

Argumentos de linha de comando que o Bazel transmitirá para o destino quando ele for executado pelo comando run ou como um teste. Esses argumentos são transmitidos antes dos especificados na linha de comando bazel run ou bazel test.

OBSERVAÇÃO: os argumentos não são transmitidos quando você executa o destino fora do Bazel (por exemplo, executando o binário manualmente em bazel-bin/).

env

Dicionário de strings. Os valores estão sujeitos à substituição $(location) e "Make variables". O padrão é {}

Especifica outras variáveis de ambiente a serem definidas quando o destino é executado por bazel run.

Esse atributo só se aplica a regras nativas, como cc_binary, py_binary e sh_binary. Isso não se aplica a regras de executáveis definidas pelo Starlark.

OBSERVAÇÃO: as variáveis de ambiente não são definidas quando você executa o destino fora do Bazel (por exemplo, executando manualmente o binário em bazel-bin/).

output_licenses

Lista de strings. O padrão é [].

As licenças dos arquivos de saída gerados por este binário. Ela faz parte de uma API de licenciamento descontinuada que o Bazel não usa mais. Não use isso.

Atributos configuráveis

A maioria dos atributos é "configurável", o que significa que os valores podem mudar quando o destino é criado de maneiras diferentes. Especificamente, os atributos configuráveis podem variar com base nas sinalizações passadas para a linha de comando do Bazel ou na dependência downstream que está solicitando o destino. Isso pode ser usado, por exemplo, para personalizar o destino de várias plataformas ou modos de compilação.

O exemplo a seguir declara origens diferentes para arquiteturas de destino diferentes. A execução de bazel build :multiplatform_lib --cpu x86 criará o destino usando x86_impl.cc, enquanto a substituição de --cpu arm fará com que ele use arm_impl.cc.

cc_library(
    name = "multiplatform_lib",
    srcs = select({
        ":x86_mode": ["x86_impl.cc"],
        ":arm_mode": ["arm_impl.cc"]
    })
)
config_setting(
    name = "x86_mode",
    values = { "cpu": "x86" }
)
config_setting(
    name = "arm_mode",
    values = { "cpu": "arm" }
)

A função select() escolhe entre diferentes valores alternativos para um atributo configurável com base nos critérios config_setting ou constraint_value que a configuração de destino atende.

O Bazel avalia os atributos configuráveis após o processamento de macros e antes das regras de processamento (tecnicamente, entre as fases de carregamento e análise). Qualquer processamento antes da avaliação de select() não sabe qual ramificação o select() escolhe. As macros, por exemplo, não podem mudar o comportamento delas com base na ramificação escolhida, e bazel query só pode fazer suposições conservadoras sobre as dependências configuráveis de um destino. Consulte estas perguntas frequentes para saber mais sobre o uso de select() com regras e macros.

Os atributos marcados como nonconfigurable na documentação não podem usar esse recurso. Normalmente, um atributo não é configurável porque o Bazel precisa saber o valor dele internamente antes de determinar como resolver um select().

Consulte Atributos de build configuráveis para conferir uma visão geral detalhada.

Destinos de saída implícitos

As saídas implícitas em C++ foram descontinuadas. Evite usá-lo em outros idiomas sempre que possível. Ainda não temos um caminho de descontinuação, mas eles também vão ser descontinuados.

Ao definir uma regra de build em um arquivo BUILD, você declara explicitamente um novo destino de regra nomeado em um pacote. Muitas funções de regra de compilação também envolvem implicitamente um ou mais destinos de arquivo de saída, cujo conteúdo e significado são específicos da regra. Por exemplo, ao declarar explicitamente uma regra java_binary(name='foo', ...), você também declara implicitamente o destino foo_deploy.jar de um arquivo de saída como membro do mesmo pacote. Esse destino específico é um arquivo Java independente adequado para implantação.

Destinos de saída implícitos são membros de primeira classe do gráfico de destino global. Assim como outros destinos, eles são criados sob demanda, quando especificados no comando de build de nível superior ou quando são pré-requisitos necessários para outros destinos de build. Elas podem ser referenciadas como dependências nos arquivos BUILD e podem ser observadas na saída de ferramentas de análise, como bazel query.

Para cada tipo de regra de build, a documentação da regra contém uma seção especial que detalha os nomes e o conteúdo de todas as saídas implícitas envolvidas por uma declaração desse tipo de regra.

Uma distinção importante, mas um pouco sutil, entre os dois namespaces usados pelo sistema de build: os rótulos identificam destinos, que podem ser regras ou arquivos, e os destinos de arquivos podem ser divididos em destinos de arquivos de origem (ou entrada) e destinos de arquivos derivados (ou de saída). Esses são os itens que você pode mencionar em arquivos BUILD, criar a partir da linha de comando ou examinar usando bazel query. Esse é o namespace de destino. Cada destino de arquivo corresponde a um arquivo real no disco (o "namespace do sistema de arquivos"). Cada destino de regra pode corresponder a zero, um ou mais arquivos reais no disco. Pode haver arquivos no disco sem destino correspondente. Por exemplo, arquivos de objetos .o produzidos durante a compilação em C++ não podem ser referenciados dentro dos arquivos BUILD ou da linha de comando. Dessa forma, a ferramenta de build pode ocultar determinados detalhes de implementação de como ela faz o trabalho. Isso é explicado com mais detalhes na Referência do conceito BUILD.