Esse conjunto de regras existe para permitir que você modele plataformas de hardware específicas para que você está criando e especifique as ferramentas específicas que podem ser necessárias para compilar o código para essas plataformas. O usuário precisa estar familiarizado com os conceitos explicados aqui.
Regras
Configuração de restrição
Ver origem da regraconstraint_setting(name, default_constraint_value, deprecation, distribs, features, licenses, tags, testonly, visibility)
Essa regra é usada para introduzir um novo tipo de restrição que pode ser especificado por uma plataforma.
Por exemplo, é possível definir um constraint_setting
chamado "glibc_version" para representar
a capacidade das plataformas de ter diferentes versões da biblioteca glibc instaladas.
Para mais detalhes, consulte a página
Plataformas.
Cada constraint_setting
tem um conjunto extensível de constraint_value
s
associados. Normalmente, eles são definidos no mesmo pacote, mas, às vezes, um
pacote diferente introduz novos valores para uma configuração existente. Por exemplo, a configuração
predefinida @platforms//cpu:cpu
pode ser estendida com um valor personalizado para definir uma
plataforma que segmente uma arquitetura de CPU obscura.
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para esse destino. |
default_constraint_value
|
constraint_value para o qual ele aponta precisa ser definido no
mesmo pacote que esse constraint_setting .
Se uma configuração de restrição tiver um valor padrão, sempre que uma plataforma não incluir
nenhum valor para a configuração, ela será a mesma que se a plataforma tivesse especificado o
valor padrão. Caso contrário, se não houver um valor padrão, a configuração de restrição será considerada não especificada por essa plataforma. Nesse caso, a plataforma não corresponde a nenhuma lista de restrições (como para uma |
valor_da_restrição
Ver origem da regraconstraint_value(name, constraint_setting, deprecation, distribs, features, licenses, tags, testonly, visibility)Esta regra introduz um novo valor para um determinado tipo de restrição. Para mais detalhes, consulte a página Plataformas.
Exemplo
Veja a seguir um novo valor possível para o constraint_value
predefinido que representa a arquitetura da CPU.
constraint_value( name = "mips", constraint_setting = "@platforms//cpu:cpu", )As plataformas podem declarar que têm a arquitetura
mips
como alternativa a
x86_64
, arm
e assim por diante.
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para esse destino. |
constraint_setting
|
constraint_setting para o qual constraint_value é uma opção possível.
|
platform
Ver origem da regraplatform(name, constraint_values, deprecation, distribs, exec_properties, features, licenses, parents, remote_execution_properties, tags, testonly, visibility)
Essa regra define uma nova plataforma: uma coleção nomeada de restrições de opções, como arquitetura de CPU ou versão do compilador, descrevendo um ambiente em que parte do build pode ser executada. Para mais detalhes, consulte a página Plataformas.
Exemplo
Isso define uma plataforma que descreve qualquer ambiente que execute o Linux em ARM.
platform( name = "linux_arm", constraint_values = [ "@platforms//os:linux", "@platforms//cpu:arm", ], )
Herança de plataforma
As plataformas podem usar o atributo parents
para especificar outra plataforma de que elas vão herdar valores de restrição. Embora o atributo parents
use uma lista, não é possível
ter mais de um valor único e especificar vários pais é um erro.
Ao verificar o valor de uma configuração de restrição em uma plataforma, primeiro os valores definidos diretamente
(pelo atributo constraint_values
) são verificados. Em seguida, os valores de restrição no
pai. Isso continua de maneira recursiva na cadeia de plataformas mãe. Dessa forma, qualquer
valor definido diretamente em uma plataforma substitui os valores definidos no pai.
As plataformas herdam o atributo exec_properties
da plataforma mãe.
As entradas do dicionário em exec_properties
das plataformas pai e filha
vão ser combinadas.
Se a mesma chave aparecer nos exec_properties
do pai e do filho,
o valor do filho será usado. Se a plataforma filha especificar uma string vazia como um valor, a propriedade correspondente não será definida.
As plataformas também podem herdar o atributo remote_execution_properties
(descontinuado)
da plataforma pai. Observação: o novo código precisa usar exec_properties
. A
lógica descrita abaixo é compatível com o comportamento legado, mas será removida
no futuro.
A lógica para definir o remote_execution_platform
é a seguinte quando há uma plataforma pai:
-
Se
remote_execution_property
não estiver definido na plataforma filha, oremote_execution_properties
do pai será usado. -
Se
remote_execution_property
estiver definido na plataforma filha e contiver a string literal {PARENT_REMOTE_EXECUTION_PROPERTIES}, essa macro será substituída pelo conteúdo do atributoremote_execution_property
do pai. -
Se
remote_execution_property
for definido na plataforma filha e não contiver a macro, aremote_execution_property
filha será usada inalterada.
Como remote_execution_properties
foi descontinuado e será desativado, não é permitido misturar remote_execution_properties
e exec_properties
na mesma cadeia de herança.
Use exec_properties
em vez de
remote_execution_properties
, que foi descontinuado
Exemplo: valores de restrição
platform( name = "parent", constraint_values = [ "@platforms//os:linux", "@platforms//cpu:arm", ], ) platform( name = "child_a", parents = [":parent"], constraint_values = [ "@platforms//cpu:x86_64", ], ) platform( name = "child_b", parents = [":parent"], )
Neste exemplo, as plataformas filhas têm as seguintes propriedades:
-
child_a
tem os valores de restrição@platforms//os:linux
(herdados do pai) e@platforms//cpu:x86_64
(definidos diretamente na plataforma). -
child_b
herda todos os valores de restrição do pai e não define nenhum.
Exemplo: propriedades de execução
platform( name = "parent", exec_properties = { "k1": "v1", "k2": "v2", }, ) platform( name = "child_a", parents = [":parent"], ) platform( name = "child_b", parents = [":parent"], exec_properties = { "k1": "child" } ) platform( name = "child_c", parents = [":parent"], exec_properties = { "k1": "" } ) platform( name = "child_d", parents = [":parent"], exec_properties = { "k3": "v3" } )
Neste exemplo, as plataformas filhas têm as seguintes propriedades:
-
child_a
herda o "exec_properties" do pai e não define o próprio. -
child_b
herda oexec_properties
do pai e substitui o valor dek1
. Oexec_properties
será:{ "k1": "child", "k2": "v2" }
. -
child_c
herda oexec_properties
do pai e não definek1
. Oexec_properties
será:{ "k2": "v2" }
. -
child_d
herda oexec_properties
do pai e adiciona uma nova propriedade. Oexec_properties
será:{ "k1": "v1", "k2": "v2", "k3": "v3" }
.
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para esse destino. |
constraint_values
|
Cada |
exec_properties
|
exec_properties da plataforma mãe.
Se as plataformas filha e mãe definirem as mesmas chaves, os valores serão mantidos. Todas as chaves associadas a um valor que é uma string vazia são removidas do dicionário.
Esse atributo é uma substituição completa do remote_execution_properties descontinuado.
|
parents
|
platform do qual esta plataforma precisa herdar. Embora o
atributo use uma lista, não poderá haver mais de uma plataforma. As
constraint_settings não definidas diretamente nesta plataforma serão encontradas na plataforma mãe.
Consulte a seção Herança da plataforma para ver mais detalhes.
|
remote_execution_properties
|
|
conjunto de ferramentas
Ver origem da regratoolchain(name, deprecation, distribs, exec_compatible_with, features, licenses, tags, target_compatible_with, target_settings, testonly, toolchain, toolchain_type, visibility)
Essa regra declara o tipo e as restrições de um conjunto de ferramentas específico para que ele possa ser selecionado durante a resolução do conjunto de ferramentas. Consulte a página Conjuntos de ferramentas para mais detalhes.
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para esse destino. |
exec_compatible_with
|
constraint_value s que precisam ser atendidos por uma plataforma de execução para que esse conjunto de ferramentas seja selecionado para um edifício de destino nessa plataforma.
|
target_compatible_with
|
constraint_value s que precisam ser atendidos pela plataforma de destino
para que esse conjunto de ferramentas seja selecionado para um edifício de destino nessa plataforma.
|
target_settings
|
config_setting s que precisam ser atendidos pela configuração de destino
para que esse conjunto de ferramentas seja selecionado durante a resolução dele.
|
toolchain
|
|
toolchain_type
|
toolchain_type , que representa o papel que esse conjunto de ferramentas desempenha.
|
toolchain_type
Ver origem da regratoolchain_type(name, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)
Esta regra define um novo tipo de conjunto de ferramentas: um destino simples que representa uma classe de ferramentas que têm a mesma função para diferentes plataformas.
Consulte a página Conjuntos de ferramentas para mais detalhes.
Exemplo
Isso define um tipo de conjunto de ferramentas para uma regra personalizada.
toolchain_type( name = "bar_toolchain_type", )
Isso pode ser usado em um arquivo bzl.
bar_binary = rule( implementation = _bar_binary_impl, attrs = { "srcs": attr.label_list(allow_files = True), ... # No `_compiler` attribute anymore. }, toolchains = ["//bar_tools:toolchain_type"] )
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para esse destino. |