Espaços de trabalho, pacotes e destinos

Informar um problema Mostrar fonte Por noite · 7,3 · 7,2 · 7,1 · 7,0 · 6,5

O Bazel cria um software com base no código-fonte organizado em uma árvore de diretórios chamada espaço de trabalho. Os arquivos de origem no espaço de trabalho são organizados em uma hierarquia aninhada de em que cada pacote é um diretório que contém um conjunto de arquivos de origem e um arquivo BUILD. O arquivo BUILD especifica qual software como as saídas podem ser criadas a partir da fonte.

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 pode conter referências a external dependências 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 um subdiretório que contém 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 ambos os 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 forem definidos no arquivo WORKSPACE usando regras de espaço de trabalho ou geradas a partir de módulos e extensões no sistema Bzlmod. Consulte visão geral das dependências para mais informações.

As regras do espaço de trabalho agrupadas com o Bazel estão documentadas na documentação Regras na seção Build Enciclopédia e a documentação sobre recursos incorporados Regras de repositório do 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 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 podem ser usados 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 subdiretórios abaixo dela, exceto os que contêm um arquivo BUILD. A partir dessa definição, nenhum arquivo ou diretório pode fazer parte de dois pacotes.

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. A 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.

Rótulos