As inscrições para a BazelCon 2024 já estão abertas.

Esta página foi traduzida pela API Cloud Translation.

Arquivos .bzl

Reportar um problema Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Métodos globais disponíveis em todos os arquivos .bzl.

Membros

analysis_test_transition
aspecto
configuration_field
depset
exec_group
exec_transition
module_extension
provedor
repository_rule
regra
Selecione
subrule
tag_class
visibilidade

analysis_test_transition

transition analysis_test_transition(settings)

Cria uma transição de configuração a ser aplicada às dependências de uma regra de teste de análise. Esta transição só pode ser aplicada em atributos de regras com analysis_test = True. Essas regras são restritas em recursos (por exemplo, o tamanho da árvore de dependência é limitado), portanto, as transições criadas com essa função são limitadas no escopo potencial em comparação com as transições criadas usando transition().

Essa função foi projetada principalmente para facilitar a biblioteca principal do framework de teste de análise (em inglês). Consulte a documentação (ou a implementação dela) para conhecer as práticas recomendadas.

Parâmetros

Parâmetro Descrição

settings dict; obrigatório
Um dicionário contendo informações sobre as definições de configuração que devem ser definidas por essa transição de configuração. As chaves são rótulos de configuração de build, e os valores são os novos valores pós-transição. Todas as outras configurações não foram alteradas. Use-o para declarar definições de configuração específicas que um teste de análise requer que seja definido para ser aprovado.

Parâmetro	Descrição
`settings`	dict; obrigatório Um dicionário contendo informações sobre as definições de configuração que devem ser definidas por essa transição de configuração. As chaves são rótulos de configuração de build, e os valores são os novos valores pós-transição. Todas as outras configurações não foram alteradas. Use-o para declarar definições de configuração específicas que um teste de análise requer que seja definido para ser aprovado.

aspecto

Aspect aspect(implementation, attr_aspects=[], toolchains_aspects=[], attrs={}, required_providers=[], required_aspect_providers=[], provides=[], requires=[], fragments=[], host_fragments=[], toolchains=[], incompatible_use_toolchain_transition=False, doc=None, *, apply_to_generating_rules=False, exec_compatible_with=[], exec_groups=None, subrules=[])

Cria um novo aspecto. O resultado dessa função precisa ser armazenado em um valor global. Consulte a introdução aos aspectos para mais detalhes.

Parâmetros

Parâmetro	Descrição
`implementation`	function; obrigatório Uma função do Starlark que implementa esse aspecto, com exatamente dois parâmetros: Target (o destino ao qual o aspecto é aplicado) e ctx (o contexto da regra de onde o destino é criado). Os atributos do destino estão disponíveis no campo `ctx.rule`. Essa função é avaliada durante a fase de análise para cada aplicação de um aspecto a um destino.
`attr_aspects`	Sequência de strings; O padrão é `[]` Lista de nomes de atributos. O aspecto é propagado com as dependências especificadas nos atributos de um destino com esses nomes. Os valores comuns incluem `deps` e `exports`. A lista também pode conter uma única string `"*"` para ser propagada em todas as dependências de um destino.
`toolchains_aspects`	sequência: o padrão é `[]` Lista de tipos de toolchain. O aspecto é propagado para os conjuntos de ferramentas de destino que correspondem a esses tipos.
`attrs`	dict; o padrão é `{}` Um dicionário que declara todos os atributos do aspecto. Ele é mapeado de um nome de atributo para um objeto de atributo, como `attr.label` ou `attr.string` (consulte o módulo `attr`). Os atributos de aspecto estão disponíveis para a função de implementação como campos do parâmetro `ctx`. Atributos implícitos que começam com `_` precisam ter valores padrão e tipo `label` ou `label_list`. Os atributos explícitos precisam ser do tipo `string` e usar a restrição `values`. Atributos explícitos restringem o aspecto para ser usado apenas com regras que tenham atributos do mesmo nome, tipo e valores válidos, de acordo com a restrição. Os atributos declarados vão converter `None` no valor padrão.
`required_providers`	sequence; o padrão é `[]` Esse atributo permite que o aspecto limite sua propagação apenas aos destinos cujas regras anunciam os provedores necessários. O valor precisa ser uma lista que contenha provedores individuais ou listas de provedores, mas não ambos. Por exemplo, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` é um valor válido, mas `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` não. Uma lista de provedores não aninhada é convertida automaticamente em uma lista que contém uma lista de provedores. Ou seja, `[FooInfo, BarInfo]` será automaticamente convertido em `[[FooInfo, BarInfo]]`. Para que algumas regras (por exemplo, `some_rule`) sejam visíveis para um aspecto, `some_rule` precisa anunciar todos os provedores de pelo menos uma das listas de provedores obrigatórias. Por exemplo, se o `required_providers` de um aspecto for `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, ele poderá ver destinos `some_rule` somente se `some_rule` fornecer `FooInfo`, ou `BarInfo` ou `BazInfo` e `QuxInfo`.
`required_aspect_providers`	sequence; o padrão é `[]` Esse atributo permite que esse aspecto inspecione outros aspectos. O valor precisa ser uma lista que contenha provedores individuais ou listas de provedores, mas não ambos. Por exemplo, `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]` é um valor válido, enquanto `[FooInfo, BarInfo, [BazInfo, QuxInfo]]` não é. Uma lista de provedores não aninhados será automaticamente convertida em uma lista com uma lista de provedores. Ou seja, `[FooInfo, BarInfo]` será convertido automaticamente em `[[FooInfo, BarInfo]]`. Para tornar outro aspecto (por exemplo, `other_aspect`) visível para esse aspecto, `other_aspect` precisa fornecer todos os provedores de pelo menos uma das listas. No exemplo de `[[FooInfo], [BarInfo], [BazInfo, QuxInfo]]`, esse aspecto pode ver `other_aspect` se e somente se `other_aspect` fornecer `FooInfo`, ou `BarInfo`, ou `BazInfo` e `QuxInfo`.
`provides`	sequence; o padrão é `[]` Uma lista de provedores que a função de implementação precisa retornar. É um erro se a função de implementação omitir do valor de retorno qualquer um dos tipos de provedores listados aqui. No entanto, a função de implementação pode retornar outros provedores não listados aqui. Cada elemento da lista é um objeto `*Info` retornado por `provider()`, exceto que um provedor legado é representado pelo nome da string. Quando um destino da regra é usado como uma dependência para um destino que declara um provedor obrigatório, não é necessário especificar esse provedor aqui. Basta que a função de implementação o retorne. No entanto, especificar isso é uma prática recomendada, mesmo que isso não seja obrigatório. No entanto, o campo `required_providers` de um aspect exige que provedores sejam especificados aqui.
`requires`	Sequência de aspectos: o padrão é `[]` . Lista de aspectos que precisam ser propagados antes deste.
`fragments`	Sequência de strings. O padrão é `[]` . Lista de nomes de fragmentos de configuração que o aspecto exige na configuração de destino.
`host_fragments`	Sequência de strings. O padrão é `[]` . Lista de nomes de fragmentos de configuração que o aspecto exige na configuração do host.
`toolchains`	sequência: o padrão é `[]` . Se definido, o conjunto de toolchains que esse aspecto exige. A lista pode conter objetos String, Label ou StarlarkToolchainTypeApi, em qualquer combinação. Os conjuntos de ferramentas são encontrados ao verificar a plataforma atual e fornecidos à implementação do aspecto via `ctx.toolchain`.
`incompatible_use_toolchain_transition`	bool; o padrão é `False` Obsoleto, ele não está mais em uso e precisa ser removido.
`doc`	string; ou `None` o padrão é `None` Uma descrição do aspecto que pode ser extraída por ferramentas de geração de documentação.
`apply_to_generating_rules`	bool; o padrão é `False` Se for verdadeiro, o aspecto será aplicado, quando aplicado a um arquivo de saída, à regra de geração desse arquivo. Por exemplo, suponha que um aspecto se propague transitivamente pelo atributo "deps" e seja aplicado ao destino "alpha". Suponha que "alpha" tenha "deps = [':beta_output']", em que "beta_output" é uma saída declarada de um destino "beta". Suponha que "beta" tenha um destino "charlie" como um dos "deps". Se "apply_to_generating_rules=True" para o aspecto, ele vai se propagar por "alpha", "beta" e "charlie". Se for falso, o aspecto vai se propagar apenas para "alpha". Falso por padrão.
`exec_compatible_with`	Sequência de strings. O padrão é `[]` . Uma lista de restrições na plataforma de execução que se aplicam a todas as instâncias desse aspecto.
`exec_groups`	dict ou `None`; o padrão é `None` Dict do nome do grupo de execução (string) para `exec_group`s. Se definido, permite que os aspectos executem ações em várias plataformas de execução dentro de uma única instância. Consulte a documentação sobre grupos de execução para mais informações.
`subrules`	sequência de Sub-regrass; o padrão é `[]` Experimental: lista de sub-regras usadas por este aspecto.

configuration_field

LateBoundDefault configuration_field(fragment, name)

Faz referência a um valor padrão com limite tardio para um atributo do tipo rótulo. Um valor tem data de término se ela exigir que a configuração seja criada antes de determinar o valor. Qualquer atributo que use isso como um valor precisa ser privado.

Exemplo de uso:

Como definir um atributo de regra:

'_foo': attr.label(default=configuration_field(fragment='java', name='toolchain'))

Acesso na implementação de regras:

  def _rule_impl(ctx):
    foo_info = ctx.attr._foo
    ...

Parâmetros

Parâmetro	Descrição
`fragment`	string; obrigatório O nome de um fragmento de configuração que contém o valor vinculado tardiamente.
`name`	string; obrigatório O nome do valor a ser extraído do fragmento de configuração.

Depset

depset depset(direct=None, order="default", *, transitive=None)

Cria um depset. O parâmetro direct é uma lista de elementos diretos do depset, e o parâmetro transitive é uma lista de depsets cujos elementos se tornam elementos indiretos do depset criado. A ordem em que os elementos são retornados quando o dispositivo é convertido em uma lista é especificada pelo parâmetro order. Consulte a Visão geral dos conjuntos de dependências para mais informações.

Todos os elementos (diretos e indiretos) de um dispositivo precisam ser do mesmo tipo, conforme obtido pela expressão type(x).

Como um conjunto baseado em hash é usado para eliminar duplicatas durante a iteração, todos os elementos de um depset precisam ser hasháveis. No entanto, esse invariante não é verificado de forma consistente em todos os construtores. Usar a sinalização --insupported_always_check_depset_elements para ativar a verificação consistente; esse será o comportamento padrão em versões futuras. consulte o problema 10313 (link em inglês).

Além disso, os elementos precisam ser imutáveis atualmente, embora essa restrição seja flexibilizada no futuro.

A ordem da desativação criada precisa ser compatível com a ordem das dependências de transitive. O pedido de "default" é compatível com qualquer outro pedido. Todos os outros pedidos são compatíveis somente com ele mesmo.

Parâmetros

Parâmetro	Descrição
`direct`	sequência ou `None`; o padrão é `None` Uma lista de elementos diretos de um depset.
`order`	string; O padrão é `"default"` A estratégia de travessia para o novo depset. Veja os valores possíveis aqui.
`transitive`	sequência de depsets; ou `None`; o padrão é `None` Uma lista de dispositivos com elementos que se tornarão elementos indiretos deles.

exec_group

exec_group exec_group(toolchains=[], exec_compatible_with=[])

Cria um grupo de execução que pode ser usado para criar ações para uma plataforma de execução específica durante a implementação da regra.

Parâmetros

Parâmetro	Descrição
`toolchains`	sequência; o padrão é `[]` O conjunto de toolchains necessário para esse grupo de execução. A lista pode conter objetos String, Label ou StarlarkToolchainTypeApi, em qualquer combinação.
`exec_compatible_with`	Sequência de strings; o padrão é `[]` Uma lista de restrições na plataforma de execução.

exec_transition

transition exec_transition(implementation, inputs, outputs)

Uma versão especializada de transition() usada para definir a transição de execução. Consulte a documentação (ou a implementação dela) para conhecer as práticas recomendadas. Só pode ser usado dos builtins do Bazel.

Parâmetros

Parâmetro	Descrição
`implementation`	callable; required
`inputs`	sequência de strings obrigatório
`outputs`	sequência de strings obrigatório

module_extension

unknown module_extension(implementation, *, tag_classes={}, doc=None, environ=[], os_dependent=False, arch_dependent=False)

Cria uma nova extensão de módulo. Armazene-o em um valor global para que possa ser exportado e usado em um arquivo MODULE.bazel com use_extension.

Parâmetros

Parâmetro	Descrição
`implementation`	callable; required A função que implementa essa extensão de módulo. É preciso usar um único parâmetro, `module_ctx`. A função é chamada uma vez no início de uma compilação para determinar o conjunto de repositórios disponíveis.
`tag_classes`	dict; o padrão é `{}` Um dicionário para declarar todas as classes de tag usadas pela extensão. Ele mapeia o nome da classe de tag para um objeto `tag_class`.
`doc`	string; ou `None` o padrão é `None` Uma descrição da extensão do módulo que pode ser extraída por ferramentas que geram documentação.
`environ`	Sequência de strings. O padrão é `[]` Fornece uma lista de variáveis de ambiente das quais a extensão do módulo depende. Se uma variável de ambiente dessa lista mudar, a extensão será reavaliada.
`os_dependent`	bool; o padrão é `False` Indica se a extensão depende do SO ou não
`arch_dependent`	bool; o padrão é `False` Indica se a extensão depende da arquitetura ou não

provider

unknown provider(doc=None, *, fields=None, init=None)

Define um símbolo de provedor. O valor resultante dessa função precisa ser armazenado em um valor global para poder ser usado em uma implementação de regra ou aspecto. Os provedores podem ser instanciados chamando o valor resultante como uma função ou usados diretamente como chave de índice para recuperar uma instância desse provedor em um destino. Exemplo:

MyInfo = provider()
...
def _my_library_impl(ctx):
    ...
    my_info = MyInfo(x = 2, y = 3)
    # my_info.x == 2
    # my_info.y == 3
    ...

Consulte Regras (provedores) para um guia completo sobre como usar provedores.

Retorna um valor Provider que pode ser chamado se init não for especificado.

Se init for especificado, retornará uma tupla de dois elementos: um valor acionável Provider e um valor acionável construtor bruto. Consulte Regras (inicialização personalizada de provedores personalizados) e a discussão sobre o parâmetro init abaixo para saber mais.

Parâmetros

Parâmetro Descrição

doc string; ou None o padrão é None
Uma descrição do provedor que pode ser extraída por ferramentas de geração de documentação.

Parâmetro	Descrição
`doc`	string; ou `None` o padrão é `None` Uma descrição do provedor que pode ser extraída por ferramentas de geração de documentação.
`fields`	sequência de strings ou dict; ou `None`; o padrão é `None` Se especificado, restringe o conjunto de campos permitidos. Os valores possíveis são: lista de campos: provider(fields = ['a', 'b']) dictionary field name -> documentation: provider( fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' }) Todos os campos são opcionais.
`init`	callable ou `None`; o padrão é `None` Um callback opcional para pré-processar e validar os valores de campo do provedor durante a instanciação. Se `init` for especificado, `provider()` retornará uma tupla de dois elementos: o símbolo do provedor normal e um construtor bruto. A seguir, há uma descrição precisa. consulte Regras (Inicialização personalizada de provedores) para ter uma discussão intuitiva e casos de uso. Permita que `P` seja o símbolo do provedor criado chamando `provider()`. Conceitualmente, uma instância de `P` é gerada chamando uma função de construtor padrão `c(args, kwargs)`, que faz o seguinte: Se `args` não estiver vazio, ocorrerá um erro. Se o parâmetro `fields` for especificado quando `provider()` for chamado e `kwargs` contiver alguma chave que não esteja listada em `fields`, ocorrerá um erro. Caso contrário, `c` retorna uma nova instância que tem, para cada entrada `k: v` em `kwargs`, um campo chamado `k` com o valor `v`. No caso em que um callback `init` não* é fornecido, uma chamada para o próprio símbolo `P` atua como uma chamada para a função de construtor padrão `c`. Em outras palavras, `P(args, kwargs)` retorna `c(args, *kwargs)`. Por exemplo, MyInfo = provider() m = MyInfo(foo = 1) vai fazer com que `m` seja uma instância `MyInfo` com `m.foo == 1`. No entanto, no caso em que `init` for especificado, a chamada `P(args, *kwargs)` realizará as seguintes etapas: O callback é invocado como `init(args, kwargs)`, ou seja, com os mesmos argumentos de posição e palavra-chave que foram transmitidos para `P`. O valor de retorno de `init` precisa ser um dicionário, `d`, com chaves que são strings de nome de campo. Caso contrário, um erro vai ocorrer. Uma nova instância de `P` é gerada como se fosse chamar o construtor padrão com as entradas de `d` como argumentos de palavra-chave, como em `c(d)`. Observação: as etapas acima implicam que um erro vai ocorrer se `args` ou `kwargs` não corresponder à assinatura de `init`, se a avaliação do corpo de `init` falhar (talvez intencionalmente por meio de uma chamada para `fail()`) ou se o valor de retorno de `init` não for um dicionário com o esquema esperado. Dessa forma, o callback `init` generaliza a construção normal do provedor, permitindo argumentos posicionais e lógica arbitrária para pré-processamento e validação. Não* é possível contornar a lista de `fields` permitidos. Quando `init` é especificado, o valor de retorno de `provider()` se torna uma tupla `(P, r)`, em que `r` é o construtor bruto. Na verdade, o comportamento de `r` é exatamente o da função de construtor padrão `c` discutida acima. Normalmente, `r` está vinculado a uma variável cujo nome é prefixado com um sublinhado, para que apenas o arquivo .bzl atual tenha acesso direto a ela: MyInfo, _new_myinfo = provider(init = ...)

fields

sequência de strings ou dict; ou None; o padrão é None
Se especificado, restringe o conjunto de campos permitidos.
Os valores possíveis são:

lista de campos:
```
provider(fields = ['a', 'b'])
```

dictionary field name -> documentation:

provider(
       fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })

Todos os campos são opcionais.

init

callable ou None; o padrão é None
Um callback opcional para pré-processar e validar os valores de campo do provedor durante a instanciação. Se init for especificado, provider() retornará uma tupla de dois elementos: o símbolo do provedor normal e um construtor bruto.

A seguir, há uma descrição precisa. consulte Regras (Inicialização personalizada de provedores) para ter uma discussão intuitiva e casos de uso.

Permita que P seja o símbolo do provedor criado chamando provider(). Conceitualmente, uma instância de P é gerada chamando uma função de construtor padrão c(*args, **kwargs), que faz o seguinte:

Se args não estiver vazio, ocorrerá um erro.
Se o parâmetro fields for especificado quando provider() for chamado e kwargs contiver alguma chave que não esteja listada em fields, ocorrerá um erro.
Caso contrário, c retorna uma nova instância que tem, para cada entrada k: v em kwargs, um campo chamado k com o valor v.

No caso em que um callback init não é fornecido, uma chamada para o próprio símbolo P atua como uma chamada para a função de construtor padrão c. Em outras palavras, P(*args, **kwargs) retorna c(*args, **kwargs). Por exemplo,

MyInfo = provider()
m = MyInfo(foo = 1)

vai fazer com que m seja uma instância MyInfo com m.foo == 1.

No entanto, no caso em que init for especificado, a chamada P(*args, **kwargs) realizará as seguintes etapas:

O callback é invocado como init(*args, **kwargs), ou seja, com os mesmos argumentos de posição e palavra-chave que foram transmitidos para P.
O valor de retorno de init precisa ser um dicionário, d, com chaves que são strings de nome de campo. Caso contrário, um erro vai ocorrer.
Uma nova instância de P é gerada como se fosse chamar o construtor padrão com as entradas de d como argumentos de palavra-chave, como em c(**d).

Observação: as etapas acima implicam que um erro vai ocorrer se *args ou **kwargs não corresponder à assinatura de init, se a avaliação do corpo de init falhar (talvez intencionalmente por meio de uma chamada para fail()) ou se o valor de retorno de init não for um dicionário com o esquema esperado.

Dessa forma, o callback init generaliza a construção normal do provedor, permitindo argumentos posicionais e lógica arbitrária para pré-processamento e validação. Não é possível contornar a lista de fields permitidos.

Quando init é especificado, o valor de retorno de provider() se torna uma tupla (P, r), em que r é o construtor bruto. Na verdade, o comportamento de r é exatamente o da função de construtor padrão c discutida acima. Normalmente, r está vinculado a uma variável cujo nome é prefixado com um sublinhado, para que apenas o arquivo .bzl atual tenha acesso direto a ela:

MyInfo, _new_myinfo = provider(init = ...)

repository_rule

callable repository_rule(implementation, *, attrs=None, local=False, environ=[], configure=False, remotable=False, doc=None)

Cria uma nova regra de repositório. Armazene-o em um valor global para que ele possa ser carregado e chamado de uma função de implementação module_extension() ou usado por use_repo_rule().

Parâmetros

Parâmetro	Descrição
`implementation`	callable; required a função que implementa essa regra. É preciso ter um único parâmetro, `repository_ctx`. A função é chamada durante a fase de carregamento para cada instância da regra.
`attrs`	dict ou `None`; o padrão é `None` Um dicionário para declarar todos os atributos da regra do repositório. Ele é mapeado de um nome de atributo para um objeto de atributo (consulte `attr`). Atributos que começam com `_` são particulares e podem ser usados para adicionar uma dependência implícita em um rótulo a um arquivo. Uma regra de repositório não pode depender de um artefato gerado. O atributo `name` é adicionado implicitamente e não pode ser especificado. Os atributos declarados converterão `None` para o valor padrão.
`local`	bool; o padrão é `False` Indica que essa regra busca tudo do sistema local e precisa ser reavaliada em cada busca.
`environ`	sequência de strings o padrão é `[]` Descontinuado. Este parâmetro foi suspenso. Migre para `repository_ctx.getenv`. Fornece uma lista de variáveis de ambiente das quais essa regra do repositório depende. Se uma variável de ambiente nessa lista mudar, o repositório será buscado novamente.
`configure`	bool; o padrão é `False` Indica que o repositório inspeciona o sistema para fins de configuração
`remotable`	bool; o padrão é `False` Experimental. Esse parâmetro é experimental e pode ser alterado a qualquer momento. Não dependa disso. Para ativar esse recurso experimental, defina `--experimental_repo_remote_exec` Compatível com a execução remota
`doc`	string; ou `None` o padrão é `None` Uma descrição da regra do repositório que pode ser extraída por ferramentas de geração de documentação.

regra

callable rule(implementation, *, test=unbound, attrs={}, outputs=None, executable=unbound, output_to_genfiles=False, fragments=[], host_fragments=[], _skylark_testable=False, toolchains=[], incompatible_use_toolchain_transition=False, doc=None, provides=[], dependency_resolution_rule=False, exec_compatible_with=[], analysis_test=False, build_setting=None, cfg=None, exec_groups=None, initializer=None, parent=None, extendable=None, subrules=[])

Cria uma nova regra que pode ser chamada de um arquivo BUILD ou uma macro para criar destinos.

As regras precisam ser atribuídas a variáveis globais em um arquivo .bzl. O nome da variável global é o nome da regra.

As regras de teste precisam ter um nome que termine em _test, enquanto todas as outras regras não podem ter esse sufixo. Essa restrição se aplica apenas às regras, não aos alvos delas.

Parâmetros

Parâmetro	Descrição
`implementation`	function; required a função Starlark que implementa essa regra precisa ter exatamente um parâmetro: ctx. A função é chamada durante a fase de análise para cada instância da regra. Ele pode acessar os atributos fornecidos pelo usuário. Ele precisa criar ações para gerar todas as saídas declaradas.
`test`	bool; O padrão é `unbound` Indica se essa regra é de teste, ou seja, se ela pode ser o assunto de um comando `blaze test`. todas as regras de teste são automaticamente consideradas executable; é desnecessário (e não recomendado) definir explicitamente `executable = True` para uma regra de teste. O valor padrão é `False`. Consulte a página Regras para mais informações.
`attrs`	dict: o padrão é `{}` . Um dicionário para declarar todos os atributos da regra. Ele é mapeado de um nome de atributo para um objeto de atributo (consulte `attr`). Atributos que começam com `_` são particulares e podem ser usados para adicionar uma dependência implícita em um rótulo. O atributo `name` é adicionado implicitamente e não pode ser especificado. Os atributos `visibility`, `deprecation`, `tags`, `testonly` e `features` são adicionados implicitamente e não podem ser substituídos. A maioria das regras precisa apenas de alguns atributos. Para limitar o uso da memória, há um limite no número de atributos que podem ser declarados. Os atributos declarados converterão `None` para o valor padrão.
`outputs`	dict; ou `None`; ou function; o padrão é `None` Descontinuado. Este parâmetro foi descontinuado e será removido em breve. Não dependa dele. Ele está desativado com `--incompatible_no_rule_outputs_param`. Use essa sinalização para verificar se seu código é compatível com a remoção iminente. Este parâmetro foi descontinuado. Migre as regras para usar `OutputGroupInfo` ou `attr.output`. Um esquema para definir saídas pré-declaradas. Ao contrário dos atributos `output` e `output_list`, o usuário não especifica os rótulos desses arquivos. Consulte a página Regras para mais informações sobre resultados pré-declarados. O valor desse argumento é um dicionário ou uma função de callback que produz um dicionário. O callback funciona de forma semelhante aos atributos de dependência computados: os nomes de parâmetro da função são comparados com os atributos da regra. Por exemplo, se você transmitir `outputs = _my_func` com a definição `def _my_func(srcs, deps): ...`, a função terá acesso aos atributos `srcs` e `deps`. O dicionário é interpretado da seguinte forma, seja especificado diretamente ou por uma função. Cada entrada no dicionário cria uma saída predeclarada em que a chave é um identificador e o valor é um modelo de string que determina o rótulo da saída. Na função de implementação da regra, o identificador se torna o nome do campo usado para acessar o `File` da saída em `ctx.outputs`. O rótulo da saída tem o mesmo pacote da regra, e a parte após o pacote é produzida substituindo cada marcador de posição do formulário `"%{ATTR}"` por uma string formada pelo valor do atributo `ATTR`: Os atributos do tipo string são substituídos literalmente. Os atributos do tipo rótulo se tornam parte do rótulo após o pacote, menos a extensão do arquivo. Por exemplo, o rótulo `"//pkg:a/b.c"` se torna `"a/b"`. Os atributos do tipo saída se tornam parte do rótulo após o pacote, incluindo a extensão do arquivo (no exemplo acima, `"a/b.c"`). Todos os atributos do tipo lista (por exemplo, `attr.label_list`) usados em marcadores de posição precisam ter exatamente um elemento. A conversão é igual à versão sem lista (`attr.label`). Outros tipos de atributos podem não aparecer em marcadores de posição. Os marcadores de posição que não são atributos especiais `%{dirname}` e `%{basename}` se expandem para essas partes do rótulo da regra, exceto o pacote. Por exemplo, em `"//pkg:a/b.c"`, o nome de diretório é `a` e o nome de base é `b.c`. Na prática, o marcador de substituição mais comum é `"%{name}"`. Por exemplo, para um destino chamado "foo", o dict de saídas `{"bin": "%{name}.exe"}` pré-declara uma saída chamada `foo.exe` que pode ser acessada na função de implementação como `ctx.outputs.bin`.
`executable`	bool; o padrão é `unbound` Indica se a regra é considerada executável, ou seja, se pode ser objeto de um comando `blaze run`. O padrão é `False`. Consulte a página Regras para mais informações.
`output_to_genfiles`	bool; o padrão é `False` Se verdadeiro, os arquivos serão gerados no diretório genfiles em vez de no diretório bin. A menos que você precise para compatibilidade com as regras existentes (por exemplo, ao gerar arquivos de cabeçalho para C++), não defina essa flag.
`fragments`	Sequência de strings. O padrão é `[]` . Lista de nomes de fragmentos de configuração que a regra exige na configuração de destino.
`host_fragments`	sequência de strings o padrão é `[]` Lista de nomes dos fragmentos de configuração que a regra exige na configuração do host.
`_skylark_testable`	bool; o padrão é `False` (Experimental) Se for verdadeiro, esta regra vai expor as ações para inspeção pelas regras que dependem dela usando um provedor `Actions`. O provedor também está disponível para a regra chamando ctx.created_actions(). Ele só deve ser usado para testar o comportamento no momento da análise das regras do Starlark. Essa flag pode ser removida no futuro.
`toolchains`	sequência: o padrão é `[]` . Se definido, o conjunto de toolchains necessário para essa regra. A lista pode conter objetos String, Label ou StarlarkToolchainTypeApi, em qualquer combinação. As cadeias de ferramentas serão encontradas verificando a plataforma atual e fornecidas à implementação da regra por meio de `ctx.toolchain`.
`incompatible_use_toolchain_transition`	bool; o padrão é `False` Descontinuado, não está mais em uso e precisa ser removido.
`doc`	string; ou `None` o padrão é `None` Uma descrição da regra que pode ser extraída por ferramentas de geração de documentação.
`provides`	sequence: o padrão é `[]` . Uma lista de provedores que a função de implementação precisa retornar. É um erro se a função de implementação omitir do valor de retorno qualquer um dos tipos de provedores listados aqui. No entanto, a função de implementação pode retornar outros provedores não listados aqui. Cada elemento da lista é um objeto `*Info` retornado por `provider()`, exceto que um provedor legado é representado pelo nome da string. Quando um destino da regra é usado como uma dependência para um destino que declara um provedor obrigatório, não é necessário especificar esse provedor aqui. Basta que a função de implementação o retorne. No entanto, especificar isso é uma prática recomendada, mesmo que isso não seja obrigatório. No entanto, o campo `required_providers` de um aspecto exige que os provedores sejam especificados aqui.
`dependency_resolution_rule`	bool; o padrão é `False` Se definida, a regra pode ser uma dependência por atributos também marcados como disponíveis nos materializadores. Todos os atributos de regras com essa flag definida também precisam ser marcados como disponíveis nos materializadores. Dessa forma, as regras marcadas não podem depender daquelas que não têm essa marcação.
`exec_compatible_with`	sequência de strings o padrão é `[]` Uma lista de restrições na plataforma de execução que se aplicam a todos os destinos deste tipo de regra.
`analysis_test`	bool; o padrão é `False` Se verdadeiro, essa regra é tratada como um teste de análise. Observação: as regras de teste de análise são definidas principalmente usando a infraestrutura fornecida nas bibliotecas principais do Starlark. Consulte Testes para ver orientações. Se uma regra for definida como uma regra de teste de análise, ela poderá usar transições de configuração definidas usando analysis_test_transition nos atributos, mas vai aceitar algumas restrições: Os destinos desta regra são limitados quanto ao número de dependências transitivas que podem ter. A regra é considerada uma regra de teste (como se `test=True` estivesse definido). Isso substitui o valor de `test`. A função de implementação de regras não pode registrar ações. Em vez disso, é necessário registrar um resultado de aprovação/reprovação fornecendo AnalysisTestResultInfo.
`build_setting`	BuildSetting; ou `None` o padrão é `None` Se definido, descreve o tipo de `build setting` dessa regra. Consulte o módulo `config`. Se esse valor for definido, um atributo obrigatório chamado "build_setting_default" é automaticamente adicionado a esta regra, com um tipo correspondente ao valor passado aqui.
`cfg`	O padrão é `None` Se definido, aponta para a transição de configuração que a regra vai aplicar à própria configuração antes da análise.
`exec_groups`	dict; ou `None` o padrão é `None` Ditado do nome do grupo de execução (string) para `exec_group`s. Se definido, permite que as regras executem ações em várias plataformas de execução dentro de um único destino. Consulte a documentação sobre grupos de execução para mais informações.
`initializer`	padrão é `None` Experimental: a função Stalark inicializa os atributos da regra. A função é chamada no tempo de carregamento para cada instância da regra. Ele é chamado com `name` e os valores dos atributos públicos definidos pela regra (não com atributos genéricos, por exemplo, `tags`). Ele precisa retornar um dicionário dos nomes dos atributos para os valores desejados. Os atributos que não são retornados não são afetados. Retornar `None` como um valor resulta no uso do valor padrão especificado na definição do atributo. Os inicializadores são avaliados antes dos valores padrão especificados em uma definição de atributo. Consequentemente, se um parâmetro na assinatura do inicializador contiver valores padrão, ele vai substituir o padrão da definição do atributo, exceto se retornar `None`. Da mesma forma, se um parâmetro na assinatura do inicializador não tiver um padrão, ele se tornará obrigatório. Nesses casos, é recomendável omitir as configurações padrão/obrigatórias de uma definição de atributo. É recomendável usar `**kwargs` para atributos que não são processados. No caso de regras estendidas, todos os inicializadores são chamados de filhos para ancestrais. Cada inicializador recebe apenas os atributos públicos que ele conhece.
`parent`	o padrão é `None` Experimental: a regra Stalark que é estendida. Quando definido, os atributos públicos são mesclados, assim como os provedores anunciados. A regra corresponde a `executable` e `test` da mãe. Os valores de `fragments`, `toolchains`, `exec_compatible_with` e `exec_groups` são mesclados. Os parâmetros legados ou descontinuados não podem ser definidos. A transição de configuração de entrada `cfg` do pai é aplicada após a configuração de entrada de thisrule.
`extendable`	bool; ou Rótulo; ou string; ou `None`; o padrão é `None` Experimental: um marcador de uma lista de permissões que define quais regras podem estender esta regra. Ela também pode ser definida como verdadeira/falsa para sempre permitir/proibir a extensão. O Bazel sempre permite extensões.
`subrules`	Sequência de subregras; o padrão é `[]` Experimental: lista de subregras usadas por esta regra.

select

unknown select(x, no_match_error='')

select() é a função auxiliar que torna um atributo de regra configurável. Consulte a enciclopédia de criação para mais detalhes.

Parâmetros

Parâmetro	Descrição
`x`	dict; obrigatório Um dicionário que mapeia condições de configuração para valores. Cada chave é um Label ou uma string de rótulo que identifica uma instância de config_setting ou constraints_value. Consulte a documentação sobre macros para saber quando usar um rótulo em vez de uma string.
`no_match_error`	string; o padrão é `''` Erro personalizado opcional a ser informado se nenhuma condição corresponder.

sub-regra

Subrule subrule(implementation, attrs={}, toolchains=[], fragments=[], subrules=[])

Constrói uma nova instância de uma sub-regra. O resultado dessa função precisa ser armazenado em uma variável global antes de ser usado.

Parâmetros

Parâmetro	Descrição
`implementation`	function; required A função Starlark que implementa essa subregrinha
`attrs`	dict; o padrão é `{}` Um dicionário para declarar todos os atributos (privados) da sub-regra. As subregras só podem ter atributos particulares do tipo rótulo (ou seja, rótulo ou lista de rótulos). Os valores resolvidos que correspondem a esses marcadores são transmitidos automaticamente pelo Bazel para a função de implementação da sub-regra como argumentos nomeados. Assim, a função de implementação é necessária para aceitar parâmetros nomeados que correspondam aos nomes dos atributos. Os tipos desses valores serão: `FilesToRunProvider` para atributos de rótulo com `executable=True` `File` para atributos de rótulo com `allow_single_file=True` `Target` para todos os outros atributos de rótulo `[Target]` para todos os atributos de lista de rótulos
`toolchains`	sequence; o padrão é `[]` Se definido, o conjunto de conjuntos de ferramentas exigido por essa sub-regra. A lista pode conter objetos String, Label ou StarlarkToolchainTypeApi, em qualquer combinação. Os conjuntos de ferramentas são encontrados ao verificar a plataforma atual e fornecidos à implementação da sub-regra via `ctx.toolchains`.
`fragments`	Sequência de strings. O padrão é `[]` . Lista de nomes de fragmentos de configuração que a subregra requer na configuração de destino.
`subrules`	sequência de Sub-regrass; o padrão é `[]` Lista de outras subregras exigidas por esta sub-regra.

tag_class

tag_class tag_class(attrs={}, *, doc=None)

Cria um novo objeto tag_class, que define um esquema de atributo para uma classe de tags, que são objetos de dados que podem ser usados por uma extensão de módulo.

Parâmetros

Parâmetro	Descrição
`attrs`	dict; o padrão é `{}` Um dicionário para declarar todos os atributos dessa classe de tag. Ele é mapeado de um nome de atributo para um objeto de atributo (consulte attr. Ao contrário de `rule()`, `aspect()` e `repository_rule()`, os atributos declarados não convertem `None` no valor padrão. Para que o padrão seja usado, o atributo precisa ser omitido totalmente pelo autor da chamada.
`doc`	string; ou `None` o padrão é `None` Uma descrição da classe de tag que pode ser extraída por ferramentas que geram documentação.

visibilidade

None visibility(value)

Define a visibilidade de carregamento do módulo .bzl que está sendo inicializado.

A visibilidade de carregamento de um módulo determina se outros arquivos BUILD e .bzl podem ou não carregá-lo. Isso é diferente da visibilidade de destino do arquivo de origem .bzl, que determina se o arquivo pode aparecer como uma dependência de outros destinos. A visibilidade de carga funciona no nível de pacotes: para carregar um módulo, o arquivo que está fazendo o carregamento precisa estar em um pacote que tenha recebido visibilidade para o módulo. Um módulo sempre pode ser carregado no próprio pacote, independentemente da visibilidade.

O visibility() só pode ser chamado uma vez por arquivo .bzl e somente no nível superior, não dentro de uma função. O estilo preferido é colocar essa chamada imediatamente abaixo das instruções load() e de qualquer lógica breve necessária para determinar o argumento.

Se a flag --check_bzl_visibility estiver definida como falsa, as violações de visibilidade de carregamento vão emitir avisos, mas não vão falhar no build.

Parâmetros

Parâmetro Descrição

Parâmetro	Descrição
`value`	obrigatório Uma lista de strings de especificação de pacote ou uma única string de especificação de pacote. As especificações de pacote seguem o mesmo formato de `package_group`, com a exceção de que não são permitidas especificações negativas de pacote. Isto é, uma especificação pode ter os seguintes formatos: `"//foo"`: o pacote `//foo` `"//foo/..."`: o pacote `//foo` e todos os subpacotes dele. `"public"` ou `"private"`: todos os pacotes ou nenhum pacote, respectivamente. O "@" sintaxe não é permitida; todas as especificações são interpretadas em relação ao repositório do módulo atual. Se `value` for uma lista de strings, o conjunto de pacotes com visibilidade para este módulo será a união dos pacotes representados por cada especificação. Uma lista vazia tem o mesmo efeito que `private`. Se `value` for uma única string, ela vai ser tratada como se fosse a lista de singleton `[value]`. As flags `--incompatible_package_group_has_public_syntax` e `--incompatible_fix_package_group_reporoot_syntax` não afetam esse argumento. Os valores `"public"` e `"private"` estão sempre disponíveis, e `"//..."` é sempre interpretado como "todos os pacotes no repositório atual".

value

obrigatório
Uma lista de strings de especificação de pacote ou uma única string de especificação de pacote.

As especificações de pacote seguem o mesmo formato de package_group, com a exceção de que não são permitidas especificações negativas de pacote. Isto é, uma especificação pode ter os seguintes formatos:

"//foo": o pacote //foo
"//foo/...": o pacote //foo e todos os subpacotes dele.
"public" ou "private": todos os pacotes ou nenhum pacote, respectivamente.

O "@" sintaxe não é permitida; todas as especificações são interpretadas em relação ao repositório do módulo atual.

Se value for uma lista de strings, o conjunto de pacotes com visibilidade para este módulo será a união dos pacotes representados por cada especificação. Uma lista vazia tem o mesmo efeito que private. Se value for uma única string, ela vai ser tratada como se fosse a lista de singleton [value].

As flags --incompatible_package_group_has_public_syntax e --incompatible_fix_package_group_reporoot_syntax não afetam esse argumento. Os valores "public" e "private" estão sempre disponíveis, e "//..." é sempre interpretado como "todos os pacotes no repositório atual".