Um rótulo é um identificador de um destino. Um rótulo típico na forma canônica completa é assim:
@@myrepo//my/app/main:app_binary
A primeira parte do rótulo é o nome do repositório, @@myrepo
. O duplo @
sintaxe significa que este é um repositório canônico
nome, que é exclusivo no
espaço de trabalho. Os rótulos com nomes de repositórios canônicos identificam de forma inequívoca um destino,
independente do contexto em que aparecem.
Muitas vezes, o nome do repositório canônico é uma string arcana que se parece com
@@rules_java~7.1.0~toolchains~local_jdk
. O que é muito mais comum é encontrar
rótulos com um nome de repositório aparente,
que se parece com:
@myrepo//my/app/main:app_binary
A única diferença é que o nome do repositório é prefixado com um @
em vez de dois.
Isso se refere a um repositório com o nome aparente myrepo
, que pode ser diferente
com base no contexto em que esse rótulo aparece.
No caso típico de um rótulo se referir ao mesmo repositório do qual
for usado, a parte do nome do repositório pode ser omitida. Portanto, dentro de @@myrepo
, o primeiro
rótulo geralmente é escrito como
//my/app/main:app_binary
A segunda parte do rótulo é o nome do pacote não qualificado
my/app/main
, o caminho para o pacote.
em relação à raiz do repositório. Juntos, o nome do repositório e o
nome do pacote não qualificado formam o nome do pacote totalmente qualificado
@@myrepo//my/app/main
. Quando o rótulo se refere ao mesmo
pacote em que é usado, o nome do pacote (e, opcionalmente, o dois-ponto)
pode ser omitido. Portanto, dentro de @@myrepo//my/app/main
,
esse identificador pode ser escrito de uma das seguintes maneiras:
app_binary
:app_binary
É uma convenção que o dois-pontos é omitido para arquivos, mas mantido para regras, mas não é significativo de outra forma.
A parte do rótulo após os dois-pontos, app_binary
é o destino não qualificado.
nome. Quando ele corresponder ao último componente do caminho do pacote, ele e o
dois pontos, pode ser omitido. Portanto, estes dois rótulos são equivalentes:
//my/app/lib
//my/app/lib:lib
O nome de um destino de arquivo em um subdiretório do pacote é o caminho do arquivo
em relação à raiz do pacote (o diretório que contém o arquivo BUILD
). Então,
esse arquivo está no subdiretório my/app/main/testdata
do repositório:
//my/app/main:testdata/input.txt
Strings como //my/app
e @@some_repo//my/app
têm dois significados, dependendo da
no contexto em que são usados: quando o Bazel espera um rótulo, eles significam
//my/app:app
e @@some_repo//my/app:app
, respectivamente. Mas, quando o Bazel
espera um pacote (por exemplo, em especificações package_group
), ele faz referência ao
que contém o rótulo.
Um erro comum em arquivos BUILD
é usar //my/app
para se referir a um pacote ou
a todos os destinos em um pacote, o que não é possível. Ele é
equivalente a //my/app:app
, então ele nomeia o destino app
no pacote my/app
do repositório atual.
No entanto, o uso de //my/app
para se referir a um pacote é incentivado na
especificação de um package_group
ou em arquivos .bzl
, porque claramente
informa que o nome do pacote é absoluto e tem como enraizado no nível superior
do espaço de trabalho.
Os rótulos relativos não podem ser usados para se referir a destinos em outros pacotes. O
identificador do repositório e o nome do pacote precisam ser sempre especificados nesse caso.
Por exemplo, se a árvore de origem contiver os pacotes my/app
e os
pacote my/app/testdata
(cada um desses dois diretórios tem o próprio
BUILD
), o último pacote contém um arquivo chamado testdepot.zip
. Aqui
há duas maneiras (uma errada, uma correta) de se referir a esse arquivo em
//my/app:BUILD
:
Incorreto: testdata
é um pacote diferente, então não é possível usar um caminho relativo.
testdata/testdepot.zip
Correto: consulte testdata
com o caminho completo
//my/app/testdata:testdepot.zip
Os rótulos que começam com @@//
são referências ao repositório
principal, que ainda funciona mesmo em repositórios externos.
Portanto, @@//a/b/c
é diferente
//a/b/c
quando referenciados em um repositório externo.
O primeiro se refere ao repositório principal, enquanto o segundo se refere
procura //a/b/c
no próprio repositório externo.
Isso é especialmente relevante ao escrever regras na entrada
que se referem a destinos no repositório principal e serão
de repositórios externos.
Para informações sobre as diferentes maneiras de se referir a destinos, consulte padrões de segmentação.
Especificação léxica de um rótulo
A sintaxe de rótulos desencoraja o uso de metacaracteres que têm um significado especial para o shell. Isso ajuda a evitar problemas de citação acidentais e facilita construir ferramentas e scripts que manipulam rótulos, como o Linguagem de consulta do Bazel.
Confira abaixo os detalhes exatos dos nomes de destino permitidos.
Nomes de destino: package-name:target-name
target-name
é o nome do destino no pacote. O nome de uma regra
é o valor do atributo name
na declaração da regra em um arquivo BUILD
.
O nome de um arquivo é o caminho relativo ao diretório que contém
o arquivo BUILD
.
Os nomes de destino precisam ser compostos inteiramente de caracteres retirados do conjunto de a
a z
.
A
–Z
, 0
–9
e os símbolos de pontuação !%-@^_"#$&'()*-+,;<=>?[]{|}~/.
.
Os nomes de arquivo precisam ser caminhos relativos no formato normal, ou seja, eles não podem
começar nem terminar com um caractere de barra (por exemplo, /foo
e foo/
são
proibidos) nem conter vários caracteres de barra consecutivos como separadores de caminho
(por exemplo, foo//bar
). Da mesma forma, referências de nível superior (..
) e
de diretório atual (./
) são proibidas.
Incorreto: não use ".." para se referir a arquivos em outros pacotes.
Correto: uso `//package-name:filename`
Embora seja comum usar /
no nome de um destino de arquivo, evite o uso de
/
nos nomes das regras. Especialmente quando a forma abreviada de um rótulo é
usado, pode confundir o leitor. O rótulo //foo/bar/wiz
é sempre uma abreviação
para //foo/bar/wiz:wiz
, mesmo que não haja esse pacote foo/bar/wiz
;
nunca se refere a //foo:bar/wiz
, mesmo que esse destino exista.
No entanto, há algumas situações em que o uso de um caractere de barra é conveniente ou às vezes até necessário. Por exemplo, o nome de algumas regras precisa corresponder ao arquivo de origem principal, que pode estar em um subdiretório do pacote.
Nomes de pacote: //package-name:target-name
O nome de um pacote é o nome do diretório que contém o arquivo BUILD
.
em relação ao diretório de nível superior do repositório que o contém.
Por exemplo, my/app
.
Os nomes dos pacotes precisam ser compostos inteiramente de caracteres retirados do conjunto
A
-Z
, a
–z
, 0
–9
, "/
", "-
", ".
", "@
" e "_
", e não podem
comece com uma barra.
Para uma linguagem com uma estrutura de diretório significativa para o sistema de módulos (por exemplo, Java), é importante escolher nomes de diretório que sejam identificadores válidos na linguagem.
Embora o Bazel ofereça suporte a destinos no pacote raiz do espaço de trabalho (por exemplo,
//:foo
), é melhor deixar esse pacote vazio para que todos os pacotes significativos
tenham nomes descritivos.
Os nomes dos pacotes não podem conter a substring //
nem terminar com uma barra.
Regras
Uma regra especifica a relação entre entradas e saídas, e a etapas para criar as saídas. As regras podem ser de uma das várias (às vezes chamada de classe de regra), que produzem dados compilados executáveis, bibliotecas, executáveis de teste e outros saídas, conforme descrito na Enciclopédia de builds.
Arquivos BUILD
declaram destinos invocando regras.
No exemplo abaixo, vemos a declaração do destino my_app
.
usando a regra cc_binary
.
cc_binary(
name = "my_app",
srcs = ["my_app.cc"],
deps = [
"//absl/base",
"//absl/strings",
],
)
Toda invocação de regra tem um atributo name
, que precisa ser um atributo válido
target name), que declara um destino dentro do pacote
do arquivo BUILD
.
Cada regra tem um conjunto de atributos. os atributos aplicáveis a um determinado e a importância e a semântica de cada atributo são uma função o tipo da regra. consulte a Build Encyclopedia lista de regras e seus atributos correspondentes. Cada atributo tem um nome e um tipo. Alguns dos tipos comuns que um atributo pode ter são inteiro, rótulo, lista de rótulos, string, lista de strings, rótulo de saída, lista de rótulos de saída. Não todos os atributos precisam ser especificados em cada regra. Os atributos formam um dicionário de chaves (nomes) para valores digitados opcionais.
O atributo srcs
, presente em muitas regras, tem o tipo "lista de rótulos". dela
valor, se presente, é uma lista de rótulos, sendo cada um o nome de um destino que é
uma entrada para essa regra.
Em alguns casos, o nome do tipo da regra é um pouco arbitrário, e mais interessantes são os nomes dos arquivos gerados pela regra, e isso é verdadeiro das regras gerais. Para mais informações, consulte Regras gerais: genrule.
Em outros casos, o nome é significativo: para regras *_binary
e *_test
,
por exemplo, o nome da regra determina o nome do executável produzido pelo
build.
Esse gráfico acíclico dirigido sobre os destinos é chamado de gráfico de destino ou gráfico de dependência de build e é o domínio em que a ferramenta de consulta do Bazel opera.
Metas | Arquivos BUILD |