Criar variáveis

Informar um problema Ver o código-fonte Nightly · 7.4 . 7,3 · 7.2 · 7,1 · 7,0 · 6,5

"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

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 atributo tools do genrule.

  • 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 lista outs do genrule. Se você tiver apenas um arquivo de saída, também é possível usar $@.
  • SRCS: a lista srcs do genrule (ou, mais precisamente, os nomes de caminho dos arquivos correspondentes aos rótulos na lista srcs). 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 árvore genfiles ou bin. Para //my/pkg:my_genrule, isso sempre termina em my/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 árvore genfiles, mesmo que todos os arquivos de saída estejam no mesmo subdiretório.

    Observação:use RULEDIR em vez de @D porque RULEDIR 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 origem empty.source está vinculado ao caminho bazel-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 Atributo tools de show_app_output. Portanto, o arquivo de saída app é gravado bazel-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. Use rlocationpath 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 que empty.source e app usam caminhos puramente relativos ao espaço de trabalho: testapp/empty.source e testapp/app.

    O rootpath de um arquivo em um repositório externo repo 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ção Rlocation 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 que empty.source e app resultam no seguinte caminhos: myproject/testapp/empty.source e myproject/testapp/app.

    O rlocationpath de um arquivo em um repositório externo repo começa com repo/, 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 de execpath ou rootpath, 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 com CC. 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 se CC 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 regra java_binary sempre que possível. Pode ser um caminho relativo. Se você precisar alterar diretórios antes de invocar java, 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:

Confira um exemplo de variáveis definidas pelo Starlark.