Configuração do conjunto de ferramentas C++

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 algum conhecimento sobre os componentes internos dele, como diretórios de inclusão e flags importantes. Em outras palavras, o Bazel precisa de um modelo simplificado do compilador para entender o funcionamento dele.

O Bazel precisa saber o seguinte:

• Indica se o compilador oferece suporte a thinLTO, módulos, vinculação dinâmica ou PIC (código independente de posição).
• Caminhos para as ferramentas necessárias, como gcc, ld, ar, objcopy etc.
• Os diretórios são incluídos no sistema integrado. O Bazel precisa deles para validar se todos os cabeçalhos que foram incluídos no arquivo de origem foram corretamente declarados no arquivo BUILD.
• O sysroot padrão.
• Quais flags usar para compilação, vinculação e arquivamento.
• Quais flags usar para os modos de compilação com suporte (opt, dbg, fastbuild).
• Crie as variáveis especificamente exigidas pelo compilador.

Se o compilador tiver suporte a várias arquiteturas, o Bazel precisará configurá-las separadamente.

O CcToolchainConfigInfo é um provedor que fornece o nível necessário de granularidade para configurar o comportamento das regras de C++ do Bazel. Por padrão, o Bazel configura automaticamente CcToolchainConfigInfo para seu build, mas você tem a opção de configurá-lo manualmente. Para isso, você precisa de uma regra do Starlark que forneça o CcToolchainConfigInfo e apontar o atributo toolchain_config do cc_toolchain para sua regra. Você pode criar o CcToolchainConfigInfo chamando cc_common.create_cc_toolchain_config_info(). Você pode encontrar construtores do Starlark para todos os structs necessários no processo em @rules_cc//cc:cc_toolchain_config_lib.bzl.

Quando um destino C++ entra na fase de análise, o Bazel seleciona o destino cc_toolchain apropriado com base no arquivo BUILD e recebe o provedor CcToolchainConfigInfo do destino especificado no atributo 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 necessários no sandbox, são especificadas no destino do Starlark para o qual o cc_toolchain aponta.

Os artefatos a serem enviados para o sandbox são declarados no destino cc_toolchain. Por exemplo, com o atributo cc_toolchain.linker_files, é possível especificar as bibliotecas de toolchain e o binário do vinculador para enviar para o sandbox.

Seleção de conjunto de ferramentas

A lógica de seleção da cadeia de ferramentas funciona da seguinte maneira:

1. 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.

2. O destino cc_toolchain_suite faz referência a vários conjuntos de ferramentas. Os valores das flags --cpu e --compiler determinam qual das toolchains é selecionada, seja com base apenas no valor da flag --cpu ou com base em um valor --cpu | --compiler conjunto. O processo de seleção é o seguinte:

   • Se a opção --compiler for especificada, o Bazel selecionará a entrada correspondente do atributo 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 sinalização for especificada, o Bazel vai inspecionar o sistema host e selecionar um valor de --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 completos do C++ no Bazel sem modificar o 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 recurso é uma entidade que exige sinalizações de linha de comando, ações, restrições no ambiente de execução ou alterações de dependência. 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.

O ideal é que CcToolchainConfigInfo contenha uma lista de recursos, em que cada recurso consiste em um ou mais grupos de flags, cada um definindo uma lista de flags que se aplicam a ações específicas do Bazel.

Um recurso é especificado por nome, o que permite o desacoplamento total da configuração de regra do Starlark das versões do Bazel. Em outras palavras, uma versão do Bazel não afeta o comportamento das configurações CcToolchainConfigInfo, desde que essas configurações não exijam 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 o serviço usando a opção --feature do Bazel ou o atributo de regra features.

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

Relações entre atributos

As dependências geralmente são gerenciadas diretamente com o Bazel, que simplesmente aplica os requisitos e gerencia conflitos intrínsecos à natureza dos recursos definidos no build. A especificação do conjunto de ferramentas permite restrições mais granulares para uso diretamente dentro da regra do Starlark que regem o suporte e a expansão de recursos. 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 tem suporte apenas em determinados modos de build (opt, dbg ou fastbuild). Se "requires" contiver vários "feature_set"s, o recurso terá suporte se qualquer um dos "feature_set"s for atendido (quando todos os recursos especificados estiverem ativados).
implies = ['feature']	Nível do recurso. Este recurso indica os recursos especificados. Ativar um recurso também ativa implicitamente todos os recursos implícitos nele, ou seja, ele funciona recursivamente. Também possibilita fatorar subconjuntos comuns de funcionalidade em um conjunto de recursos, como as partes comuns dos desinfetantes. Os recursos implícitos não podem ser desativados.
provides = ['feature']	Nível do recurso. Indica que esse recurso é um dos vários recursos alternativos mutuamente exclusivos. Por exemplo, todos os limpadores podem especificar provides = ["sanitizer"]. Isso melhora o tratamento de erros, listando as alternativas se o usuário solicitar dois ou mais recursos mutuamente exclusivos de uma só vez.
with_features = [ with_feature_set( features = ['feature-1'], not_features = ['feature-2'], ), ]	Nível de sinalização. Um recurso pode especificar vários conjuntos de sinalizações com vários. Quando with_features for especificado, a sinalização definida será expandida para o comando de build se houver pelo menos um with_feature_set para o qual todos os recursos no conjunto de features especificado estiverem ativados e todos os recursos especificados no conjunto de not_features estiverem desativados. Se with_features não for especificado, o conjunto de flags será aplicado incondicionalmente a todas as ações especificadas.

Ações

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

Os recursos se referem a ações para indicar quais ações do Bazel afetam, já que elas podem modificar o gráfico de ações do Bazel. O provedor CcToolchainConfigInfo contém ações que têm flags e ferramentas associadas a ele, 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 executada pelo Bazel, como compilação ou vinculação. No entanto, há uma relação de muitos para um entre ações 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). Em particular, as "ações do assembler" e as "ações do compilador" na tabela abaixo são CppCompileAction, enquanto as ações de vinculação são CppLinkAction.

Ações do assembler

Ação	Descrição
preprocess-assemble	Montagem com 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 a 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	Vincular uma biblioteca compartilhada que contém apenas cc_library origens.
c++-link-executable	Vincule uma biblioteca final pronta para uso.

Ações de RA

As ações de RA reúnem arquivos de objeto em bibliotecas de arquivos (arquivos .a) usando ar e codificam algumas semânticas no nome.

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

Ações de 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 do Starlark que descreve uma ação do Bazel especificando a ferramenta (binária) a ser invocada durante a ação e os conjuntos de sinalizações, definidas por recursos. Essas sinalizações aplicam restrições à execução da ação.

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

Attribute	Descrição
action_name	A ação do Bazel a que essa ação corresponde. O Bazel usa esse atributo para descobrir a ferramenta por ação e os requisitos de execução.
tools	O executável a ser invocado. A ferramenta aplicada à ação será a primeira na lista com um conjunto de recursos que corresponde à configuração do recurso. É necessário fornecer o valor padrão.
flag_sets	Uma lista de flags que se aplica a um grupo de ações. Igual a um recurso.
env_sets	Uma lista de restrições de ambiente que se aplica 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 relações de recursos descritas anteriormente. Esse comportamento é semelhante ao de um recurso.

Os dois últimos atributos são redundantes em relação aos atributos correspondentes em recursos e são incluídos porque algumas ações do Bazel exigem determinadas flags ou variáveis de ambiente, e o objetivo é evitar pares action_config+feature desnecessários. Normalmente, é preferível compartilhar um único recurso em vários 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 impõe a intenção por trás de action_config: que as propriedades de uma ação sejam claramente descritas em um único local no conjunto de ferramentas.

Como usar o 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 recursos em que pelo menos um precisa ser atendido para que essa ferramenta seja aplicada.

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 no início desta página para mais informações. Encerre suas listas de ferramentas com uma ferramenta padrão que corresponda a uma configuração de recurso vazia.

Exemplo de uso

Os recursos e as ações podem ser usados juntos para implementar ações do Bazel com várias semânticas multiplataforma. Por exemplo, a geração de símbolos de depuração no macOS exige a geração de símbolos na ação de compilação, a invocação de uma ferramenta especializada durante a ação de link para criar um arquivo Dsym compactado e a descompactação desse arquivo para produzir o pacote de aplicativos e os arquivos .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 geração de símbolos de depuração baseada em fission pode ter esta 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 comando de build. 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 sinalizações que precisam ser repetidas com valores diferentes quando adicionadas ao comando de criação, o grupo de sinalizações 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 se repetir várias vezes. Exemplo:

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

expande-se 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 podem conter sequências. Para evitar conflitos de nome e para ser explícito, especifique o caminho completo nos 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 sinalizações são compatíveis com a expansão condicional com base na presença de uma determinada variável ou do respectivo campo 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"],
                ),
            ],
        ),
    ],
)

Observação: as opções --whole_archive e --no_whole_archive são adicionadas ao comando de build somente quando uma biblioteca iterada atualmente tem um campo is_whole_archive.

Referência de CcToolchainConfigInfo

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

Variáveis de build CcToolchainConfigInfo

Esta é uma referência de variáveis de build CcToolchainConfigInfo.

Observação: a coluna Ação indica o tipo de ação relevante, se aplicável.

Variável	Ação	Descrição
source_file	compile	Arquivo de origem a ser compilado.
input_file	strip	Artefato a ser retirado.
output_file	compile	Saída da compilação.
output_assembly_file	compile	Arquivo de montagem emitido. Aplica-se somente quando a ação compile emite texto Assembly, normalmente ao usar a sinalização --save_temps. O conteúdo é o mesmo de output_file.
output_preprocess_file	compile	Saída pré-processada. Aplica-se apenas a ações de compilação que processam apenas os arquivos de origem, normalmente quando a flag --save_temps é usada. 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 pesquisa 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).
stripotps	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 das sinalizações --copt, --cxxopt e --conlyopt.
unfiltered_compile_flags	compile	Sequência de sinalizações do campo CROSSTOOL legado de unfiltered_cxx_flag ou do recurso unfiltered_compile_flags. Elas não são filtradas pelo atributo de regra nocopts.
sysroot		O sysroot.
runtime_library_search_directories	link	Entradas no caminho de pesquisa do ambiente de execução do vinculador (geralmente definidas com a sinalização -rpath).
library_search_directories	link	Entradas no caminho de pesquisa do vinculador (geralmente definido com a flag -L).
libraries_to_link	link	Sinalizações que fornecem arquivos a serem 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 dessa variável indica que o código PIC/PIE deve ser gerado (a opção do Bazel "--force_pic" 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 divisão (informações de depuração por objeto) está ativada. As informações de depuração estarão em arquivos .dwo, e não em arquivos .o, e o compilador e o vinculador precisam saber isso.
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.
csfdo_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 dos recursos e as condições de ativação.

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 na flag --fission.
supports_start_end_lib	Se ativado (e a opção --start_end_lib estiver definida), o Bazel não vai vincular bibliotecas estáticas, mas vai usar as --start-lib/--end-lib opções do vinculador para vincular 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 estiver definida), o Bazel vai vincular destinos que tenham linkstatic definido como falso (cc_tests por padrão) a bibliotecas compartilhadas de interface. Isso torna a vinculação incremental mais rápida.
supports_dynamic_linker	Se ativada, as regras do C++ saberão que o conjunto de ferramentas pode produzir bibliotecas compartilhadas.
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 vai saber usar objetos PIC para bibliotecas dinâmicas. A variável `pic` está presente sempre que a compilação de PIC é necessária. Se não estiver ativado por padrão e "--force_pic" for transmitido, o Bazel solicitará "supports_pic" e validará se o recurso está ativado. Se o recurso estiver ausente ou não puder ser ativado, não será possível usar `--force_pic`.
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 de recursos abaixo.

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

O Bazel aplica as seguintes mudanças aos recursos da cadeia de ferramentas para compatibilidade com versões anteriores:

• Move o recurso legacy_compile_flags para o topo da cadeia de ferramentas
• Move o recurso default_compile_flags para o topo da cadeia de ferramentas
• Adiciona o recurso dependency_file (se não houver) à parte superior do conjunto 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 estiver presente) à parte de cima da cadeia 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 estiver presente) à parte de cima da cadeia de ferramentas
• Adiciona o recurso fdo_optimize (se não houver) à parte superior do conjunto de ferramentas.
• Adiciona o recurso cs_fdo_instrument (se não estiver presente) à parte de cima da cadeia de ferramentas
• Adiciona o recurso cs_fdo_optimize (se não houver) à parte superior do conjunto 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 houver) à parte superior do conjunto de ferramentas.
• Adiciona o recurso dynamic_library_linker_tool (se não houver) à parte superior do conjunto 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 houver) à parte superior do conjunto de ferramentas.
• Adiciona o recurso output_execpath_flags (se não houver) à parte superior do conjunto de ferramentas.
• Adiciona o recurso runtime_library_search_directories (se não houver) à parte superior do conjunto de ferramentas.
• Adiciona o recurso library_search_directories (se não houver) à parte superior do conjunto 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 estiver presente) à parte de cima da cadeia de ferramentas
• Adiciona o recurso force_pic_flags (se não houver) à parte superior do conjunto 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 houver) à parte inferior 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 houver) à parte inferior do conjunto de ferramentas.
• Adiciona o recurso linker_param_file (se não houver) à parte inferior do conjunto de ferramentas.
• Adiciona o recurso compiler_input_flags (se não estiver presente) à parte de baixo do conjunto de ferramentas
• Adiciona o recurso compiler_output_flags (se não houver) à parte inferior do conjunto de ferramentas.

Esta é uma longa lista de recursos. O plano é se livrar deles quando o Crosstool no Starlark for concluído. Se você tiver curiosidade, confira a implementação em CppActionConfigs. No caso dos conjuntos de ferramentas de produção, considere adicionar no_legacy_features para torná-los mais autônomos.