O Bazel cria o software com base no código-fonte organizado em uma árvore de diretórios chamada
um espaço de trabalho. Os arquivos de origem no espaço de trabalho são organizados em um
hierarquia de pacotes, em que cada pacote é um diretório que contém um conjunto
de arquivos de origem relacionados e um arquivo BUILD. O arquivo BUILD especifica quais
é possível criar saídas de software
com base na origem.
Espaço de trabalho
Um espaço de trabalho é uma árvore de diretórios no seu sistema de arquivos que contém a origem
do software que você quer criar. Cada espaço de trabalho tem um arquivo de texto chamado
WORKSPACE, que pode estar vazio ou conter referências a
As dependências externas são necessárias para criar as saídas.
Os diretórios contendo um arquivo chamado WORKSPACE são considerados a raiz de um
espaço de trabalho. Portanto, o Bazel ignora todas as árvores de diretórios em um espaço de trabalho com acesso root.
em um subdiretório contendo um arquivo WORKSPACE, porque eles formam outro espaço de trabalho.
Ele também oferece suporte ao arquivo WORKSPACE.bazel como um alias do arquivo WORKSPACE.
Se os dois arquivos existirem, WORKSPACE.bazel será usado.
Repositórios
O código é organizado em repositórios. O diretório que contém o WORKSPACE
é a raiz do repositório principal, também chamado de @. Outro, (externo)
os repositórios são definidos no arquivo WORKSPACE usando regras de espaço de trabalho.
As regras do espaço de trabalho incluídas no Bazel estão documentadas na na seção Regras do espaço de trabalho Build Enciclopédia e a documentação sobre regras incorporadas do repositório Starlark.
Como os repositórios externos também são repositórios, eles geralmente contêm uma
WORKSPACE também. No entanto, esses arquivos WORKSPACE adicionais são
ignoradas pelo Bazel. Em particular, os repositórios que dependem transitivamente são
não são adicionados automaticamente.
Pacotes
A unidade principal de organização do código em um repositório é o pacote (link em inglês). Um é uma coleção de arquivos relacionados e uma especificação de como eles pode ser usado para produzir artefatos de saída.
Um pacote é definido como um diretório que contém um arquivo chamado BUILD
(ou BUILD.bazel). Um pacote inclui todos os arquivos em seu diretório, além de
todos os subdiretórios abaixo dela, exceto os que contêm um
BUILD. A partir dessa definição, nenhum arquivo ou diretório pode fazer parte
dois pacotes diferentes.
Por exemplo, na seguinte árvore de diretórios
Há dois pacotes, my/app, e o subpacote my/app/tests.
Observe que my/app/data não é um pacote, mas um diretório.
que pertencem ao pacote my/app.
src/my/app/BUILD
src/my/app/app.cc
src/my/app/data/input.txt
src/my/app/tests/BUILD
src/my/app/tests/test.cc
Destinos
Um pacote é um contêiner de destinos, que são definidos no
arquivo BUILD. A maioria das segmentações é de dois tipos principais: arquivos e regras.
Os arquivos são divididos em dois tipos. Os arquivos de origem geralmente são escrita pelos esforços de pessoas e check-in no repositório. Arquivos gerados, às vezes chamados de arquivos derivados ou de saída, não são check-in, mas são gerados a partir de arquivos de origem.
O segundo tipo de meta é declarado com uma regra. Cada regra instância especifica a relação entre um conjunto de entrada e um conjunto de arquivos de saída. As entradas de uma regra podem ser arquivos de origem, mas podem ser as saídas de outras regras.
Se a entrada de uma regra é um arquivo de origem ou um arquivo gerado na maioria dos casos, irrelevante; o que importa é apenas o conteúdo . Isso facilita a substituição de um arquivo fonte complexo por um arquivo gerado produzido por uma regra, como acontece quando a carga manter manualmente um arquivo altamente estruturado se torna cansativo, e alguém escreve um programa para derivá-lo. Nenhuma alteração é necessários aos consumidores desse arquivo. Por outro lado, um servidor pode ser facilmente substituído por um arquivo de origem apenas com arquivos mudanças.
As entradas de uma regra também podem incluir outras regras. A significado exato dessas relações é muitas vezes complexo e dependente de linguagem ou regra, mas intuitivamente é simples: uma linguagem C++ a regra de biblioteca A pode ter outra regra de biblioteca C++ B para uma entrada. O efeito dessa dependência é que os arquivos de cabeçalho de B são disponíveis para A durante a compilação, os símbolos de B estão disponíveis para A durante a vinculação, e os dados do ambiente de execução de B estão disponíveis para A durante execução.
Uma invariante de todas as regras é que os arquivos gerados por uma regra sempre pertencer ao mesmo pacote que a própria regra; não é possível gerar arquivos em outro pacote. Não é incomum que as entradas de uma regra venham de outro pacote.
Grupos de pacotes são conjuntos de pacotes cujo objetivo é limitar a acessibilidade
de certas regras. Os grupos de pacotes são definidos pela função package_group.
Eles têm três propriedades: a lista de pacotes que contêm, seu nome e
e outros grupos de pacotes que incluirem. A única maneira permitida de se referir a eles é
no atributo visibility das regras ou no default_visibility
da função package. mas não geram nem consomem arquivos.
Para mais informações, consulte a
Documentação do package_group.