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

Esta página foi traduzida pela API Cloud Translation.

Regras C / C++

Regras

cc_binary
cc_import
cc_library
cc_proto_library
fdo_prefetch_hints
fdo_profile
propeller_optimize
cc_test
cc_toolchain
cc_toolchain_suite

cc_binary

cc_binary(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, includes, licenses, linkopts, linkshared, linkstatic, local_defines, malloc, nocopts, output_licenses, restricted_to, stamp, tags, target_compatible_with, testonly, toolchains, visibility, win_def_file)

Destinos de saída implícitos

name.stripped (criado apenas se solicitado explicitamente): uma versão removida. versão do binário. strip -g é executado no binário para remover a depuração. símbolos. Outras opções de remoção podem ser fornecidas na linha de comando usando --stripopt=-foo: Essa saída só é criada se solicitada explicitamente.
name.dwp (criado apenas se solicitado explicitamente): se A fissão está ativada: uma depuração. arquivo de pacote de informações adequado para depurar binários implantados remotamente. Caso contrário: um arquivo vazio.

Argumentos

Atributos
`name`	`Name; required` Um nome exclusivo para o destino.
`deps`	`List of labels; optional` A lista de outras bibliotecas a serem vinculadas ao destino binário. Eles podem ser `cc_library` ou `objc_library`. de destino.
`srcs`	`List of labels; optional` A lista de arquivos C e C++ processados para criar o destino. Estes são arquivos de origem e de cabeçalho em C/C++, não gerados (origem normal ou gerados. Todos os arquivos `.cc`, `.c` e `.cpp` serão ser compilado. Podem ser arquivos gerados: se um arquivo nomeado estiver no o `outs` de alguma outra regra, esta regra dependerão automaticamente da outra regra. Um arquivo `.h` não será compilado, mas estará disponível para inclusão por origens nesta regra. Tanto `.cc` quanto Os arquivos `.h` podem incluir diretamente os cabeçalhos listados em esses `srcs` ou no `hdrs` de qualquer regra listada em o argumento `deps`. Todos os arquivos `#include`d precisam ser mencionados no `srcs` desta regra ou da Atributo `hdrs` dos `cc_library()`s referenciados. O estilo recomendado é que os cabeçalhos associados a uma biblioteca sejam listados no atributo `hdrs` dessa biblioteca e os valores cabeçalhos associados às origens desta regra a serem listados em `srcs`. Consulte Verificação da inclusão de cabeçalho. para uma descrição mais detalhada. Se o nome de uma regra estiver em `srcs`, ela depende dela automaticamente. Se os `outs` da regra nomeada forem C ou C++ arquivos de origem, eles são compilados nessa regra. Se forem arquivos de biblioteca, eles serão vinculados. Tipos de arquivo `srcs` permitidos: Arquivos de origem C e C++: `.c`, `.cc`, `.cpp`. `.cxx`, `.c++` e `.C` Arquivos de cabeçalho C e C++: `.h`, `.hh`, `.hpp`, `.hxx`, `.inc`, `.inl`, `.H` Montador com pré-processador C: `.S` Arquivo: `.a`, `.pic.a` "Sempre vincular" biblioteca: `.lo`, `.pic.lo` Biblioteca compartilhada, com ou sem controle de versão: `.so`, `.so.version` Arquivo de objeto: `.o`, `.pic.o` e as regras que produzem esses arquivos. Extensões diferentes indicam linguagens de programação diferentes de acordo com a convenção de GCC.
`additional_linker_inputs`	`List of labels; optional` Transmita esses arquivos para o comando do vinculador do C++. Por exemplo, arquivos .res compilados do Windows podem ser fornecidos aqui para serem incorporados em o destino binário.
`copts`	`List of strings; optional` Adicione essas opções ao comando de compilação do C++. Sujeito à substituição "Make variables" e Tokenização de Bourne Shell. Cada string nesse atributo é adicionada a `COPTS` na ordem determinada antes de e compilar o destino binário. As sinalizações entram em vigor somente para compilar esse destino, não suas dependências, portanto, tenha cuidado com arquivos de cabeçalho incluídos em outros lugares. Todos os caminhos devem ser relativo ao espaço de trabalho, não ao pacote atual. Se o pacote declarar o objeto feature `no_copts_tokenization`: a tokenização de shell Bourne se aplica apenas a strings que consistem em uma única "marca" variável.
`defines`	`List of strings; optional` Lista de definições a serem adicionadas à linha de compilação. Sujeito a "Marca" variável e Tokenização de Bourne Shell. Cada string, que deve consistir em um único token de shell Bourne, tem `-D` como prefixo e foi adicionado à linha de comando de compilação desse destino. e todas as regras que dependem dele. Tenha muito cuidado, pois isso pode ter efeitos mais amplos. Em caso de dúvida, adicione valores definidos ao `local_defines`.
`includes`	`List of strings; optional` Lista de diretórios de inclusão a serem adicionados à linha de compilação. Sujeito à substituição "Make variables". Cada string é prefixada com `-isystem` e adicionada a `COPTS`. Ao contrário de COPTS, essas sinalizações são adicionadas para esta regra e todas as regras que dependem dele. Observação: não são as regras das quais ele depende. Tenha tenha muito cuidado, já que isso pode ter efeitos mais amplos. Em caso de dúvida, adicione "-Eu" para COPTS. Os cabeçalhos precisam ser adicionados a srcs ou hdrs; caso contrário, eles não estarão disponíveis para os quando a compilação está no modo sandbox (o padrão).
`linkopts`	`List of strings; optional` Adicione estas sinalizações ao comando do vinculador C++. Sujeito a "Marca" variável, tokenização de shell Bourne e expansão de rótulos. Cada string nesse atributo é adicionada a `LINKOPTS` antes ao vincular o destino binário. Cada elemento dessa lista que não começa com `$` ou `-` é foi considerado o rótulo de um destino em `deps`. A uma lista de arquivos gerados por esse destino é anexada ao vinculador; . Um erro será informado se o rótulo for inválido ou for não declarado em `deps`.
`linkshared`	`Boolean; optional; nonconfigurable; default is False` Criar uma biblioteca compartilhada. Para ativar esse atributo, inclua `linkshared=True` na sua regra. Por padrão essa opção está desativada. A presença dessa flag significa que a vinculação ocorre com a flag `-shared`. como `gcc`, e a biblioteca compartilhada resultante pode ser carregada para um programa Java. No entanto, para fins de criação, ele nunca será vinculado ao dependente, já que se presume que as bibliotecas compartilhadas criadas com um cc_binary são carregados manualmente apenas por outros programas, então ela não deve ser considerada um substituto para cc_library regra de firewall. Por uma questão de escalonabilidade, recomendamos evitar essa abordagem e simplesmente deixar `java_library` depender de regras `cc_library`. como alternativa. Se você especificar `linkopts=['-static']` e `linkshared=True`, você recebe uma unidade completamente independente. Se você especificar ambos `linkstatic=True` e `linkshared=True`, você recebe uma única, principalmente uma unidade independente.
`linkstatic`	`Boolean; optional; default is True` Para `cc_binary` e `cc_test`: vincular o binário na estática modo Para `cc_library.linkstatic`: confira abaixo. Por padrão, essa opção fica ativada para `cc_binary` e desativada para o restante. Se ativada e for um binário ou teste, essa opção manda a ferramenta de build vincular Sempre que possível, `.a`s em vez de `.so` para bibliotecas do usuário. Algumas bibliotecas do sistema ainda podem ser vinculadas dinamicamente, assim como as bibliotecas para as quais não há uma biblioteca estática. O executável resultante ainda vai ser dinamicamente vinculados, portanto, são apenas quase estáticos. Existem três maneiras diferentes de vincular um executável: STATIC com recurso full_static_link, em que tudo é vinculado estaticamente. Por exemplo: "`gcc -static foo.o libbar.a libbaz.a -lm`". Para ativar esse modo, especifique `fully_static_link` no `features`. STATIC, no qual todas as bibliotecas do usuário são vinculadas estaticamente (se uma está disponível), mas quando as bibliotecas do sistema (exceto bibliotecas de ambiente de execução C/C++) são vinculadas dinamicamente, por exemplo, "`gcc foo.o libfoo.a libbaz.a -lm`". Para ativar esse modo, especifique `linkstatic=True`. DYNAMIC, no qual todas as bibliotecas são vinculadas dinamicamente (se uma versão dinâmica é disponíveis), por exemplo, "`gcc foo.o libfoo.so libbaz.so -lm`". Para ativar esse modo, especifique `linkstatic=False`. O atributo `linkstatic` tem um significado diferente se usado em uma regra `cc_library()`. Para uma biblioteca C++, `linkstatic=True` indica que apenas a vinculação estática é permitida, portanto, nenhum `.so` será produzido. linkstatic=False faz não impede a criação de bibliotecas estáticas. O atributo serve para controlar criação de bibliotecas dinâmicas. Se for `linkstatic=False`, a ferramenta de build criará links simbólicos para dependem das bibliotecas compartilhadas na área de `*.runfiles`.
`local_defines`	`List of strings; optional` Lista de definições a serem adicionadas à linha de compilação. Sujeito a "Marca" variável e Tokenização de Bourne Shell. Cada string, que deve consistir em um único token de shell Bourne, tem `-D` como prefixo e foi adicionado à linha de comando de compilação desse destino. mas não aos dependentes.
`malloc`	`Label; optional; default is @bazel_tools//tools/cpp:malloc` Substitui a dependência padrão em Malloc. Por padrão, os binários C++ são vinculados a `//tools/cpp:malloc`, que é uma biblioteca vazia, de modo que o binário acaba usando a libc Malloc. Esse rótulo precisa se referir a um `cc_library`. Se a compilação for para uma versão que não seja C++ regra, essa opção não terá efeito. O valor desse atributo é ignorado se `linkshared=True` é especificado.
`nocopts`	`String; optional` As opções de correspondência foram removidas do comando de compilação em C++. Sujeito a "Marca" variável. O valor desse atributo é interpretado como uma expressão regular. Qualquer `COPTS` preexistente que corresponda a essa expressão regular (incluindo os valores explicitamente especificados no atributo copts da regra) serão removidos dos `COPTS` para compilar esta regra. Esse atributo raramente será necessário.
`stamp`	`Integer; optional; default is -1` Define se as informações da versão serão codificadas no binário. Valores possíveis: `stamp = 1`: sempre inclua as informações do build no binário, mesmo em `--nostamp` builds. Este deve ser evitada, já que ela pode eliminar o armazenamento em cache remoto dos binário e qualquer ação downstream que dependa dele. `stamp = 0`: sempre substitui as informações do build por valores constantes. Isso oferece um bom armazenamento em cache dos resultados da compilação. `stamp = -1`: a incorporação de informações do build é controlada pelo sinalização `--[no]stamp`. Os binários carimbos não são recriados, a menos que as dependências deles mudem.
`win_def_file`	`Label; optional` O arquivo DEF do Windows a ser passado para o vinculador. Esse atributo só deve ser usado quando o Windows for a plataforma de destino. Ele pode ser usado para exportar símbolos durante a vinculação de uma biblioteca compartilhada.

cc_import

cc_import(name, data, hdrs, alwayslink, compatible_with, deprecation, distribs, features, interface_library, licenses, restricted_to, shared_library, static_library, system_provided, tags, target_compatible_with, testonly, visibility)

As regras cc_import permitem que os usuários importem bibliotecas C/C++ pré-compiladas.

Confira a seguir os casos de uso mais comuns:
1: Como vincular uma biblioteca estática

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  static_library = "libmylib.a",
  # If alwayslink is turned on,
  # libmylib.a will be forcely linked into any binary that depends on it.
  # alwayslink = 1,
)

2: Como vincular uma biblioteca compartilhada (Unix)

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  shared_library = "libmylib.so",
)

3: Como vincular uma biblioteca compartilhada à biblioteca de interfaces (Windows)

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  # mylib.lib is a import library for mylib.dll which will be passed to linker
  interface_library = "mylib.lib",
  # mylib.dll will be available for runtime
  shared_library = "mylib.dll",
)

4) Vincular uma biblioteca compartilhada ao system_provided=True (Windows)

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  # mylib.lib is an import library for mylib.dll which will be passed to linker
  interface_library = "mylib.lib",
  # mylib.dll is provided by system environment, for example it can be found in PATH.
  # This indicates that Bazel is not responsible for making mylib.dll available.
  system_provided = 1,
)

5) Vincular à biblioteca estática ou compartilhada
No Unix:

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  static_library = "libmylib.a",
  shared_library = "libmylib.so",
)

# first will link to libmylib.a
cc_binary(
  name = "first",
  srcs = ["first.cc"],
  deps = [":mylib"],
  linkstatic = 1, # default value
)

# second will link to libmylib.so
cc_binary(
  name = "second",
  srcs = ["second.cc"],
  deps = [":mylib"],
  linkstatic = 0,
)

No Windows:

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  static_library = "libmylib.lib", # A normal static library
  interface_library = "mylib.lib", # An import library for mylib.dll
  shared_library = "mylib.dll",
)

# first will link to libmylib.lib
cc_binary(
  name = "first",
  srcs = ["first.cc"],
  deps = [":mylib"],
  linkstatic = 1, # default value
)

# second will link to mylib.dll through mylib.lib
cc_binary(
  name = "second",
  srcs = ["second.cc"],
  deps = [":mylib"],
  linkstatic = 0,
)

Argumentos

Atributos
`name`	`Name; required` Um nome exclusivo para o destino.
`hdrs`	`List of labels; optional` A lista de arquivos principais publicados por que essa biblioteca pré-compilada seja incluída diretamente pelas fontes em regras dependentes.
`alwayslink`	`Boolean; optional; default is False` Se for 1, qualquer binário que dependa (direta ou indiretamente) desse código C++ pré-compilada vinculará todos os arquivos de objeto arquivados na biblioteca estática, mesmo que alguns não contenham símbolos referenciados pelo binário. Isso é útil se o código não for chamado explicitamente por código em o binário, por exemplo, caso seu código seja registrado para receber algum callback por algum serviço. Se o Alwayslink não funcionar com o VS 2017 no Windows, é devido a problema conhecido, faça upgrade do seu VS 2017 para a versão mais recente.
`interface_library`	`Label; optional` Uma única biblioteca de interface para vincular a biblioteca compartilhada. Tipos de arquivos permitidos: `.ifso`, `.tbd`, `.lib`, `.so` ou `.dylib`
`shared_library`	`Label; optional` Uma única biblioteca compartilhada pré-compilada. O Bazel garante que eles estejam disponíveis que depende dele durante o tempo de execução. Tipos de arquivos permitidos: `.so`, `.dll` ou `.dylib`
`static_library`	`Label; optional` Uma única biblioteca estática pré-compilada. Tipos de arquivos permitidos: `.a`, `.pic.a` ou `.lib`
`system_provided`	`Boolean; optional; default is False` Se for 1, isso indica que a biblioteca compartilhada necessária no momento da execução foi fornecida pelo sistema. Em neste caso, `interface_library` deve ser especificado `shared_library` deve estar vazio.

cc_library

cc_library(name, deps, srcs, data, hdrs, additional_compiler_inputs, additional_linker_inputs, alwayslink, compatible_with, copts, defines, deprecation, distribs, exec_compatible_with, exec_properties, features, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, nocopts, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)

Verificação da inclusão de cabeçalho

Todos os arquivos de cabeçalho usados no build precisam ser declarados nas APIs hdrs ou srcs de cc_* regras. Isso é obrigatório.

Para regras cc_library, os cabeçalhos em hdrs compreendem a interface pública do biblioteca e pode ser incluído diretamente dos arquivos em hdrs e srcs da própria biblioteca, bem como dos arquivos em hdrs e srcs de cc_* regras que listam a biblioteca no deps. Os cabeçalhos em srcs só podem ser incluídos diretamente dos arquivos em hdrs e srcs da própria biblioteca. Ao decidir colocar um cabeçalho hdrs ou srcs, pergunte se você quer os consumidores da biblioteca para poder incluí-lo diretamente. Essa é praticamente a mesma decisão Visibilidade de public e private nas linguagens de programação.

As regras cc_binary e cc_test não têm uma interface exportada, então também não têm um atributo hdrs. Todos os cabeçalhos que pertencem ao binário ou ao diretamente serão listadas no srcs.

Para ilustrar essas regras, veja o exemplo a seguir.

cc_binary(
    name = "foo",
    srcs = [
        "foo.cc",
        "foo.h",
    ],
    deps = [":bar"],
)

cc_library(
    name = "bar",
    srcs = [
        "bar.cc",
        "bar-impl.h",
    ],
    hdrs = ["bar.h"],
    deps = [":baz"],
)

cc_library(
    name = "baz",
    srcs = [
        "baz.cc",
        "baz-impl.h",
    ],
    hdrs = ["baz.h"],
)

As inclusões diretas permitidas neste exemplo estão listadas na tabela abaixo. Por exemplo: foo.cc tem permissão para incluir diretamente foo.h e bar.h, mas não baz.h.

Incluindo arquivo	Inclusões permitidas
foo.h	bar.h
foo.cc	foo.h bar.h
bar.h	bar-impl.h baz.h
barra-impl.h	bar.h baz.h
bar.cc	bar.h bar-impl.h baz.h
baz.h	baz-impl.h
baz-impl.h	baz.h
baz.cc	baz.h baz-impl.h

As regras de verificação de inclusão só se aplicam a eventos diretos inclusões. No exemplo acima, foo.cc pode incluem bar.h, que pode incluir baz.h, que em sua vez pode incluir baz-impl.h. Tecnicamente, os a compilação de um arquivo .cc pode incluir transitivamente qualquer cabeçalho no arquivo hdrs ou srcs na qualquer cc_library na interdição transitiva de deps. Em Nesse caso, o compilador pode ler baz.h e baz-impl.h. ao compilar foo.cc, mas foo.cc não pode contêm #include "baz.h". Para que isso seja permitido, adicione baz a deps de foo.

No momento, o Bazel não consegue distinguir entre direto e transitivo inclusões, o que impede a detecção de casos de erro em que um arquivo inclui ilegalmente uma que só pode ser incluído de forma transitiva. Por exemplo: O Bazel não reclamaria se no exemplo acima foo.cc diretamente inclui baz.h. Isso seria ilegal, porque foo não depende diretamente de baz. Atualmente, nenhum erro é gerado Nesse caso, mas essa verificação de erros poderá ser adicionada no futuro.

Argumentos

Atributos
`name`	`Name; required` Um nome exclusivo para o destino.
`deps`	`List of labels; optional` A lista de outras bibliotecas a serem vinculadas ao destino binário. Eles podem ser `cc_library` ou `objc_library`. de destino.
`srcs`	`List of labels; optional` A lista de arquivos C e C++ processados para criar o destino. Estes são arquivos de origem e de cabeçalho em C/C++, não gerados (origem normal ou gerados. Todos os arquivos `.cc`, `.c` e `.cpp` serão ser compilado. Podem ser arquivos gerados: se um arquivo nomeado estiver no o `outs` de alguma outra regra, esta regra dependerão automaticamente da outra regra. Um arquivo `.h` não será compilado, mas estará disponível para inclusão por origens nesta regra. Tanto `.cc` quanto Os arquivos `.h` podem incluir diretamente os cabeçalhos listados em esses `srcs` ou no `hdrs` de qualquer regra listada em o argumento `deps`. Todos os arquivos `#include`d precisam ser mencionados no `srcs` desta regra ou da Atributo `hdrs` dos `cc_library()`s referenciados. O estilo recomendado é que os cabeçalhos associados a uma biblioteca sejam listados no atributo `hdrs` dessa biblioteca e os valores cabeçalhos associados às origens desta regra a serem listados em `srcs`. Consulte Verificação da inclusão de cabeçalho. para uma descrição mais detalhada. Se o nome de uma regra estiver em `srcs`, ela depende dela automaticamente. Se os `outs` da regra nomeada forem C ou C++ arquivos de origem, eles são compilados nessa regra. Se forem arquivos de biblioteca, eles serão vinculados. Tipos de arquivo `srcs` permitidos: Arquivos de origem C e C++: `.c`, `.cc`, `.cpp`. `.cxx`, `.c++` e `.C` Arquivos de cabeçalho C e C++: `.h`, `.hh`, `.hpp`, `.hxx`, `.inc`, `.inl`, `.H` Montador com pré-processador C: `.S` Arquivo: `.a`, `.pic.a` "Sempre vincular" biblioteca: `.lo`, `.pic.lo` Biblioteca compartilhada, com ou sem controle de versão: `.so`, `.so.version` Arquivo de objeto: `.o`, `.pic.o` e as regras que produzem esses arquivos. Extensões diferentes indicam linguagens de programação diferentes de acordo com a convenção de GCC.
`hdrs`	`List of labels; optional` A lista de arquivos principais publicados por a biblioteca seja incluída diretamente pelas fontes em regras dependentes. Esse é o local mais recomendado para declarar arquivos de cabeçalho que e descrever a interface da biblioteca. Esses cabeçalhos serão feitos disponíveis para inclusão pelas origens nesta regra ou em regras dependentes. Os cabeçalhos que não devem ser incluídos por um cliente desta biblioteca devem ser no atributo `srcs`, mesmo que estejam incluídos por um cabeçalho publicado. Consulte "Inclusão de cabeçalho verificação" para uma descrição mais detalhada.
`additional_compiler_inputs`	`List of labels; optional` Outros arquivos que você queira passar para a linha de comando do compilador, como sanitizer listas de ignorados, por exemplo. Os arquivos especificados aqui podem ser usados em copts com o função $(location).
`additional_linker_inputs`	`List of labels; optional` Transmita esses arquivos para o comando do vinculador do C++. Por exemplo, arquivos .res compilados do Windows podem ser fornecidos aqui para serem incorporados em o destino binário.
`alwayslink`	`Boolean; optional; default is False` Se for 1, qualquer binário que dependa (direta ou indiretamente) desse código C++ do Google Cloud vinculará todos os arquivos de objeto para os arquivos listados em `srcs`, mesmo que alguns não contenham símbolos referenciados pelo binário. Isso é útil se o código não for chamado explicitamente por código em o binário, por exemplo, caso seu código seja registrado para receber algum callback por algum serviço. Se o Alwayslink não funcionar com o VS 2017 no Windows, é devido a problema conhecido, faça upgrade do seu VS 2017 para a versão mais recente.
`copts`	`List of strings; optional` Adicione essas opções ao comando de compilação do C++. Sujeito à substituição "Make variables" e Tokenização de Bourne Shell. Cada string nesse atributo é adicionada a `COPTS` na ordem determinada antes de e compilar o destino binário. As sinalizações entram em vigor somente para compilar esse destino, não suas dependências, portanto, tenha cuidado com arquivos de cabeçalho incluídos em outros lugares. Todos os caminhos devem ser relativo ao espaço de trabalho, não ao pacote atual. Se o pacote declarar o objeto feature `no_copts_tokenization`: a tokenização de shell Bourne se aplica apenas a strings que consistem em uma única "marca" variável.
`defines`	`List of strings; optional` Lista de definições a serem adicionadas à linha de compilação. Sujeito a "Marca" variável e Tokenização de Bourne Shell. Cada string, que deve consistir em um único token de shell Bourne, tem `-D` como prefixo e foi adicionado à linha de comando de compilação desse destino. e todas as regras que dependem dele. Tenha muito cuidado, pois isso pode ter efeitos mais amplos. Em caso de dúvida, adicione valores definidos ao `local_defines`.
`implementation_deps`	`List of labels; optional` A lista de outras bibliotecas de que o destino da biblioteca depende. Remover de `deps`, os cabeçalhos e os caminhos de inclusão dessas bibliotecas (e de todas transitives) são usadas apenas para compilação dessa biblioteca, e não para bibliotecas que dependerem disso. As bibliotecas especificadas com `implementation_deps` ainda estão vinculadas na binários que dependem dessa biblioteca. Por enquanto, o uso é limitado a cc_libraries e protegido pela sinalização. `--experimental_cc_implementation_deps`:
`include_prefix`	`String; optional` O prefixo a ser adicionado aos caminhos dos cabeçalhos desta regra. Quando definido, os cabeçalhos no atributo `hdrs` dessa regra podem ser acessados "at" é o valor desse atributo anexado ao caminho relativo ao repositório. O prefixo no atributo `strip_include_prefix` é removido antes deste é adicionado.
`includes`	`List of strings; optional` Lista de diretórios de inclusão a serem adicionados à linha de compilação. Sujeito à substituição "Make variables". Cada string é prefixada com `-isystem` e adicionada a `COPTS`. Ao contrário de COPTS, essas sinalizações são adicionadas para esta regra e todas as regras que dependem dele. Observação: não são as regras das quais ele depende. Tenha tenha muito cuidado, já que isso pode ter efeitos mais amplos. Em caso de dúvida, adicione "-Eu" para COPTS. Os cabeçalhos precisam ser adicionados a srcs ou hdrs; caso contrário, eles não estarão disponíveis para os quando a compilação está no modo sandbox (o padrão).
`linkopts`	`List of strings; optional` Adicione estas sinalizações ao comando do vinculador C++. Sujeito a "Marca" variável, tokenização de shell Bourne e expansão de rótulos. Cada string nesse atributo é adicionada a `LINKOPTS` antes ao vincular o destino binário. Cada elemento dessa lista que não começa com `$` ou `-` é foi considerado o rótulo de um destino em `deps`. A uma lista de arquivos gerados por esse destino é anexada ao vinculador; . Um erro será informado se o rótulo for inválido ou for não declarado em `deps`.
`linkstamp`	`Label; optional` Compila e vincula simultaneamente o arquivo de origem C++ especificado ao arquivo binário. Esse truque é necessário para introduzir o carimbo de data/hora informações em binários, se compilamos o arquivo de origem para um arquivo de objeto da maneira normal, o carimbo de data/hora estaria incorreto. Uma compilação de linkstamp pode não incluir nenhum conjunto específico de do compilador e, portanto, não podem depender de nenhuma cabeçalho, opção do compilador ou outra variável de build. Essa opção só é necessária pacote `base`.
`linkstatic`	`Boolean; optional; default is False` Para `cc_binary` e `cc_test`: vincular o binário na estática modo Para `cc_library.linkstatic`: confira abaixo. Por padrão, essa opção fica ativada para `cc_binary` e desativada para o restante. Se ativada e for um binário ou teste, essa opção manda a ferramenta de build vincular Sempre que possível, `.a`s em vez de `.so` para bibliotecas do usuário. Algumas bibliotecas do sistema ainda podem ser vinculadas dinamicamente, assim como as bibliotecas para as quais não há uma biblioteca estática. O executável resultante ainda vai ser dinamicamente vinculados, portanto, são apenas quase estáticos. Existem três maneiras diferentes de vincular um executável: STATIC com recurso full_static_link, em que tudo é vinculado estaticamente. Por exemplo: "`gcc -static foo.o libbar.a libbaz.a -lm`". Para ativar esse modo, especifique `fully_static_link` no `features`. STATIC, no qual todas as bibliotecas do usuário são vinculadas estaticamente (se uma está disponível), mas quando as bibliotecas do sistema (exceto bibliotecas de ambiente de execução C/C++) são vinculadas dinamicamente, por exemplo, "`gcc foo.o libfoo.a libbaz.a -lm`". Para ativar esse modo, especifique `linkstatic=True`. DYNAMIC, no qual todas as bibliotecas são vinculadas dinamicamente (se uma versão dinâmica é disponíveis), por exemplo, "`gcc foo.o libfoo.so libbaz.so -lm`". Para ativar esse modo, especifique `linkstatic=False`. O atributo `linkstatic` tem um significado diferente se usado em uma regra `cc_library()`. Para uma biblioteca C++, `linkstatic=True` indica que apenas a vinculação estática é permitida, portanto, nenhum `.so` será produzido. linkstatic=False faz não impede a criação de bibliotecas estáticas. O atributo serve para controlar criação de bibliotecas dinâmicas. Se for `linkstatic=False`, a ferramenta de build criará links simbólicos para dependem das bibliotecas compartilhadas na área de `*.runfiles`.
`local_defines`	`List of strings; optional` Lista de definições a serem adicionadas à linha de compilação. Sujeito a "Marca" variável e Tokenização de Bourne Shell. Cada string, que deve consistir em um único token de shell Bourne, tem `-D` como prefixo e foi adicionado à linha de comando de compilação desse destino. mas não aos dependentes.
`nocopts`	`String; optional` As opções de correspondência foram removidas do comando de compilação em C++. Sujeito a "Marca" variável. O valor desse atributo é interpretado como uma expressão regular. Qualquer `COPTS` preexistente que corresponda a essa expressão regular (incluindo os valores explicitamente especificados no atributo copts da regra) serão removidos dos `COPTS` para compilar esta regra. Esse atributo raramente será necessário.
`strip_include_prefix`	`String; optional` O prefixo a ser removido dos caminhos dos cabeçalhos desta regra. Quando definido, os cabeçalhos no atributo `hdrs` dessa regra podem ser acessados no caminho com esse prefixo cortado. Se for um caminho relativo, ele será considerado como relativo ao pacote. Se for absoluta, ela é entendida como um caminho relativo ao repositório. O prefixo no atributo `include_prefix` é adicionado depois que esse prefixo é descascada.
`textual_hdrs`	`List of labels; optional` A lista de arquivos principais publicados por a biblioteca seja incluída textualmente pelas fontes em regras dependentes. Esse é o local para declarar os arquivos de cabeçalho que não podem ser compilados sozinhos. ou seja, eles sempre precisam ser incluídos textualmente por outros arquivos-fonte para criar versões válidas o código-fonte.
`win_def_file`	`Label; optional` O arquivo DEF do Windows a ser passado para o vinculador. Esse atributo só deve ser usado quando o Windows for a plataforma de destino. Ele pode ser usado para exportar símbolos durante a vinculação de uma biblioteca compartilhada.

cc_proto_library

cc_proto_library(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

cc_proto_library gera código C++ de arquivos .proto.

deps precisa apontar para regras proto_library.

Exemplo:

cc_library(
    name = "lib",
    deps = [":foo_cc_proto"],
)

cc_proto_library(
    name = "foo_cc_proto",
    deps = [":foo_proto"],
)

proto_library(
    name = "foo_proto",
)

Argumentos

Atributos

name

Name; required

Um nome exclusivo para o destino.

deps

List of labels; optional

Lista de proto_library para gerar código C++.

fdo_prefetch_hints

fdo_prefetch_hints(name, compatible_with, deprecation, distribs, features, licenses, profile, restricted_to, tags, target_compatible_with, testonly, visibility)

Representa um perfil de dicas de pré-busca do FDO que está no espaço de trabalho ou em um caminho absoluto. Exemplos:

fdo_prefetch_hints(
    name = "hints",
    profile = "//path/to/hints:profile.afdo",
)

fdo_profile(
  name = "hints_abs",
  absolute_path_profile = "/absolute/path/profile.afdo",
)

Argumentos

Atributos

name

Name; required

Um nome exclusivo para o destino.

profile

Label; optional

Identificador do perfil de dicas. O arquivo de dicas tem a extensão .afdo O rótulo também pode apontar para uma regra fdo_absolute_path_profile.

fdo_profile

fdo_profile(name, absolute_path_profile, compatible_with, deprecation, distribs, features, licenses, profile, proto_profile, restricted_to, tags, target_compatible_with, testonly, visibility)

Representa um perfil do FDO que está no espaço de trabalho ou em um caminho absoluto especificado. Exemplos:

fdo_profile(
    name = "fdo",
    profile = "//path/to/fdo:profile.zip",
)

fdo_profile(
  name = "fdo_abs",
  absolute_path_profile = "/absolute/path/profile.zip",
)

Argumentos

Atributos
`name`	`Name; required` Um nome exclusivo para o destino.
`absolute_path_profile`	`String; optional` Caminho absoluto para o perfil do FDO. O arquivo FDO só pode ter a extensão .afdo.
`profile`	`Label; optional` Rótulo do perfil do FDO ou uma regra que o gera. O arquivo FDO pode ter um dos seguintes extensões: .profraw para perfis de LLVM não indexados, .profdata para LLVM indexados perfil, .zip que contenha um perfil de perfil LLVM, .afdo para perfil AutoFDO, .xfdo para perfil XBinary. O rótulo também pode apontar para uma regra fdo_absolute_path_profile.
`proto_profile`	`Label; optional` Marcador do perfil protobuf.

propeller_optimize

propeller_optimize(name, compatible_with, deprecation, distribs, features, ld_profile, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

Representa um perfil de otimização de hélice no espaço de trabalho. Exemplo:

propeller_optimize(
    name = "layout",
    cc_profile = "//path:cc_profile.txt",
    ld_profile = "//path:ld_profile.txt"
)

propeller_optimize(
    name = "layout_absolute",
    absolute_cc_profile = "/absolute/cc_profile.txt",
    absolute_ld_profile = "/absolute/ld_profile.txt"
)

Argumentos

Atributos

name

Name; required

Um nome exclusivo para o destino.

ld_profile

Label; optional

Rótulo do perfil transmitido para a ação de vinculação. Este arquivo tem a extensão .txt.

cc_test

cc_test(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, includes, licenses, linkopts, linkstatic, local, local_defines, malloc, nocopts, restricted_to, shard_count, size, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility, win_def_file)

Argumentos

Atributos
`name`	`Name; required` Um nome exclusivo para o destino.
`deps`	`List of labels; optional` A lista de outras bibliotecas a serem vinculadas ao destino binário. Eles podem ser `cc_library` ou `objc_library`. de destino.
`srcs`	`List of labels; optional` A lista de arquivos C e C++ processados para criar o destino. Estes são arquivos de origem e de cabeçalho em C/C++, não gerados (origem normal ou gerados. Todos os arquivos `.cc`, `.c` e `.cpp` serão ser compilado. Podem ser arquivos gerados: se um arquivo nomeado estiver no o `outs` de alguma outra regra, esta regra dependerão automaticamente da outra regra. Um arquivo `.h` não será compilado, mas estará disponível para inclusão por origens nesta regra. Tanto `.cc` quanto Os arquivos `.h` podem incluir diretamente os cabeçalhos listados em esses `srcs` ou no `hdrs` de qualquer regra listada em o argumento `deps`. Todos os arquivos `#include`d precisam ser mencionados no `srcs` desta regra ou da Atributo `hdrs` dos `cc_library()`s referenciados. O estilo recomendado é que os cabeçalhos associados a uma biblioteca sejam listados no atributo `hdrs` dessa biblioteca e os valores cabeçalhos associados às origens desta regra a serem listados em `srcs`. Consulte Verificação da inclusão de cabeçalho. para uma descrição mais detalhada. Se o nome de uma regra estiver em `srcs`, ela depende dela automaticamente. Se os `outs` da regra nomeada forem C ou C++ arquivos de origem, eles são compilados nessa regra. Se forem arquivos de biblioteca, eles serão vinculados. Tipos de arquivo `srcs` permitidos: Arquivos de origem C e C++: `.c`, `.cc`, `.cpp`. `.cxx`, `.c++` e `.C` Arquivos de cabeçalho C e C++: `.h`, `.hh`, `.hpp`, `.hxx`, `.inc`, `.inl`, `.H` Montador com pré-processador C: `.S` Arquivo: `.a`, `.pic.a` "Sempre vincular" biblioteca: `.lo`, `.pic.lo` Biblioteca compartilhada, com ou sem controle de versão: `.so`, `.so.version` Arquivo de objeto: `.o`, `.pic.o` e as regras que produzem esses arquivos. Extensões diferentes indicam linguagens de programação diferentes de acordo com a convenção de GCC.
`additional_linker_inputs`	`List of labels; optional` Transmita esses arquivos para o comando do vinculador do C++. Por exemplo, arquivos .res compilados do Windows podem ser fornecidos aqui para serem incorporados em o destino binário.
`copts`	`List of strings; optional` Adicione essas opções ao comando de compilação do C++. Sujeito à substituição "Make variables" e Tokenização de Bourne Shell. Cada string nesse atributo é adicionada a `COPTS` na ordem determinada antes de e compilar o destino binário. As sinalizações entram em vigor somente para compilar esse destino, não suas dependências, portanto, tenha cuidado com arquivos de cabeçalho incluídos em outros lugares. Todos os caminhos devem ser relativo ao espaço de trabalho, não ao pacote atual. Se o pacote declarar o objeto feature `no_copts_tokenization`: a tokenização de shell Bourne se aplica apenas a strings que consistem em uma única "marca" variável.
`defines`	`List of strings; optional` Lista de definições a serem adicionadas à linha de compilação. Sujeito a "Marca" variável e Tokenização de Bourne Shell. Cada string, que deve consistir em um único token de shell Bourne, tem `-D` como prefixo e foi adicionado à linha de comando de compilação desse destino. e todas as regras que dependem dele. Tenha muito cuidado, pois isso pode ter efeitos mais amplos. Em caso de dúvida, adicione valores definidos ao `local_defines`.
`includes`	`List of strings; optional` Lista de diretórios de inclusão a serem adicionados à linha de compilação. Sujeito à substituição "Make variables". Cada string é prefixada com `-isystem` e adicionada a `COPTS`. Ao contrário de COPTS, essas sinalizações são adicionadas para esta regra e todas as regras que dependem dele. Observação: não são as regras das quais ele depende. Tenha tenha muito cuidado, já que isso pode ter efeitos mais amplos. Em caso de dúvida, adicione "-Eu" para COPTS. Os cabeçalhos precisam ser adicionados a srcs ou hdrs; caso contrário, eles não estarão disponíveis para os quando a compilação está no modo sandbox (o padrão).
`linkopts`	`List of strings; optional` Adicione estas sinalizações ao comando do vinculador C++. Sujeito a "Marca" variável, tokenização de shell Bourne e expansão de rótulos. Cada string nesse atributo é adicionada a `LINKOPTS` antes ao vincular o destino binário. Cada elemento dessa lista que não começa com `$` ou `-` é foi considerado o rótulo de um destino em `deps`. A uma lista de arquivos gerados por esse destino é anexada ao vinculador; . Um erro será informado se o rótulo for inválido ou for não declarado em `deps`.
`linkstatic`	`Boolean; optional; default is False` Para `cc_binary` e `cc_test`: vincular o binário na estática modo Para `cc_library.linkstatic`: confira abaixo. Por padrão, essa opção fica ativada para `cc_binary` e desativada para o restante. Se ativada e for um binário ou teste, essa opção manda a ferramenta de build vincular Sempre que possível, `.a`s em vez de `.so` para bibliotecas do usuário. Algumas bibliotecas do sistema ainda podem ser vinculadas dinamicamente, assim como as bibliotecas para as quais não há uma biblioteca estática. O executável resultante ainda vai ser dinamicamente vinculados, portanto, são apenas quase estáticos. Existem três maneiras diferentes de vincular um executável: STATIC com recurso full_static_link, em que tudo é vinculado estaticamente. Por exemplo: "`gcc -static foo.o libbar.a libbaz.a -lm`". Para ativar esse modo, especifique `fully_static_link` no `features`. STATIC, no qual todas as bibliotecas do usuário são vinculadas estaticamente (se uma está disponível), mas quando as bibliotecas do sistema (exceto bibliotecas de ambiente de execução C/C++) são vinculadas dinamicamente, por exemplo, "`gcc foo.o libfoo.a libbaz.a -lm`". Para ativar esse modo, especifique `linkstatic=True`. DYNAMIC, no qual todas as bibliotecas são vinculadas dinamicamente (se uma versão dinâmica é disponíveis), por exemplo, "`gcc foo.o libfoo.so libbaz.so -lm`". Para ativar esse modo, especifique `linkstatic=False`. O atributo `linkstatic` tem um significado diferente se usado em uma regra `cc_library()`. Para uma biblioteca C++, `linkstatic=True` indica que apenas a vinculação estática é permitida, portanto, nenhum `.so` será produzido. linkstatic=False faz não impede a criação de bibliotecas estáticas. O atributo serve para controlar criação de bibliotecas dinâmicas. Se for `linkstatic=False`, a ferramenta de build criará links simbólicos para dependem das bibliotecas compartilhadas na área de `*.runfiles`.
`local_defines`	`List of strings; optional` Lista de definições a serem adicionadas à linha de compilação. Sujeito a "Marca" variável e Tokenização de Bourne Shell. Cada string, que deve consistir em um único token de shell Bourne, tem `-D` como prefixo e foi adicionado à linha de comando de compilação desse destino. mas não aos dependentes.
`malloc`	`Label; optional; default is @bazel_tools//tools/cpp:malloc` Substitui a dependência padrão em Malloc. Por padrão, os binários C++ são vinculados a `//tools/cpp:malloc`, que é uma biblioteca vazia, de modo que o binário acaba usando a libc Malloc. Esse rótulo precisa se referir a um `cc_library`. Se a compilação for para uma versão que não seja C++ regra, essa opção não terá efeito. O valor desse atributo é ignorado se `linkshared=True` é especificado.
`nocopts`	`String; optional` As opções de correspondência foram removidas do comando de compilação em C++. Sujeito a "Marca" variável. O valor desse atributo é interpretado como uma expressão regular. Qualquer `COPTS` preexistente que corresponda a essa expressão regular (incluindo os valores explicitamente especificados no atributo copts da regra) serão removidos dos `COPTS` para compilar esta regra. Esse atributo raramente será necessário.
`stamp`	`Integer; optional; default is 0` Define se as informações da versão serão codificadas no binário. Valores possíveis: `stamp = 1`: sempre inclua as informações do build no binário, mesmo em `--nostamp` builds. Este deve ser evitada, já que ela pode eliminar o armazenamento em cache remoto dos binário e qualquer ação downstream que dependa dele. `stamp = 0`: sempre substitui as informações do build por valores constantes. Isso oferece um bom armazenamento em cache dos resultados da compilação. `stamp = -1`: a incorporação de informações do build é controlada pelo sinalização `--[no]stamp`. Os binários carimbos não são recriados, a menos que as dependências deles mudem.
`win_def_file`	`Label; optional` O arquivo DEF do Windows a ser passado para o vinculador. Esse atributo só deve ser usado quando o Windows for a plataforma de destino. Ele pode ser usado para exportar símbolos durante a vinculação de uma biblioteca compartilhada.

cc_toolchain

cc_toolchain(name, all_files, ar_files, as_files, compatible_with, compiler, compiler_files, compiler_files_without_includes, coverage_files, cpu, deprecation, distribs, dwp_files, dynamic_runtime_lib, exec_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, restricted_to, static_runtime_lib, strip_files, supports_header_parsing, supports_param_files, tags, target_compatible_with, testonly, toolchain_config, toolchain_identifier, visibility)

Representa um conjunto de ferramentas C++.

Essa regra é responsável por:

Coletar todos os artefatos necessários para que as ações C++ sejam executadas. Isso é feito pela atributos como all_files, compiler_files, linker_files ou outros atributos terminados em _files). São geralmente são grupos de arquivos que contêm todos os arquivos necessários.
Geração de linhas de comando corretas para ações C++. Para isso, usamos CcToolchainConfigInfo provedor (detalhes abaixo).

Use o atributo toolchain_config para configurar o conjunto de ferramentas do C++. Consulte também este página para ver a documentação elaborada sobre a configuração do conjunto de ferramentas C++ e a seleção do conjunto de ferramentas.

Usar tags = ["manual"] para impedir que os conjuntos de ferramentas sejam criados e configurados desnecessariamente ao invocar bazel build //...

Argumentos

Atributos
`name`	`Name; required` Um nome exclusivo para o destino.
`all_files`	`Label; required` Coleção de todos os artefatos cc_Dataset. Esses artefatos serão adicionados como entradas regras_cc (exceto as ações que usam conjuntos mais precisos de artefatos dos atributos abaixo). Bazel supõe que `all_files` é um superconjunto de todos os outros atributos que fornecem artefatos (por exemplo, a compilação do linktamp precisa ser compilada e arquivos de link, o que leva `all_files`). Isso é o que `cc_toolchain.files` contém, e é usado por todos os Starlark regras usando o conjunto de ferramentas C++.
`ar_files`	`Label; optional` Coleção de todos os artefatos cc_Dataset necessários para ações de arquivamento.
`as_files`	`Label; optional` Coleção de todos os artefatos cc_Dataset necessários para ações de montagem.
`compiler`	`String; optional; nonconfigurable` Obsoleto. Use o atributo `toolchain_identifier`. Vai ser um ambiente autônomo depois Migração da CROSSTOOL para o Starlark , e será removido por 7075 (link em inglês). Quando definida, ela será usada para executar a seleção crosstool_config.Dataset. Levará precedência sobre a opção --cpu Bazel.
`compiler_files`	`Label; required` Coleção de todos os artefatos cc_Dataset necessários para ações de compilação.
`compiler_files_without_includes`	`Label; optional` Coleção de todos os artefatos cc_Dataset necessários para ações de compilação nos casos em que há suporte para a descoberta de entrada (no momento somente do Google).
`coverage_files`	`Label; optional` Coleção de todos os artefatos cc_Dataset necessários para ações de cobertura. Se não for especificado, all_files são usados.
`cpu`	`String; optional; nonconfigurable` Obsoleto. Em vez disso, use o atributo "conjunto de ferramentas_identificador". Será um ambiente autônomo após Migração da CROSSTOOL para o Starlark , e será removido por 7075 (link em inglês). Quando definida, ela será usada para executar a seleção crosstool_config.Dataset. Levará precedência sobre a opção --cpu Bazel.
`dwp_files`	`Label; required` Coleção de todos os artefatos cc_dataset necessários para ações dwp.
`dynamic_runtime_lib`	`Label; optional` Artefato de biblioteca dinâmica para a biblioteca de ambiente de execução C++ (por exemplo, libstdc++.so). Vai ser usado quando "static_link_cpp_runtimes" está ativado e estamos vinculando dependências de maneira dinâmica.
`exec_transition_for_inputs`	`Boolean; optional; default is True` Defina como "True" para criar todas as entradas de arquivo para cc_dataset para a plataforma "exec". em vez de ter transição (ou seja, plataforma segmentada por padrão).
`libc_top`	`Label; optional` Uma coleção de artefatos para a libc transmitidos como entradas para ações de compilação/vinculação.
`linker_files`	`Label; required` Coleção de todos os artefatos cc_Dataset necessários para ações de vinculação.
`module_map`	`Label; optional` Artefato de mapa de módulo a ser usado para builds modulares.
`objcopy_files`	`Label; required` Coleção de todos os artefatos cc_Dataset necessários para ações objcopy.
`static_runtime_lib`	`Label; optional` Artefato de biblioteca estática para a biblioteca de ambiente de execução C++ (por exemplo, libstdc++.a). Vai ser usado quando "static_link_cpp_runtimes" está ativado e estamos vinculando dependências estaticamente.
`strip_files`	`Label; required` Coleção de todos os artefatos cc_Dataset necessários para ações de remoção.
`supports_header_parsing`	`Boolean; optional; default is False` Defina como verdadeiro quando cc_Dataset for compatível com ações de análise de cabeçalho.
`supports_param_files`	`Boolean; optional; default is True` Defina como "True" quando "cc_dataset" for compatível com o uso de arquivos de parâmetros para ações de vinculação.
`toolchain_config`	`Label; required` A etiqueta da regra que fornece `cc_toolchain_config_info`.
`toolchain_identifier`	`String; optional; nonconfigurable` O identificador usado para corresponder esse cc_Dataset com o crosstool_config.toolchain. Até que o problema 5380 seja corrigido essa é a forma recomendada de associar `cc_toolchain` `CROSSTOOL.toolchain`. Ela vai ser substituída por `toolchain_config`. atributo (#5380).

cc_toolchain_suite

cc_toolchain_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

Representa uma coleção de conjuntos de ferramentas C++.

Essa regra é responsável por:

coletar todos os conjuntos de ferramentas de C++ relevantes;
Como selecionar um conjunto de ferramentas dependendo das opções --cpu e --compiler passados para o Bazel.

Consulte também este página para ver a documentação elaborada sobre a configuração do conjunto de ferramentas C++ e a seleção do conjunto de ferramentas.

Argumentos

Atributos

name

Name; required

Um nome exclusivo para o destino.

toolchains

Dictionary mapping strings to labels; required; nonconfigurable

Um mapa de "<cpu>" ou "<cpu>|<compiler>" strings para um rótulo cc_toolchain. "<CPU>" será usado quando apenas --cpu é passado para o Bazel e "<cpu>|<compiler>" será usado quando --cpu e --compiler são transmitidos para o Bazel. Exemplo:

          cc_toolchain_suite(
            name = "toolchain",
            toolchains = {
              "piii|gcc": ":my_cc_toolchain_for_piii_using_gcc",
              "piii": ":my_cc_toolchain_for_piii_using_default_compiler",
            },
          )