O Bazel cria um software a partir do código-fonte organizado em árvores de diretórios chamadas
repositórios. Um conjunto definido de repositórios compreende o espaço de trabalho. Origem
os arquivos nos repositórios são organizados em uma hierarquia aninhada de pacotes, em que
cada pacote é um diretório que contém um conjunto de arquivos de origem relacionados e um
BUILD. O arquivo BUILD especifica a partir de quais saídas de software podem ser criadas
a origem.
Repositórios
Os arquivos de origem usados em uma compilação do Bazel são organizados em repositórios (geralmente
abreviada para repos). Um repositório é uma árvore de diretórios com um arquivo de marcador de limite em
sua raiz; um arquivo de marcador de limite como MODULE.bazel, REPO.bazel ou
em contextos legados, WORKSPACE ou WORKSPACE.bazel.
O repositório em que o comando atual do Bazel está sendo executado é chamado de gcloud. Outros (externos) são definidos pelas regras do repo. consulte informações externas visão geral das dependências para mais informações.
Espaço de trabalho
Um espaço de trabalho é o ambiente compartilhado por todos os comandos do Bazel executados no mesmo repositório principal. Ele abrange o repositório principal e o conjunto de todas as instâncias repositórios.
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".
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 podem ser usados para produzir artefatos de saída.
Um pacote é definido como um diretório que contém
Arquivo BUILD com o nome BUILD ou BUILD.bazel. Um
inclui todos os arquivos em seu diretório e todos os subdiretórios abaixo dele,
exceto aqueles que contêm um arquivo BUILD. Com base nessa definição,
ou diretório pode fazer parte de dois pacotes diferentes.
Por exemplo, na árvore de diretórios a seguir há dois pacotes, my/app,
e o subpacote my/app/tests. Observe que my/app/data não é um pacote, mas
um diretório pertencente 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 gravados por os esforços das pessoas e fez check-in no repositório. Arquivos gerados às vezes chamados arquivos derivados ou arquivos de saída, não são verificados, mas gerados a partir de arquivos de origem.
O segundo tipo de meta é declarado com uma regra. Cada instância de regra especifica a relação entre um conjunto de entrada e um conjunto de arquivos de saída. O entradas de uma regra podem ser arquivos de origem, mas também podem ser saídas regras de firewall.
Se a entrada para uma regra é um arquivo de origem ou um arquivo gerado está na maioria casos irrelevantes; o que importa é apenas o conteúdo desse arquivo. Este fato facilita a substituição de um arquivo fonte complexo por um arquivo gerado produzido pelo uma regra, como acontece quando o ônus de manter manualmente um sistema um arquivo estruturado se torna cansativo, e alguém escreve um programa para derivá-lo. Nenhuma alteração é necessária para os consumidores desse arquivo. Por outro lado, um servidor pode ser facilmente substituído por um arquivo de origem apenas com alterações locais.
As entradas de uma regra também podem incluir outras regras. O significado exato dessas relacionamentos costumam ser bastante complexos e dependem da linguagem ou da regra, mas intuitivamente, é simples: uma regra de biblioteca C++ A pode ter outra biblioteca C++ regra 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 vinculação, e os dados do ambiente de execução de B ficam disponíveis para A durante a execução.
Uma invariante de todas as regras é que os arquivos gerados por uma regra sempre pertencem ao o mesmo pacote da própria regra, não é possível gerar arquivos outro pacote. Não é incomum que as entradas de uma regra venham de outra .
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, o nome e outras
os grupos de pacotes que elas incluem. As únicas maneiras permitidas de se referir a elas são
visibility das regras ou do atributo default_visibility de
a função package; mas não geram nem consomem arquivos. Para mais
mais informações, consulte a package_group
na documentação do Google.