- Uso
- Variáveis predefinidas
- Variáveis predefinidas de genrule
- Variáveis predefinidas de caminho de origem/saída
- Variáveis personalizadas
"Fazer" são uma classe especial de variáveis de string expansíveis disponíveis para atributos marcados como "Sujeito a "Criar variável" substituição".
Elas podem ser usadas, por exemplo, para injetar caminhos específicos de toolchain em ações de build criadas pelo usuário.
O Bazel fornece as duas variáveis predefinidas, que estão disponíveis para todos destinos, e variáveis personalizadas, que são definidas em destinos de dependência e disponível apenas para destinos que dependem deles.
O motivo do termo "Make" é histórico: a sintaxe e a semântica dessas variáveis foram originalmente criadas para corresponder ao GNU Make.
Usar
Atributos marcados como "Sujeito à substituição da variável "Make"" podem
referenciar a variável FOO
"Make" da seguinte maneira:
my_attr = "prefix $(FOO) suffix"
Em outras palavras, qualquer substring que corresponda a $(FOO)
é expandida
para o valor de FOO
. Se esse valor for "bar"
, a string
final vai ser:
my_attr = "prefix bar suffix"
Se FOO
não corresponder a uma variável conhecida pelas
destino, o Bazel falha com um erro.
Variáveis "Make" com nomes que são símbolos que não são letras, como
@
, também podem ser referenciadas usando apenas um cifrão, sem
parênteses. Exemplo:
my_attr = "prefix $@ suffix"
Para escrever $
como um literal de string (ou seja, para evitar a expansão
da variável), escreva $$
.
Variáveis predefinidas
"Marca" predefinida variáveis podem ser referenciadas por qualquer atributo marcado como "Sujeito a 'Criar variável' substituição" em qualquer destino.
Para ver a lista dessas variáveis e os valores delas para um determinado conjunto de build opções, executar
bazel info --show_make_env [build options]
e observe as primeiras linhas da saída com letras maiúsculas.
Veja um exemplo de variáveis predefinidas.
Variáveis de opção do conjunto de ferramentas
COMPILATION_MODE
:fastbuild
,dbg
ouopt
. (mais detalhes).
Variáveis de caminho
-
BINDIR
: a base da árvore binária gerada para a arquitetura de destino.Observe que uma árvore diferente pode ser usada para programas executados durante a se baseia na arquitetura do host para possibilitar a compilação cruzada.
Se você quiser executar uma ferramenta em um
genrule
, a maneira recomendada de acessar o caminho dela é$(execpath toolname)
, em que toolname precisa estar listado no atributotools
dogenrule
. GENDIR
: A base da árvore de código gerada para a arquitetura de destino.
Variáveis de arquitetura de máquina
-
TARGET_CPU
: A CPU da arquitetura de destino, por exemplo,k8
.
Variáveis de genrule predefinidas
Os recursos a seguir estão disponíveis especialmente para ogenrule
cmd
e estão
é importante para que o atributo funcione.
Veja um exemplo de variáveis predefinidas de regra geral.
OUTS
: a listaouts
dogenrule
. Se você tiver apenas um arquivo de saída, também é possível usar$@
.-
SRCS
: a listasrcs
dogenrule
(ou, mais precisamente, os nomes de caminho dos arquivos correspondentes aos rótulos na listasrcs
). Se você tiver apenas um arquivo de origem, também poderá usar$<
. -
<
:SRCS
, se for um único arquivo. Outros gatilhos um erro de build. -
@
:OUTS
, se for um único arquivo. Caso contrário, um erro de build será acionado. -
RULEDIR
: o diretório de saída do destino, ou seja, o diretório correspondente ao nome do pacote que contém o destino na árvoregenfiles
oubin
. Para//my/pkg:my_genrule
, isso sempre termina emmy/pkg
, mesmo que as saídas de//my/pkg:my_genrule
estejam em subdiretórios. -
@D
: o diretório de saída. Se outs tem uma entrada, isso se expande para o diretório que contém o arquivo. Se tiver várias entradas, isso será expandido para o diretório raiz do pacote na árvoregenfiles
, mesmo que todos os arquivos de saída estejam no mesmo subdiretório.Observação:use
RULEDIR
em vez de@D
porqueRULEDIR
tem uma semântica mais simples e se comporta da mesma maneira independentemente do número de arquivos de saída.Se a genrule precisar gerar arquivos intermediários temporários (talvez como resultado do uso de outra ferramenta, como um compilador), ela tentará gravá-los em
@D
(embora/tmp
também possa ser gravado) e removê-los antes de terminar.Evite especialmente gravar em diretórios que contenham entradas. Eles podem estar ativados em sistemas de arquivos somente leitura. Mesmo que não seja, isso vai destruir a árvore de origem.
Variáveis de caminho de origem/saída predefinidas
As variáveis predefinidas execpath
, execpaths
,
rootpath
, rootpaths
, location
e
locations
usam parâmetros de rótulo (por exemplo, $(execpath
//foo:bar)
) e substituem os caminhos de arquivo indicados por esse rótulo.
Para arquivos de origem, esse é o caminho relativo à raiz do espaço de trabalho. Para arquivos que são saídas de regras, esse é o caminho de saída do arquivo. Consulte a explicação sobre arquivos de saída abaixo.
Confira um exemplo de variáveis de caminho predefinidas.
-
execpath
: indica o caminho abaixo do execroot em que o Bazel executa ações de build.No exemplo acima, o Bazel executa todas as ações de build no diretório vinculado pelo link simbólico
bazel-myproject
na raiz do espaço de trabalho. O o arquivo de origemempty.source
está vinculado ao caminhobazel-myproject/testapp/empty.source
. Portanto, o caminho de execução (que é o subcaminho abaixo da raiz) étestapp/empty.source
. Isso é o caminho que as ações de compilação podem usar para encontrar o arquivo.Os arquivos de saída são preparados de forma semelhante, mas também têm como prefixo o subcaminho
bazel-out/cpu-compilation_mode/bin
(ou para as saídas de ferramentas:bazel-out/cpu-opt-exec-hash/bin
). No exemplo acima,//testapp:app
é uma ferramenta porque aparece Atributotools
deshow_app_output
. Portanto, o arquivo de saídaapp
é gravadobazel-myproject/bazel-out/cpu-opt-exec-hash/bin/testapp/app
. O caminho de execução é, portanto,bazel-out/cpu-opt-exec-hash/bin/testapp/app
. Esse prefixo extra é possível criar o mesmo destino para duas CPUs diferentes a mesma construção sem que os resultados atrapalhem uns aos outros.O rótulo transmitido a essa variável precisa representar exatamente um arquivo. Para rótulos que representam arquivos de origem, isso é automaticamente verdadeiro. Para rótulos que representam regras, a regra precisa gerar exatamente uma saída. Se for falso ou o rótulo estiver malformado, o build falhará com um erro.
-
rootpath
: indica o caminho que um binário criado pode usar para encontrar uma dependência no ambiente de execução em relação ao subdiretório dos arquivos de execução que corresponde ao repositório principal. Observação: isso só funciona se--enable_runfiles
está ativado, o que não acontece Windows por padrão. Userlocationpath
para oferecer suporte a várias plataformas.Isso é semelhante a
execpath
, mas remove os prefixos de configuração descritos acima. No exemplo acima, isso significa queempty.source
eapp
usam caminhos puramente relativos ao espaço de trabalho:testapp/empty.source
etestapp/app
.O
rootpath
de um arquivo em um repositório externorepo
vai começar com../repo/
, seguido pelo caminho relativo ao repositório.Tem a mesma saída "apenas uma" como
execpath
. -
rlocationpath
: o caminho que um binário criado pode transmitir para a funçãoRlocation
de uma biblioteca de arquivos de execução para encontrar uma dependência em ambiente de execução, seja no diretório runfiles (se disponível) ou usando a manifesto dos arquivos de execução.Isso é semelhante a
rootpath
, porque não contém prefixos de configuração, mas difere porque sempre começa com o nome do repositório. No exemplo acima, isso significa queempty.source
eapp
resultam no seguinte caminhos:myproject/testapp/empty.source
emyproject/testapp/app
.O
rlocationpath
de um arquivo em um repositório externorepo
começa comrepo/
, seguido pelo caminho relativo ao repositório.Transmitir esse caminho para um binário e resolvê-lo em um caminho de sistema de arquivos usando as bibliotecas runfiles são a abordagem recomendada para encontrar dependências em no ambiente de execução. Em comparação com
rootpath
, ele tem a vantagem de que funciona em todas as plataformas e mesmo se o diretório runfiles não estiver disponíveis.Tem a mesma saída "apenas uma" como
execpath
. -
location
: um sinônimo deexecpath
ourootpath
, dependendo do atributo que está sendo expandido. Isso é comportamento pré-Starlark legado e não é recomendado, a menos que você realmente saiba para determinada regra. Consulte No 2475 para mais detalhes.
execpaths
, rootpaths
, rlocationpaths
e locations
são as variações plurais de execpath
,
rootpath
, rlocationpaths
e location
,
respectivamente. Eles oferecem suporte a rótulos que produzem várias saídas. Nesse caso,
cada saída é listada separadas por um espaço. Regras de saída zero e rótulos
malformados produzem erros de build.
Todos os rótulos referenciados precisam aparecer no srcs
do destino de consumo.
arquivos de saída, ou deps
. Caso contrário, o build falhará. Os destinos do C++ também
podem referenciar rótulos em data
.
Os rótulos não precisam estar no formato canônico: foo
, :foo
e //somepkg:foo
estão bem.
Variáveis personalizadas
As variáveis "Make" personalizadas podem ser referenciadas por qualquer atributo marcado como "Sujeito à substituição da variável "Make"", mas apenas em segmentos que dependem de outros que definem essas variáveis.
Como prática recomendada, todas as variáveis devem ser personalizadas, a menos que haja uma boa e por isso é importante incluí-los no Bazel básico. Isso evita que o Bazel precise carregar dependências potencialmente caras para fornecer variáveis que consomem tarets que não se importam.
Variáveis da cadeia de ferramentas do C++
Os itens a seguir são definidos nas regras do conjunto de ferramentas do C++ e estão disponíveis para qualquer regra
que define toolchains =
["@bazel_tools//tools/cpp:current_cc_toolchain"]
Algumas regras, como java_binary
, implicitamente
incluir o conjunto de ferramentas C++ na definição da regra. Eles herdam essas variáveis
automaticamente.
As regras integradas do C++ são muito mais sofisticadas do que "executar o compilador nele". Para oferecer suporte a modos de compilação tão diversos como *SAN, ThinLTO, com/sem módulos e binários cuidadosamente otimizados ao mesmo tempo que executar testes rápidos em várias plataformas, as regras integradas são ideais para garantir que as entradas, saídas e sinalizações de linha de comando corretas sejam definidas em cada uma das ações possivelmente geradas internamente.
Essas variáveis são um mecanismo alternativo para uso por especialistas em linguagem em casos raros. Se você tiver vontade de usá-los, entre em contato com os desenvolvedores do Bazel primeiro.
ABI
: a versão da ABI C++.-
AR
: o "ar" do Crosstool. -
C_COMPILER
: O identificador do compilador C/C++, por exemplo,llvm
. -
CC
: o comando do compilador C e C++.É altamente recomendável usar sempre
CC_FLAGS
nas combinação comCC
. Se você não fizer isso, será por sua conta e risco. CC_FLAGS
: um conjunto mínimo de sinalizações para a biblioteca C/C++. para que o compilador possa ser usado pelas regras gerais. Especificamente, ele contém sinalizações para selecione a arquitetura correta seCC
for compatível com várias arquitetônicas.-
NM
: o comando "nm" do crosstool. -
OBJCOPY
: o comando objcopy do mesmo pacote que o módulo C/C++. . -
STRIP
: o comando de remoção do mesmo pacote que o código C/C++. .
Variáveis da cadeia de ferramentas do Java
As seguintes regras são definidas nas regras do conjunto de ferramentas Java e estão disponíveis para qualquer regra
que defina toolchains =
["@bazel_tools//tools/jdk:current_java_runtime"]
(ou
"@bazel_tools//tools/jdk:current_host_java_runtime"
para o equivalente do conjunto de ferramentas do host).
A maioria das ferramentas do JDK não deve ser usada diretamente. A biblioteca Java integrada usam abordagens muito mais sofisticadas para compilação e empacotamento em Java do que as ferramentas upstream podem expressar, como jars de interface, interfaces de cabeçalho Jars e empacotamento de Jar altamente otimizado e implementações de mesclagem.
Essas variáveis são um mecanismo alternativo para uso por especialistas em linguagem em casos raros. Se você quiser usá-los, entre em contato com os desenvolvedores do Bazel primeiro.
-
JAVA
: a classe "java" (uma instância virtual Java máquina virtual. Evite isso e use uma regrajava_binary
sempre que possível. Pode ser um caminho relativo. Se você precisar alterar diretórios antes de invocarjava
, você precisa capturar diretório de trabalho antes de mudá-lo. JAVABASE
: o diretório base que contém os utilitários Java. Pode ser um caminho relativo. Ele terá um subdiretório "bin".
Variáveis definidas pelo Starlark
Os criadores de regras e de toolchain podem definir
variáveis totalmente personalizadas retornando um
provedor de
TemplateVariableInfo. Qualquer regra que dependa deles pelo atributo
toolchains
pode ler os valores: