Índice
pacote
package(default_deprecation, default_package_metadata, default_testonly, default_visibility, features)
Essa função declara metadados que se aplicam a todas as regras da . Ele é usado no máximo uma vez em um pacote (arquivo BUILD).
Para a contraparte que declara os metadados aplicáveis a todas as regras no todo
repositório, use a função repo()
na
arquivo REPO.bazel
na raiz do seu repositório.
A função repo()
usa exatamente os mesmos argumentos que package()
.
A função package() deve ser chamada logo após todas as instruções load() no topo da antes de qualquer regra.
Argumentos
Atributo | Descrição |
---|---|
default_applicable_licenses |
Alias para |
default_visibility |
Lista de rótulos o padrão é A visibilidade padrão das regras neste pacote. Todas as regras neste pacote têm a visibilidade especificada
atributo, a menos que especificado de outra forma no |
default_deprecation |
String; o padrão é Define o padrão
|
default_package_metadata |
Lista de rótulos o padrão é Define uma lista padrão de destinos de metadados que se aplicam a todos os outros destinos no pacote. Normalmente, são destinos relacionados ao pacote OSS e declarações de licença. Consulte exemplos em rules_license. |
default_testonly |
Booleano; o padrão é Define o padrão
a propriedade Em pacotes em |
features |
Listar strings; o padrão é Define várias sinalizações que afetam a semântica deste arquivo BUILD. Esse recurso é usado principalmente pelas pessoas que trabalham no sistema de build para incluir tags em pacotes que precisam de algum tipo de tratamento especial. Não use isso, a menos que explicitamente solicitado por alguém que trabalha no sistema de build. |
Exemplos
A declaração abaixo declara que as regras do pacote são visível apenas para os membros do pacote grupo//foo:target
. Declarações de visibilidade individual
em uma regra, se presente, substitui esta especificação.
package(default_visibility = ["//foo:target"])
package_group
package_group(name, packages, includes)
Essa função define um conjunto de pacotes
e associa um rótulo ao conjunto. O rótulo pode ser referenciado
visibility
.
Os grupos de pacotes são usados principalmente para controle de visibilidade. Um ícone visível publicamente o destino pode ser referenciado de cada pacote na árvore de origem. Uma política de privacidade o destino visível só pode ser referenciado dentro do próprio pacote, e não em subpacotes. Entre esses extremos, um alvo pode permitir o acesso ao próprio pacote mais qualquer dos pacotes descritos por um ou mais grupos. Para uma visão mais detalhada sobre o sistema de visibilidade, consulte a visibilidade .
Um determinado pacote é considerado no grupo se corresponder ao
packages
ou já estiver contido em um dos outros
aos grupos de pacotes mencionados no atributo includes
.
Tecnicamente, os grupos de pacotes são alvos, mas não são criados por regras, e não têm nenhuma proteção de visibilidade.
Argumentos
Atributo | Descrição |
---|---|
name |
Nome; obrigatório Um nome exclusivo para o destino. |
packages |
Lista de strings o padrão é Uma lista de zero ou mais especificações de pacote. Cada string de especificação do pacote pode ter uma das seguintes opções formas:
Além disso, os dois primeiros tipos de especificações de pacote também podem
podem ser prefixados com O grupo de pacotes contém qualquer pacote que corresponda a pelo menos um
suas especificações positivas e nenhuma de suas especificações negativas
Por exemplo, o valor Além da visibilidade pública, não há como especificar diretamente pacotes fora do repositório atual. Se esse atributo estiver ausente, será o mesmo que defini-lo como um
lista vazia, o que também é o mesmo de defini-la como uma lista que contém
somente Observação:antes do Bazel 6.0, a especificação Observação:antes do Bazel 6.0, quando esse atributo é serializado como
parte de |
includes |
Lista de rótulos o padrão é Outros grupos de pacotes incluídos neste. Os rótulos neste atributo precisam se referir a outros grupos de pacotes.
Os pacotes nos grupos mencionados são levados
grupo de pacotes. Isso é transitivo: se o grupo de pacotes
Quando usado com especificações de pacote negadas, observe que o de pacotes para cada grupo é calculado de forma independente, e o e os resultados são reunidos. Isso significa que especificações em um grupo não têm efeito sobre as especificações em outro grupo. |
Exemplos
A declaração package_group
a seguir especifica um
grupo de pacotes chamado "tropical" que contém frutas tropicais.
package_group( name = "tropical", packages = [ "//fruits/mango", "//fruits/orange", "//fruits/papaya/...", ], )
As declarações a seguir especificam os grupos de pacotes de um aplicativo:
package_group( name = "fooapp", includes = [ ":controller", ":model", ":view", ], ) package_group( name = "model", packages = ["//fooapp/database"], ) package_group( name = "view", packages = [ "//fooapp/swingui", "//fooapp/webui", ], ) package_group( name = "controller", packages = ["//fooapp/algorithm"], )
exports_files
exports_files([label, ...], visibility, licenses)
exports_files()
especifica uma lista de arquivos que pertencem a
desse pacote que são exportados para outros pacotes.
O arquivo BUILD de um pacote só pode se referir diretamente a arquivos de origem que pertençam
para outro pacote se forem exportados explicitamente com
Instrução exports_files()
. Leia mais sobre
visibilidade dos arquivos.
Por ser um comportamento legado, também são exportados os arquivos mencionados como entrada para uma regra
com a visibilidade padrão até que a sinalização
--incompatible_no_implicit_file_export
é invertido. No entanto, esse comportamento não deve ser confiável
que migraram para o Google.
Argumentos
O argumento é uma lista de nomes de arquivos dentro do pacote atual. Um
declaração de visibilidade também pode ser especificada. Neste caso, os arquivos serão
visível para os destinos especificados. Se nenhuma visibilidade for especificada, os arquivos
será visível para todos os pacotes, mesmo se a visibilidade padrão do pacote for
especificado em package
função. As licenças
também podem ser especificadas.
Exemplo
O exemplo a seguir exporta golden.txt
, um
de texto do pacote test_data
, para que outros
podem usá-lo, por exemplo, no atributo data
de testes.
# from //test_data/BUILD exports_files(["golden.txt"])
massa
glob(include, exclude=[], exclude_directories=1, allow_empty=True)
Glob é uma função auxiliar que encontra todos os arquivos que correspondem a determinados padrões de caminho, e retorna uma nova lista mutável e classificada dos caminhos. O Glob só pesquisa arquivos em seu próprio pacote e procura apenas por arquivos de origem (não arquivos gerados nem outros destinos).
O rótulo de um arquivo de origem será incluído no resultado se a propriedade
caminho corresponde a qualquer um dos include
padrões e a nenhuma
exclude
.
As listas include
e exclude
contêm padrões de caminho
que são relativos ao pacote atual. Cada padrão pode consistir em um ou
mais segmentos de caminho. Como de costume com caminhos Unix, esses segmentos são separados por
/
: Os segmentos do padrão são combinados com os segmentos de
o caminho. Os segmentos podem conter o caractere curinga *
: corresponde a
qualquer substring no segmento do caminho (mesmo a substring vazia), excluindo a
separador de diretório /
. Esse caractere curinga pode ser usado várias vezes
em um segmento de caminho. Além disso, o caractere curinga **
pode corresponder
zero ou mais segmentos de caminho completos, mas devem ser declarados como um segmento
segmento de caminho.
foo/bar.txt
corresponde exatamente ao arquivofoo/bar.txt
neste pacote (a menos quefoo/
seja um subpacote)foo/*.txt
corresponde a todos os arquivos no diretóriofoo/
. se o arquivo terminar com.txt
(a menos quefoo/
seja um subpacote)foo/a*.htm*
corresponde a todos os arquivos emfoo/
. diretório que começa coma
e tem uma string arbitrária (pode vazio), depois tem.htm
e termina com outra string arbitrária (a menos quefoo/
seja um subpacote); comofoo/axx.htm
efoo/a.html
oufoo/axxx.html
foo/*
corresponde a todos os arquivos no diretóriofoo/
; (a menos quefoo/
seja um subpacote); não corresponde afoo
mesmo seexclude_directories
estiver definido como 0foo/**
corresponde a todos os arquivos em cada subdiretório que não seja um subpacote. no subdiretório de primeiro nível do pacotefoo/
; seexclude_directories
é definido como 0,foo
diretório em si também corresponde ao padrão. Nesse caso,**
é considerados correspondentes a nenhum segmento de caminho**/a.txt
corresponde a arquivosa.txt
no mais os subdiretórios que não são subdiretórios.**/bar/**/*.txt
corresponde a cada arquivo.txt
em cada não subpacote desse pacote, se pelo menos um diretório no o caminho resultante é chamadobar
, comoxxx/bar/yyy/zzz/a.txt
oubar/a.txt
(lembre que**
também corresponde a nenhum segmento) oubar/zzz/a.txt
**
corresponde a todos os arquivos em cada subdiretório que não seja um subpacote do este pacotefoo**/a.txt
é um padrão inválido, porque**
deve se destacar sozinho como um segmentofoo/
é um padrão inválido, porque o segundo segmento definido Depois de/
é uma string vazia
Se o argumento exclude_directories
estiver ativado (definido como 1), os arquivos de
tipo será omitido dos resultados (padrão 1).
Se o argumento allow_empty
estiver definido como False
, o
A função glob
causará um erro se o resultado for o
lista vazia.
Há várias limitações e ressalvas importantes:
-
Como
glob()
é executado durante a avaliação do arquivo BUILD,glob()
corresponde somente a arquivos da sua árvore de origem, nunca arquivos gerados pelo servidor. Se você está criando um destino que exige origem e arquivos gerados, você deve anexar uma lista explícita de arquivos no glob. Veja o exemplo abaixo com:mylib
e:gen_java_srcs
. -
Se uma regra tiver o mesmo nome de um arquivo de origem correspondente, “sombra” o arquivo.
Para entender isso, lembre-se de que
glob()
retorna uma lista de caminhos. Portanto, usarglob()
nas outras regras (por exemplo,srcs = glob(["*.cc"])
) tem o mesmo efeito que listar os caminhos correspondentes de forma explícita. Se, por exemplo,glob()
produzir["Foo.java", "bar/Baz.java"]
, mas também existe uma regra na pacote chamado "Foo.java" (o que é permitido, mas o Bazel avisa sobre isso), o consumidor doglob()
vai usar a classe "Foo.java" regra (suas saídas) em vez do arquivo "Foo.java" . Consulte GitHub no problema 10395 para saber mais detalhes. - Os Globs podem corresponder a arquivos em subdiretórios. E nomes de subdiretórios podem ser curingas. No entanto...
-
Os rótulos não podem cruzar os limites do pacote, e o glob não correspondem a arquivos em subpacotes.
Por exemplo, a expressão glob
**/*.cc
no pacotex
não vai incluirx/y/z.cc
sex/y
existe como um pacote (comox/y/BUILD
ou em outro lugar no package-path). Isso significa que o resultado da expressão glob realmente depende da de arquivos BUILD, ou seja, a mesma expressão glob incluirx/y/z.cc
se não houver um pacote chamadox/y
ou ela foi marcada como excluída usando o --deleted_packages . - A restrição acima se aplica a todas as expressões glob, sejam quais forem os caracteres curinga.
-
A correspondência total de um arquivo oculto com nome começando com
.
é: os caracteres curinga**
e*
. Se você quiser fazer a correspondência com um arquivo oculto com um padrão composto, ele precisa começar com uma.
. Por exemplo:*
e.*.txt
vão corresponder a.foo.txt
, mas*.txt
não. A correspondência dos diretórios ocultos é feita da mesma maneira. Diretórios ocultos pode incluir arquivos que não são necessários como entradas e pode aumentar o número de arquivos carregados desnecessariamente e o consumo de memória. Para excluir os diretórios ocultos, adicione-os ao diretório "excluir" argumento list. -
O "**" o caractere curinga tem uma primeira letra maiúscula: o padrão
"**"
não corresponde ao caminho do diretório do pacote. Ou seja, Por exemplo,glob(["**"], exclude_directories = 0)
corresponde a todos os arquivos e diretórios de maneira transitiva estritamente sob o diretório do pacote atual (mas sem entrar em diretórios de subpacotes. Consulte os sobre isso).
Em geral, você deve tentar fornecer uma extensão adequada (por exemplo, *.html) em vez de usar um "*" simples para um padrão glob. O nome mais explícito é autodocumentado e garante que você não corresponda acidentalmente ao backup ou arquivos emacs/vi/... salvos automaticamente.
Ao escrever regras de compilação, é possível enumerar os elementos do glob. Isso permite gerar regras individuais para cada entrada, por exemplo. Consulte a seção exemplo de glob expandido abaixo.
Exemplos da Glob
Criar uma biblioteca Java compilada com base em todos os arquivos java deste diretório
e todos os arquivos gerados pela regra :gen_java_srcs
.
java_library( name = "mylib", srcs = glob(["*.java"]) + [":gen_java_srcs"], deps = "...", ) genrule( name = "gen_java_srcs", outs = [ "Foo.java", "Bar.java", ], ... )
Incluir todos os arquivos txt no diretório testdata, exceto experimental.txt. Observe que os arquivos em subdiretórios de testdata não serão incluídos. Se Para que esses arquivos sejam incluídos, use um glob recursivo (**).
sh_test( name = "mytest", srcs = ["mytest.sh"], data = glob( ["testdata/*.txt"], exclude = ["testdata/experimental.txt"], ), )
Exemplos de globo recursivo
Faça com que o teste dependa de todos os arquivos txt no diretório testdata e de qualquer dos subdiretórios (e de seus subdiretórios e assim por diante). Os subdiretórios que contêm um arquivo BUILD são ignorados. Consulte as limitações e as ressalvas acima.
sh_test( name = "mytest", srcs = ["mytest.sh"], data = glob(["testdata/**/*.txt"]), )
Criar uma biblioteca compilada a partir de todos os arquivos java deste diretório e todos subdiretórios, exceto aqueles cujo caminho inclui um diretório chamado "testing". Evite esse padrão, se possível, porque ele pode reduzir a a incrementabilidade e, portanto, aumentar os tempos de compilação.
java_library( name = "mylib", srcs = glob( ["**/*.java"], exclude = ["**/testing/**"], ), )
Exemplos de Glob expandido
Crie uma regra geral individual para *_test.cc no diretório atual que conta o número de linhas do arquivo.
# Conveniently, the build language supports list comprehensions. [genrule( name = "count_lines_" + f[:-3], # strip ".cc" srcs = [f], outs = ["%s-linecount.txt" % f[:-3]], cmd = "wc -l $< >$@", ) for f in glob(["*_test.cc"])]
Se o arquivo BUILD acima estiver no pacote //foo e o pacote contiver três
arquivos correspondentes, a_test.cc, b_test.cc e c_test.cc, sendo executado
bazel query '//foo:all'
listará todas as regras que foram geradas:
$ bazel query '//foo:all' | sort //foo:count_lines_a_test //foo:count_lines_b_test //foo:count_lines_c_test
select
select( {conditionA: valuesA, conditionB: valuesB, ...}, no_match_error = "custom message" )
select()
é a função auxiliar que faz com que um atributo de regra
configurável.
Ele pode substituir o lado direito de
quase
qualquer atribuição de atributo, portanto, o valor dele depende das sinalizações de linha de comando do Bazel.
Você pode usar isso, por exemplo, para definir dependências específicas da plataforma ou para
incorporar recursos diferentes dependendo de a regra ter sido criada no nível "desenvolvedor"
x "lançamento" modo
O uso básico é o seguinte:
sh_binary( name = "mytarget", srcs = select({ ":conditionA": ["mytarget_a.sh"], ":conditionB": ["mytarget_b.sh"], "//conditions:default": ["mytarget_default.sh"] }) )
Isso faz com que o atributo srcs
do
um sh_binary
configurável substituindo o rótulo normal
de lista com uma chamada select
que mapeia
das condições de configuração
aos valores correspondentes. Cada condição é um rótulo
referência a
um config_setting
ou
constraint_value
,
que "corresponde" se a configuração do destino corresponder a um conjunto esperado de
valores. O valor de mytarget#srcs
se torna o que
lista de rótulos corresponde à invocação atual.
Observações:
- Exatamente uma condição é selecionada em qualquer invocação.
- Se várias condições corresponderem e uma for especialização das outras, a especialização tem precedência. A condição B é considerada especialização da condição A se B tiver as mesmas flags e restrições valores como A mais algumas flags ou valores de restrição adicionais. Isso também significa que a resolução da especialização não é projetada para criar um pedido como demonstradas no Exemplo 2 abaixo.
- Se houver correspondência de várias condições e uma não for uma especialização de todas outros, o Bazel falha com um erro, a menos que todas as condições sejam resolvidas com o mesmo valor.
- O pseudorótulo especial
//conditions:default
é considerados correspondentes se nenhuma outra condição corresponder. Se essa condição for deixada de fora, alguma outra regra deverá corresponder para evitar um erro. - O
select
pode ser incorporado dentro de uma atribuição de atributo. Portanto,srcs = ["common.sh"] + select({ ":conditionA": ["myrule_a.sh"], ...})
esrcs = select({ ":conditionA": ["a.sh"]}) + select({ ":conditionB": ["b.sh"]})
são expressões válidas. select
funciona com a maioria dos atributos, mas não com todos. Incompatível atributos estão marcados comononconfigurable
na documentação.subpacotes
subpackages(include, exclude=[], allow_empty=True)
subpackages()
é uma função auxiliar, semelhante aglob()
. que lista subpacotes em vez de arquivos e diretórios. Ele usa a mesma caminhos padrão comoglob()
e pode corresponder a qualquer subpacote que seja um descendente direto do arquivo BUILD que está sendo carregado. Consulte glob para uma explicação detalhada e exemplos de inclusão e excluir padrões.A lista resultante de subpacotes retornados está na ordem de classificação e contém caminhos relativos ao pacote de carregamento atual que correspondem aos padrões especificados em
include
e não aqueles emexclude
.Exemplo
O exemplo a seguir lista todos os subpacotes diretos do pacote
foo/BUILD
.# The following BUILD files exist: # foo/BUILD # foo/bar/baz/BUILD # foo/bar/but/bad/BUILD # foo/sub/BUILD # foo/sub/deeper/BUILD # # In foo/BUILD a call to subs1 = subpackages(include = ["**"]) # results in subs1 == ["sub", "bar/baz", "bar/but/bad"] # # 'sub/deeper' is not included because it is a subpackage of 'foo/sub' not of # 'foo' subs2 = subpackages(include = ["bar/*"]) # results in subs2 = ["bar/baz"] # # Since 'bar' is not a subpackage itself, this looks for any subpackages under # all first level subdirectories of 'bar'. subs3 = subpackages(include = ["bar/**"]) # results in subs3 = ["bar/baz", "bar/but/bad"] # # Since bar is not a subpackage itself, this looks for any subpackages which are # (1) under all subdirectories of 'bar' which can be at any level, (2) not a # subpackage of another subpackages. subs4 = subpackages(include = ["sub"]) subs5 = subpackages(include = ["sub/*"]) subs6 = subpackages(include = ["sub/**"]) # results in subs4 and subs6 being ["sub"] # results in subs5 = []. # # In subs4, expression "sub" checks whether 'foo/sub' is a package (i.e. is a # subpackage of 'foo'). # In subs5, "sub/*" looks for subpackages under directory 'foo/sub'. Since # 'foo/sub' is already a subpackage itself, the subdirectories will not be # traversed anymore. # In subs6, 'foo/sub' is a subpackage itself and matches pattern "sub/**", so it # is returned. But the subdirectories of 'foo/sub' will not be traversed # anymore.
Em geral, é preferível que, em vez de chamar esta função diretamente que os usuários usem os "subpacotes" módulo de skylib (ambos em inglês).