Esta página descreve como estender a linguagem BUILD usando macros e regras.
As extensões do Bazel são arquivos que terminam em .bzl
. Use uma
instrução de carregamento para importar um símbolo de uma extensão.
Antes de aprender os conceitos mais avançados, faça o seguinte:
Leia sobre a linguagem Starlark, usada nos arquivos
BUILD
e.bzl
.Saiba como compartilhar variáveis entre dois arquivos
BUILD
.
Macros e regras
Uma macro é uma função que instancia regras. Ele é útil quando um
arquivo BUILD
está ficando muito repetitivo ou complexo, porque permite reutilizar
algum código. A função é avaliada assim que o arquivo BUILD
é lido. Após
a avaliação do arquivo BUILD
, o Bazel tem poucas informações sobre macros:
se a macro gerar um genrule
, o Bazel vai se comportar como se você tivesse escrito o
genrule
. Como resultado, bazel query
vai listar apenas o genrule
gerado.
Uma regra é mais poderosa do que uma macro. Ele pode acessar os elementos internos do Bazel e ter controle total sobre o que está acontecendo. Por exemplo, ela pode transmitir informações para outras regras.
Se você quiser reutilizar uma lógica simples, comece com uma macro. Se uma macro se tornar complexa, geralmente é uma boa ideia torná-la uma regra. O suporte a um novo idioma geralmente é feito com uma regra. As regras são para usuários avançados, e a maioria deles nunca precisa escrever uma. Eles só vão carregar e chamar as regras existentes.
Modelo de avaliação
Um build consiste em três fases.
Fase de carregamento. Primeiro, carregue e avalie todas as extensões e todos os arquivos
BUILD
necessários para o build. A execução dos arquivosBUILD
simplesmente instancia regras. Sempre que uma regra é chamada, ela é adicionada a um gráfico. É aqui que as macros são avaliadas.Fase de análise. O código das regras é executado (a função
implementation
delas) e as ações são instanciadas. Uma ação descreve como gerar um conjunto de saídas a partir de um conjunto de entradas, como "run gcc on hello.c and get hello.o". É necessário listar explicitamente quais arquivos serão gerados antes de executar os comandos reais. Em outras palavras, a fase de análise usa o gráfico gerado pela fase de carregamento e gera um gráfico de ação.Fase de execução. As ações são executadas quando pelo menos uma das saídas é necessária. Se um arquivo estiver ausente ou se um comando falhar ao gerar uma saída, o build vai falhar. Os testes também são executados durante essa fase.
O Bazel usa o paralelismo para ler, analisar e avaliar os arquivos .bzl
e BUILD
. Um arquivo é lido no máximo uma vez por build, e o resultado da avaliação é
armazenado em cache e reutilizado. Um arquivo só é avaliado depois que todas as dependências (instruções
load()
) são resolvidas. Por design, o carregamento de um arquivo .bzl
não tem efeitos colaterais
visíveis, apenas define valores e funções.
O Bazel tenta ser inteligente: ele usa a análise de dependência para saber quais arquivos precisam ser carregados, quais regras precisam ser analisadas e quais ações precisam ser executadas. Por exemplo, se uma regra gerar ações que você não precisa para o build atual, elas não serão executadas.
Como criar extensões
Crie sua primeira macro para reutilizar algum código. Depois, saiba mais sobre macros e como usá-las para criar "verbos personalizados".
Siga o tutorial sobre regras para começar a usar esse recurso. Em seguida, leia mais sobre os conceitos de regras.
Os dois links abaixo serão muito úteis ao escrever suas próprias extensões. Mantenha-os ao alcance:
Mais detalhes
Além das macros e regras, você pode escrever aspectos e regras de repositório.
Use o Buildifier de forma consistente para formatar e analisar seu código.
Siga o guia de estilo
.bzl
.Teste seu código.
Gerar documentação para ajudar seus usuários.
Otimize a performance do código.
Implante suas extensões para outras pessoas.