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

Esta página foi traduzida pela API Cloud Translation.

Configuração do conjunto de ferramentas C++

Relatar um problema Conferir código-fonte Por noite · 7,4 do Google. 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Visão geral

Para invocar o compilador com as opções corretas, o Bazel precisa de alguns conhecimentos sobre os componentes internos do compilador, como diretórios "include" e flags importantes. Em outras palavras, o Bazel precisa de um modelo simplificado do compilador para entender funcionamento.

O Bazel precisa saber o seguinte:

Se o compilador é compatível com thinLTO, módulos, vinculação dinâmica ou PIC. (código independente do posicionamento).
Caminhos para as ferramentas necessárias, como gcc, ld, ar, objcopy e assim por diante.
Os diretórios são incluídos no sistema integrado. O Bazel precisa desses arquivos para validar que todos os cabeçalhos que foram incluídos no arquivo de origem foram adequadamente declarados em o arquivo BUILD.
O sysroot padrão.
Quais sinalizações usar para compilação, vinculação e arquivamento.
Quais flags usar para os modos de compilação com suporte (opt, dbg, fastbuild).
Fazer com que as variáveis sejam especificamente exigidas pelo compilador.

Se o compilador oferecer suporte a várias arquiteturas, o Bazel vai precisar configurar separadamente.

CcToolchainConfigInfo é um provedor que fornece o nível necessário de granularidade para configurar o comportamento das regras C++ do Bazel. Por padrão, o Bazel configura automaticamente CcToolchainConfigInfo para o build, mas você pode fazer isso manualmente. Para isso, você precisa de uma regra do Starlark que forneça o CcToolchainConfigInfo e aponte o atributo toolchain_config do cc_toolchain para a regra. É possível criar o CcToolchainConfigInfo chamando cc_common.create_cc_toolchain_config_info(). Você pode encontrar construtores do Starlark para todas as estruturas necessárias no processo em @rules_cc//cc:cc_toolchain_config_lib.bzl.

Quando um destino C++ entra na fase de análise, o Bazel seleciona cc_toolchain destino com base no arquivo BUILD e extrai o provedor CcToolchainConfigInfo do destino especificado no cc_toolchain.toolchain_config. O destino cc_toolchain transmite essas informações ao destino C++ por meio de um CcToolchainProvider.

Por exemplo, uma ação de compilação ou link, instanciada por uma regra como cc_binary ou cc_library, precisa das seguintes informações:

O compilador ou vinculador a ser usado
Flags de linha de comando para o compilador/vinculador
Sinalizações de configuração transmitidas pelas opções --copt/--linkopt
Variáveis de ambiente
Artefatos necessários no sandbox em que a ação é executada

Todas as informações acima, exceto os artefatos exigidos no sandbox, são especificado no alvo Starlark para o qual o cc_toolchain aponta.

Os artefatos que serão enviados ao sandbox são declarados no cc_toolchain. alvo. Por exemplo, com o atributo cc_toolchain.linker_files, é possível especificar o binário do vinculador e as bibliotecas do conjunto de ferramentas a serem enviadas para o sandbox.

Seleção de conjunto de ferramentas

A lógica de seleção do conjunto de ferramentas opera da seguinte maneira:

O usuário especifica um destino cc_toolchain_suite no arquivo BUILD e aponta o Bazel para o destino usando a opção --crosstool_top.
O destino cc_toolchain_suite faz referência a vários conjuntos de ferramentas. O os valores das flags --cpu e --compiler determinam qual dessas conjunto de ferramentas for selecionado, com base apenas no valor da sinalização --cpu ou com base em um valor de --cpu | --compiler conjunto. O processo de seleção é da seguinte forma:
- Se a opção --compiler for especificada, o Bazel selecionará a entrada correspondente do elemento cc_toolchain_suite.toolchains com --cpu | --compiler. Se o Bazel não encontrar uma entrada correspondente, ele vai gerar um erro.
- Se a opção --compiler não for especificada, o Bazel vai selecionar a entrada correspondente do atributo cc_toolchain_suite.toolchains com apenas --cpu.
- Se nenhuma flag for especificada, o Bazel vai inspecionar o sistema host e selecionar um valor --cpu com base nas descobertas. Consulte o código do mecanismo de inspeção.

Depois que uma cadeia de ferramentas é selecionada, os objetos feature e action_config correspondentes na regra Starlark governam a configuração do build, ou seja, os itens descritos mais adiante. Essas mensagens permitem a implementação de recursos C++ completos no Bazel sem modificar a Binário do Bazel. As regras do C++ oferecem suporte a várias ações exclusivas documentadas em detalhes no código-fonte do Bazel.

Recursos

Um atributo é uma entidade que requer flags de linha de comando, ações restrições no ambiente de execução ou alterações nas dependências. Um recurso pode ser algo tão simples quanto permitir que arquivos BUILD selecionem configurações de flags, como treat_warnings_as_errors, ou interajam com as regras C++ e incluam novas ações de compilação e entradas na compilação, como header_modules ou thin_lto.

Idealmente, CcToolchainConfigInfo contém uma lista de atributos, em que cada O recurso consiste em um ou mais grupos de sinalizações, cada um definindo uma lista de sinalizações que se aplicam a ações específicas do Bazel.

Um recurso é especificado por nome, o que permite o desacoplamento completo da configuração de regra do Starlark das versões do Bazel. Em outras palavras, uma versão do Bazel não afetam o comportamento das configurações de CcToolchainConfigInfo, desde que essas não exigem o uso de novos recursos.

Um recurso é ativado de uma das seguintes maneiras:

O campo enabled do recurso está definido como true.
o Bazel ou o proprietário da regra a ativarem explicitamente.
O usuário ativa essa opção usando a opção --feature do Bazel ou o atributo de regra features.

Os recursos podem ter interdependências, depender de sinalizações de linha de comando, configurações de arquivo BUILD e outras variáveis.

Relações entre atributos

As dependências normalmente são gerenciadas diretamente com o Bazel, que simplesmente aplica os requisitos e gerencia conflitos intrínsecos à natureza dos atributos definidos no build. A especificação do conjunto de ferramentas permite análises mais granulares restrições para uso diretamente dentro da regra Starlark que regem os atributos suporte e expansão. São eles:

Restrição	Descrição
requires = [ feature_set (features = [ 'feature-name-1', 'feature-name-2' ]), ]	Nível do recurso. O recurso só é compatível se os recursos necessários especificados estiverem ativados. Por exemplo, quando um recurso só tem suporte em certos modos de build (`opt`, `dbg` ou `fastbuild`). Se "require" tiver vários elementos "feature_set" o recurso terá suporte se algum dos atributos "feature_set" for atendido (quando todos os recursos especificados estiverem ativados).
implies = ['feature']	Nível do recurso. Esse recurso implica os recursos especificados. Ativar um recurso também ativa implicitamente todos os recursos implícitos nele, ou seja, ele funciona recursivamente. Também fornece a capacidade de fatorar subconjuntos comuns de funcionalidade de um conjunto de recursos, como as partes comuns de desinfetantes. Implícita recursos não podem ser desativados.
provides = ['feature']	Nível do recurso. Indica que esse atributo é um dos vários mutuamente recursos alternativos exclusivos. Por exemplo, todos os desinfetantes poderiam especifique `provides = ["sanitizer"]`. Isso melhora o tratamento de erros porque lista as alternativas caso o usuário pergunte dois ou mais recursos mutuamente exclusivos de uma só vez.
with_features = [ with_feature_set( features = ['feature-1'], not_features = ['feature-2'], ), ]	Nível do conjunto de sinalizações. Um recurso pode especificar vários conjuntos de sinalizações com vários. Quando `with_features` é especificado, a sinalização definida só se expande ao comando de build se houver pelo menos um objeto `with_feature_set` para a qual todos os atributos no conjunto `features` especificado estão ativados e todos os recursos especificados em `not_features` definido estão desativados. Se `with_features` não for especificado, a sinalização definida será aplicada incondicionalmente para cada ação especificada.

Ações

As ações oferecem a flexibilidade de modificar as circunstâncias que uma ação executa sem presumir como a ação será executada. Um action_config especifica o binário de ferramenta que uma ação invoca, enquanto um feature especifica a configuração (sinalizações) que determinam como a ferramenta se comporta quando a ação é invocada.

Os recursos fazem referência a ações para indicar quais ações do Bazel elas afetam, já que as ações podem modificar o gráfico de ações do Bazel. O O provedor CcToolchainConfigInfo contém ações que têm flags e ferramentas associados a elas, como c++-compile. As flags são atribuídas a cada ação associando-as a um recurso.

Cada nome de ação representa um único tipo de ação realizada pelo Bazel, como compilação ou vinculação. Há, no entanto, uma relação de muitos para um entre e tipos de ação do Bazel, em que um tipo de ação do Bazel se refere a uma classe Java. que implementa uma ação (como CppCompileAction). Especificamente, o "ações do assembler" e "ações do compilador" na tabela abaixo são CppCompileAction, e as ações de vinculação são CppLinkAction.

Ações do assembler

Ação	Descrição
`preprocess-assemble`	Monte com o pré-processamento. Normalmente, para arquivos `.S`.
`assemble`	Monte sem pré-processamento. Normalmente, para arquivos `.s`.

Ações do compilador

Ação	Descrição
`cc-flags-make-variable`	Propaga `CC_FLAGS` para as regras gerais.
`c-compile`	Compile como C.
`c++-compile`	Compilar como C++.
`c++-header-parsing`	Execute o analisador do compilador em um arquivo de cabeçalho para garantir que ele seja independente, porque, caso contrário, ele vai produzir erros de compilação. Aplica-se apenas para conjuntos de ferramentas compatíveis com módulos.

Ações do link

Ação	Descrição
`c++-link-dynamic-library`	Vincule uma biblioteca compartilhada que contenha todas as dependências dela.
`c++-link-nodeps-dynamic-library`	Vincule uma biblioteca compartilhada que contenha apenas fontes `cc_library`.
`c++-link-executable`	Vincule uma biblioteca final pronta para uso.

Ações de RA

As ações de RA montam arquivos de objetos em bibliotecas (arquivos .a) via ar. e codificar algumas semânticas nele.

Ação	Descrição
`c++-link-static-library`	Crie uma biblioteca estática (arquivo).

Ações da LTO

Ação	Descrição
`lto-backend`	Ação ThinLTO compilando bitcodes em objetos nativos.
`lto-index`	Ação ThinLTO gerando índice global.

Como usar action_config

O action_config é uma estrutura Starlark que descreve uma ação do Bazel especificando a ferramenta (binária) a ser invocada durante a ação e os conjuntos de flags, definidos por recursos. Essas sinalizações aplicam restrições execução.

O construtor action_config() tem os seguintes parâmetros:

Attribute	Descrição
`action_name`	A ação do Bazel a que esta ação corresponde. O Bazel usa esse atributo para descobrir a ferramenta por ação e a execução e cumprimento de requisitos regulatórios.
`tools`	O executável a ser invocado. A ferramenta aplicada à ação será a primeira ferramenta na lista com um conjunto de atributos que corresponde ao atributo configuração do Terraform. É preciso fornecer o valor padrão.
`flag_sets`	Uma lista de flags que se aplica a um grupo de ações. O mesmo que em .
`env_sets`	Uma lista de restrições de ambiente que se aplicam a um grupo de ações. O mesmo que para um recurso.

Um action_config pode exigir e implicar outros recursos e action_configs, conforme determinado pelas relacionamentos de recursos descritos anteriormente. Esse comportamento é semelhante ao de um atributo.

Os dois últimos atributos são redundantes em relação aos atributos correspondentes nos recursos e são incluídos porque algumas ações do Bazel exigem flags ou variáveis de ambiente específicas. O objetivo é evitar pares action_config+feature desnecessários. Normalmente, é preferível compartilhar um único recurso em várias action_configs.

Não é possível definir mais de um action_config com o mesmo action_name na mesma cadeia de ferramentas. Isso evita ambiguidades nos caminhos de ferramentas e reforça a intenção por trás de action_config, que as propriedades de uma ação sejam claramente descritas em um único lugar na cadeia de ferramentas.

Uso do construtor de ferramentas

Um action_config pode especificar um conjunto de ferramentas pelo parâmetro tools. O construtor tool() aceita os seguintes parâmetros:

Campo	Descrição
`path`	Caminho para a ferramenta em questão (relativo ao local atual).
`with_features`	uma lista de conjuntos de atributos em que pelo menos um deles precisa ser atendido. para essa ferramenta aplicar.

Para um determinado action_config, apenas um tool aplica o caminho da ferramenta e os requisitos de execução à ação do Bazel. Uma ferramenta é selecionada iterando pelo atributo tools em um action_config até que uma ferramenta com um conjunto with_feature correspondente à configuração do recurso seja encontrada. Consulte Relacionamentos de recursos mais acima nesta página para mais informações. Você deve encerrar suas listas de ferramentas com um padrão ferramenta que corresponde a uma configuração de atributo vazia.

Exemplo de uso

Recursos e ações podem ser usados juntos para implementar ações do Bazel com semânticas variadas de várias plataformas. Por exemplo, a geração de símbolos de depuração O macOS exige a geração de símbolos na ação de compilação e, em seguida, a invocação de um ferramenta especializada durante a ação do link para criar um arquivo Dsym compactado e e descompactar esse arquivo para produzir o pacote do aplicativo e .plist consumíveis pelo Xcode.

Com o Bazel, esse processo pode ser implementado da seguinte maneira, com unbundle-debuginfo sendo uma ação do Bazel:

load("@rules_cc//cc:defs.bzl", "ACTION_NAMES")

action_configs = [
    action_config (
        action_name = ACTION_NAMES.cpp_link_executable,
        tools = [
            tool(
                with_features = [
                    with_feature(features=["generate-debug-symbols"]),
                ],
                path = "toolchain/mac/ld-with-dsym-packaging",
            ),
            tool (path = "toolchain/mac/ld"),
        ],
    ),
]

features = [
    feature(
        name = "generate-debug-symbols",
        flag_sets = [
            flag_set (
                actions = [
                    ACTION_NAMES.c_compile,
                    ACTION_NAMES.cpp_compile
                ],
                flag_groups = [
                    flag_group(
                        flags = ["-g"],
                    ),
                ],
            )
        ],
        implies = ["unbundle-debuginfo"],
   ),
]

Esse mesmo recurso pode ser implementado de maneira totalmente diferente no Linux, que usa fission, ou no Windows, que produz arquivos .pdb. Por exemplo, a implementação para a geração de símbolos de depuração baseada em fission pode ter a seguinte aparência:

load("@rules_cc//cc:defs.bzl", "ACTION_NAMES")

action_configs = [
    action_config (
        name = ACTION_NAMES.cpp_compile,
        tools = [
            tool(
                path = "toolchain/bin/gcc",
            ),
        ],
    ),
]

features = [
    feature (
        name = "generate-debug-symbols",
        requires = [with_feature_set(features = ["dbg"])],
        flag_sets = [
            flag_set(
                actions = [ACTION_NAMES.cpp_compile],
                flag_groups = [
                    flag_group(
                        flags = ["-gsplit-dwarf"],
                    ),
                ],
            ),
            flag_set(
                actions = [ACTION_NAMES.cpp_link_executable],
                flag_groups = [
                    flag_group(
                        flags = ["-Wl", "--gdb-index"],
                    ),
                ],
            ),
      ],
    ),
]

Sinalizar grupos

O CcToolchainConfigInfo permite agrupar flags em grupos com uma finalidade específica. É possível especificar uma flag usando variáveis predefinidas no valor da flag, que o compilador expande ao adicionar a flag ao build do kubectl. Exemplo:

flag_group (
    flags = ["%{output_execpath}"],
)

Nesse caso, o conteúdo da flag será substituído pelo caminho do arquivo de saída da ação.

Os grupos de sinalizadores são expandidos para o comando de build na ordem em que aparecem na lista, de cima para baixo, da esquerda para a direita.

Para flags que precisam ser repetidas com valores diferentes quando adicionadas ao comando de build, o grupo de flags pode iterar variáveis do tipo list. Por exemplo, a variável include_path do tipo list:

flag_group (
    iterate_over = "include_paths",
    flags = ["-I%{include_paths}"],
)

se expande para -I<path> para cada elemento de caminho na lista include_paths. Todas as flags (ou flag_groups) no corpo de uma declaração de grupo de flags são expandidas como uma unidade. Exemplo:

flag_group (
    iterate_over = "include_paths",
    flags = ["-I", "%{include_paths}"],
)

se expande para -I <path> para cada elemento do caminho na lista include_paths.

Uma variável pode ser repetida várias vezes. Exemplo:

flag_group (
    iterate_over = "include_paths",
    flags = ["-iprefix=%{include_paths}", "-isystem=%{include_paths}"],
)

é expandido para:

-iprefix=<inc0> -isystem=<inc0> -iprefix=<inc1> -isystem=<inc1>

As variáveis podem corresponder a estruturas acessíveis usando a notação de ponto. Por exemplo:

flag_group (
    flags = ["-l%{libraries_to_link.name}"],
)

As estruturas podem ser aninhadas e também conter sequências. Para evitar conflitos de nome e ser explícito, especifique o caminho completo pelos campos. Por exemplo:

flag_group (
    iterate_over = "libraries_to_link",
    flag_groups = [
        flag_group (
            iterate_over = "libraries_to_link.shared_libraries",
            flags = ["-l%{libraries_to_link.shared_libraries.name}"],
        ),
    ],
)

Expansão condicional

Os grupos de flags oferecem suporte à expansão condicional com base na presença de uma variável específica ou no campo dela usando os atributos expand_if_available, expand_if_not_available, expand_if_true, expand_if_false ou expand_if_equal. Exemplo:

flag_group (
    iterate_over = "libraries_to_link",
    flag_groups = [
        flag_group (
            iterate_over = "libraries_to_link.shared_libraries",
            flag_groups = [
                flag_group (
                    expand_if_available = "libraries_to_link.shared_libraries.is_whole_archive",
                    flags = ["--whole_archive"],
                ),
                flag_group (
                    flags = ["-l%{libraries_to_link.shared_libraries.name}"],
                ),
                flag_group (
                    expand_if_available = "libraries_to_link.shared_libraries.is_whole_archive",
                    flags = ["--no_whole_archive"],
                ),
            ],
        ),
    ],
)

Referência de CcToolchainConfigInfo

Esta seção fornece uma referência de variáveis de build, recursos e outras informações necessárias para configurar regras C++.

Variáveis de build CcToolchainConfigInfo

Confira a seguir uma referência de variáveis de build CcToolchainConfigInfo.

Variável	Ação	Descrição
`source_file`	compile	Arquivo de origem a ser compilado.
`input_file`	strip	Artefato a ser removido.
`output_file`	compilar, remover	Saída da compilação.
`output_assembly_file`	compile	Arquivo assembly emitido. Aplica-se apenas quando a ação `compile` emite texto de montagem, normalmente ao usar a flag `--save_temps`. O conteúdo é o mesmo de `output_file`:
`output_preprocess_file`	compile	Saída pré-processada. Aplica-se apenas à compilação ações que pré-processam apenas os arquivos de origem, normalmente ao usar o sinalização `--save_temps`. O conteúdo é o mesmo de `output_file`:
`includes`	compile	Sequência de arquivos que o compilador precisa incluir incondicionalmente na origem compilada.
`include_paths`	compile	Diretórios de sequência em que o compilador procura cabeçalhos incluídos usando `#include<foo.h>` e `#include "foo.h"`.
`quote_include_paths`	compile	A sequência de `-iquote` inclui diretórios em que o compilador procura cabeçalhos incluídos usando `#include "foo.h"`.
`system_include_paths`	compile	A sequência de `-isystem` inclui diretórios em que o compilador procura cabeçalhos incluídos usando `#include <foo.h>`.
`dependency_file`	compile	O arquivo de dependência `.d` gerado pelo compilador.
`preprocessor_defines`	compile	Sequência de `defines`, como `--DDEBUG`.
`pic`	compile	Compila a saída como código independente de posição.
`gcov_gcno_file`	compile	O arquivo de cobertura `gcov`.
`per_object_debug_info_file`	compile	O arquivo de informações de depuração por objeto (`.dwp`).
`stripopts`	strip	Sequência de `stripopts`.
`legacy_compile_flags`	compile	Sequência de flags de campos `CROSSTOOL` legados, como `compiler_flag`, `optional_compiler_flag`, `cxx_flag` e `optional_cxx_flag`.
`user_compile_flags`	compile	Sequência de sinalizações do atributo de regra `copt` ou o `--copt`, `--cxxopt` e `--conlyopt`.
`unfiltered_compile_flags`	compile	Sequência de flags do campo `CROSSTOOL` `unfiltered_cxx_flag` herdado ou do recurso `unfiltered_compile_flags`. Elas não são filtradas por o atributo da regra `nocopts`.
`sysroot`		O `sysroot`.
`runtime_library_search_directories`	link	Entradas no caminho de pesquisa do tempo de execução do vinculador (geralmente definido com a flag `-rpath`).
`library_search_directories`	link	As entradas no caminho de pesquisa do vinculador (geralmente definidas com a sinalização `-L`).
`libraries_to_link`	link	Sinaliza que os arquivos são vinculados como entradas na invocação do vinculador.
`def_file_path`	link	Localização do arquivo def usado no Windows com MSVC.
`linker_param_file`	link	Localização do arquivo de parâmetro do vinculador criado pelo Bazel para ultrapassar o limite de comprimento da linha de comando.
`output_execpath`	link	Exemplo da saída do vinculador.
`generate_interface_library`	link	`"yes"` ou `"no"`, dependendo se a biblioteca de interface precisa ser gerada.
`interface_library_builder_path`	link	Caminho para a ferramenta de criação de biblioteca de interface.
`interface_library_input_path`	link	Entrada para a ferramenta de criação `ifso` da biblioteca de interface.
`interface_library_output_path`	link	Caminho em que a biblioteca de interfaces será gerada usando a ferramenta de builder `ifso`.
`legacy_link_flags`	link	Flags do vinculador provenientes dos campos `CROSSTOOL` legados.
`user_link_flags`	link	Flags do vinculador provenientes do atributo `--linkopt` ou `linkopts`.
`linkstamp_paths`	link	Uma variável de build que fornece caminhos de linkstamp.
`force_pic`	link	A presença desta variável indica que o código PIC/PIE deve ser gerado (a opção "--force_pic" do Bazel foi passada).
`strip_debug_symbols`	link	A presença dessa variável indica que os símbolos de depuração precisam ser removidos.
`is_cc_test`	link	Verdadeiro quando a ação atual é uma ação de vinculação `cc_test`. Caso contrário, é falso.
`is_using_fission`	compilar, vincular	A presença dessa variável indica que a fissão (informações de depuração por objeto) é ativada. As informações de depuração estarão em `.dwo` arquivos dos arquivos `.o`, e o compilador e o vinculador precisam saber disso.
`fdo_instrument_path`	compilar, vincular	Caminho para o diretório que armazena o perfil de instrumentação do FDO.
`fdo_profile_path`	compile	Caminho para o perfil do FDO.
`fdo_prefetch_hints_path`	compile	Caminho para o perfil de pré-busca do cache.
`cs_fdo_instrument_path`	compilar, vincular	Caminho para o diretório que armazena o perfil de instrumentação FDO sensível ao contexto.

Recursos conhecidos

Confira a seguir uma referência de recursos e as condições de ativação deles.

Recurso	Documentação
`opt \| dbg \| fastbuild`	Ativado por padrão com base no modo de compilação.
`static_linking_mode \| dynamic_linking_mode`	Ativado por padrão com base no modo de vinculação.
`per_object_debug_info`	Ativado se o recurso `supports_fission` for especificado e ativado e o modo de compilação atual for especificado no sinalização `--fission`.
`supports_start_end_lib`	Se ativado (e a opção `--start_end_lib` estiver definida), o Bazel não vinculará a bibliotecas estáticas, mas usará Opções do vinculador `--start-lib/--end-lib` para vincular a objetos diretamente. Isso acelera a compilação, já que o Bazel não precisa criar bibliotecas estáticas.
`supports_interface_shared_libraries`	Se ativado, e a opção `--interface_shared_objects` é definido), o Bazel vai vincular destinos que têm `linkstatic` definido como Falso (`cc_test`s por padrão) em relação à interface compartilhada bibliotecas. Isso torna a vinculação incremental mais rápida.
`supports_dynamic_linker`	Se ativado, as regras do C++ saberão que o conjunto de ferramentas pode produzir bibliotecas.
`static_link_cpp_runtimes`	Se ativada, o Bazel vai vincular o ambiente de execução C++ de forma estática no modo de vinculação estática e dinâmica no modo de vinculação dinâmica. Os artefatos especificados no atributo `cc_toolchain.static_runtime_lib` ou `cc_toolchain.dynamic_runtime_lib` (dependendo do modo de vinculação) serão adicionados às ações de vinculação.
`supports_pic`	Se ativado, o conjunto de ferramentas saberá usar objetos PIC para bibliotecas dinâmicas. A variável `pic` está presente sempre que a compilação de PIC é necessária. Se ela não for ativada por padrão, e "--force_pic" é transmitido, o Bazel solicita "supports_pic" e para confirmar que o recurso está ativado. Se o recurso estiver ausente ou se não for possível estiver ativado, "--force_pic" não poderá ser usado.
`static_linking_mode \| dynamic_linking_mode`	Ativado por padrão com base no modo de vinculação.
`no_legacy_features`	Impedem que o Bazel adicione recursos legados à configuração do C++ quando presentes. Confira a lista completa recursos abaixo.

Lógica de aplicação de patches de recursos legados

O Bazel aplica as seguintes mudanças aos recursos do conjunto de ferramentas para versões anteriores compatibilidade:

Move o recurso legacy_compile_flags para a parte superior do conjunto de ferramentas.
Move o recurso default_compile_flags para a parte superior do conjunto de ferramentas.
Adiciona o recurso dependency_file (se não estiver presente) à parte de cima da cadeia de ferramentas
Adiciona o recurso pic (se não houver) à parte superior do conjunto de ferramentas.
Adiciona o recurso per_object_debug_info (se não houver) à parte superior do conjunto de ferramentas.
Adiciona o recurso preprocessor_defines (se não houver) à parte superior do conjunto de ferramentas.
Adiciona o recurso includes (se não houver) à parte superior do conjunto de ferramentas.
Adiciona o recurso include_paths (se não estiver presente) à parte de cima da cadeia de ferramentas
Adiciona o recurso fdo_instrument (se não houver) à parte superior do conjunto de ferramentas.
Adiciona o recurso fdo_optimize (se não estiver presente) à parte de cima da cadeia de ferramentas
Adiciona o recurso cs_fdo_instrument (se não houver) à parte superior do conjunto de ferramentas.
Adiciona o recurso cs_fdo_optimize (se não estiver presente) à parte de cima da cadeia de ferramentas
Adiciona o recurso fdo_prefetch_hints (se não estiver presente) à parte de cima da cadeia de ferramentas
Adiciona o recurso autofdo (se não estiver presente) à parte de cima da cadeia de ferramentas
Adiciona o recurso build_interface_libraries (se não estiver presente) à parte de cima da cadeia de ferramentas
Adiciona o recurso dynamic_library_linker_tool (se não estiver presente) à parte de cima da cadeia de ferramentas
Adiciona o recurso shared_flag (se não estiver presente) à parte de cima da cadeia de ferramentas
Adiciona o recurso linkstamps (se não estiver presente) à parte de cima da cadeia de ferramentas
Adiciona o recurso output_execpath_flags (se não estiver presente) à parte de cima da cadeia de ferramentas
Adiciona o recurso runtime_library_search_directories (se não estiver presente) à parte de cima da cadeia de ferramentas
Adiciona o recurso library_search_directories (se não estiver presente) à parte de cima da cadeia de ferramentas
Adiciona o recurso archiver_flags (se não houver) à parte superior do conjunto de ferramentas.
Adiciona o recurso libraries_to_link (se não houver) à parte superior do conjunto de ferramentas.
Adiciona o recurso force_pic_flags (se não estiver presente) à parte de cima da cadeia de ferramentas
Adiciona o recurso user_link_flags (se não estiver presente) à parte de cima da cadeia de ferramentas
Adiciona o recurso legacy_link_flags (se não houver) à parte superior do conjunto de ferramentas.
Adiciona o recurso static_libgcc (se não estiver presente) à parte de cima da cadeia de ferramentas
Adiciona o recurso fission_support (se não estiver presente) à parte de cima da cadeia de ferramentas
Adiciona o recurso strip_debug_symbols (se não houver) à parte superior do conjunto de ferramentas.
Adiciona o recurso coverage (se não estiver presente) à parte de cima da cadeia de ferramentas
Adiciona o recurso llvm_coverage_map_format (se não houver) à parte superior do conjunto de ferramentas.
Adiciona o recurso gcc_coverage_map_format (se não houver) à parte superior do conjunto de ferramentas.
Adiciona o recurso fully_static_link (se não estiver presente) à parte de baixo do conjunto de ferramentas
Adiciona o recurso user_compile_flags (se não houver) à parte inferior do conjunto de ferramentas.
Adiciona o recurso sysroot (se não houver) à parte inferior do conjunto de ferramentas.
Adiciona o recurso unfiltered_compile_flags (se não estiver presente) à parte de baixo do conjunto de ferramentas
Adiciona o recurso linker_param_file (se não estiver presente) à parte de baixo do conjunto de ferramentas
Adiciona o recurso compiler_input_flags (se não houver) à parte inferior do conjunto de ferramentas.
Adiciona o recurso compiler_output_flags (se não estiver presente) à parte de baixo do conjunto de ferramentas

Esta é uma lista longa de recursos. O plano é se livrar delas uma vez O Crosstool no Starlark está feito. Para quem tem curiosidade, confira a implementação em CppActionConfigs, Para conjuntos de ferramentas de produção, considere adicionar no_legacy_features para tornar o conjunto de ferramentas mais autônomo.