Criar variáveis

Informar um problema Conferir origem Noite · 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".

Eles podem ser usados, por exemplo, para injetar caminhos específicos de conjuntos de ferramentas 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órica: a sintaxe e a semântica das essas variáveis originalmente deveriam corresponder ao GNU Make (link em inglês).

Usar

Atributos marcados como "Sujeito a "Criar variável" substituição" pode consulte a seção FOO da seguinte maneira:

my_attr = "prefix $(FOO) suffix"

Em outras palavras, qualquer substring correspondente a $(FOO) é expandida ao valor de FOO. Se esse valor for "bar", o valor final se torna:

my_attr = "prefix bar suffix"

Se FOO não corresponder a uma variável conhecida pelas destino, o Bazel falha com um erro.

"Fazer" variáveis cujos nomes não sejam símbolos de letras, como @, também pode ser referenciado usando apenas um cifrão, sem os parênteses. Exemplo:

my_attr = "prefix $@ suffix"

Para escrever $ como um literal de string (ou seja, para evitar que a variável expansão), 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 o destino do Terraform.

    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, o a maneira recomendada de descobrir o caminho é $(execpath toolname), em que toolname precisa estar listado no genrule tools.

  • 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 regra geral 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 dos caminhos dos arquivos que correspondem aos marcadores no 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, aciona uma erro de build.

  • RULEDIR: o diretório de saída do destino, ou seja, o que corresponde ao nome do pacote que contém o diretório na árvore genfiles ou bin. Para //my/pkg:my_genrule, que 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ários entradas, isso se expande 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), ele deve tentar gravá-las em @D (embora /tmp também ser graváveis) e removê-los antes de finalizar.

    Evite especialmente gravar em diretórios que contenham entradas. Eles podem estar ativados em sistemas de arquivos somente leitura. Mesmo que não, isso descarte a árvore de origem.

Variáveis predefinidas de caminho de origem/saída

As variáveis predefinidas execpath, execpaths, rootpath, rootpaths, location e locations usa parâmetros de rótulo (por exemplo, $(execpath //foo:bar)) e substitui os caminhos de arquivo indicados por esse rótulo.

Para arquivos de origem, é o caminho relativo para a raiz do espaço de trabalho. Para arquivos que são saídas de regras, este é o caminho de saída do arquivo. Veja a explicação dos arquivos de saída abaixo.

Confira um exemplo de variáveis de caminho predefinidas.

  • execpath: indica o caminho abaixo do execroot (em inglês) 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 seu 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. Em vez disso, usar rlocationpath para suporte multiplataforma.

    Isso é semelhante a execpath, mas remove a configuração. os prefixos descritos acima. No exemplo acima, isso significa empty.source e app usam palavras-chave relativas a espaço de trabalho puras caminhos: testapp/empty.source e testapp/app.

    O rootpath de um arquivo em um repositório externo repo começa 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 para 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 e rlocationpaths. e locations são as variações no plural 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 regras rótulos 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 C++ podem também fazem referência a 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

"Marca" personalizada variáveis podem ser referenciadas por qualquer atributo marcado como "Sujeito a 'Criar variável' substituição", mas apenas em alvos que dependem de outros destinos 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. Assim o Bazel não precisa carregar dependências potencialmente caras para fornecer variáveis que consomem taretas pode que não importam.

Variáveis do conjunto de ferramentas 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 em C++ integradas são muito mais sofisticadas do que "executar o compilador em isso." 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 substituto a ser usado por especialistas em linguagens casos raros. Se você quiser 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. Não fazê-lo 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 "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 do conjunto de ferramentas Java

Os itens a seguir são definidos nas regras do conjunto de ferramentas Java e estão disponíveis para qualquer regra que define toolchains = ["@bazel_tools//tools/jdk:current_java_runtime"] (ou "@bazel_tools//tools/jdk:current_host_java_runtime" para o conjunto de ferramentas do host equivalente).

a maioria das ferramentas no 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 substituto a ser usado por especialistas em linguagens 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 o Utilitários do Java. Pode ser um caminho relativo. Ele terá um "bin" .

Variáveis definidas pelo Starlark

Os gravadores de regras e conjunto de ferramentas podem definir variáveis totalmente personalizadas retornando um TemplateVariableInfo de nuvem. Quaisquer regras que dependam delas por meio da O atributo toolchains poderá ler os valores:

Veja um exemplo de variáveis definidas pelo Starlark.