Configuração do conjunto de ferramentas C++

Informar um problema Ver fonte Nightly · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

Visão geral

Para invocar o compilador com as opções certas, o Bazel precisa de algum conhecimento sobre os internos do compilador, 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:

  • Se o compilador é compatível com 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 e assim por diante.
  • Os diretórios de inclusão do sistema integrados. O Bazel precisa deles para validar se todos os cabeçalhos incluídos no arquivo de origem foram declarados corretamente 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 compatíveis (opt, dbg, fastbuild).
  • Tornar as variáveis especificamente exigidas pelo compilador.

Se o compilador for compatível com várias arquiteturas, o Bazel precisará configurá-las separadamente.

CcToolchainConfigInfo é um provedor que oferece 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ê 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 sua regra. É possível criar o CcToolchainConfigInfo chamando cc_common.create_cc_toolchain_config_info(). Você pode encontrar construtores Starlark para todas as structs 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 o destino cc_toolchain apropriado com base no arquivo BUILD e extrai o provedor CcToolchainConfigInfo do destino especificado no atributo cc_toolchain.toolchain_config. O destino cc_toolchain transmite essas informações para o destino C++ por um CcToolchainProvider.

Por exemplo, uma ação de compilação ou vinculação, 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/linker
  • Flags 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 Starlark a que o cc_toolchain aponta.

Os artefatos a serem enviados para a sandbox são declarados na meta cc_toolchain. Por exemplo, com o atributo cc_toolchain.linker_files, é possível especificar o binário do vinculador e as bibliotecas da cadeia de ferramentas para serem enviadas para a 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 uma meta cc_toolchain_suite no arquivo BUILD e aponta o Bazel para a meta usando a opção --crosstool_top.

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

    • Se a opção --compiler for especificada, o Bazel vai 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 apenas com --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 do Starlark governam a configuração do build (ou seja, os itens descritos mais adiante). Essas mensagens permitem a implementação de recursos completos de 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 flags 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 de C++ e incluam novas ações e entradas de compilação, como header_modules ou thin_lto.

O ideal é que CcToolchainConfigInfo contenha uma lista de recursos, em que cada um 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 da regra 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 elas 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 o ativam explicitamente.
  • O usuário ativa essa opção usando o atributo --feature do Bazel ou a regra features.

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

Relações de recursos

As dependências geralmente são gerenciadas diretamente com o Bazel, que apenas impõe os requisitos e gerencia os conflitos inerentes à natureza dos recursos definidos no build. A especificação da cadeia de ferramentas permite restrições mais granulares para uso diretamente na regra Starlark que governa 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 obrigatórios especificados estiverem ativados. Por exemplo, quando um recurso só é compatível com determinados modos de build (opt, dbg ou fastbuild). Se "requires" contiver vários "feature_set"s, o recurso será compatível se qualquer um dos "feature_set"s 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 por ele (ou seja, funciona de forma recursiva).

Também oferece a capacidade de fatorar subconjuntos comuns de funcionalidades de um conjunto de recursos, como as partes comuns de sanitizadores. Não é possível desativar recursos implícitos.

 
provides = ['feature']

Nível do recurso. Indica que esse recurso é um de vários recursos alternativos mutuamente exclusivos. Por exemplo, todos os sanitizadores podem especificar provides = ["sanitizer"].

Isso melhora o tratamento de erros listando as alternativas se o usuário pedir 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 conjunto de flags. Um recurso pode especificar vários conjuntos de flags com "multiple". Quando with_features é especificado, o conjunto de flags só é expandido para o comando de build se houver pelo menos um with_feature_set em que todos os recursos no conjunto features especificado estão ativados e todos os recursos especificados no conjunto not_features estão 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 de 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 determina como essa ferramenta se comporta quando a ação é invocada.

As features referenciam ações para sinalizar quais ações do Bazel elas afetam, já que as ações podem modificar o gráfico de ações do Bazel. O provedor CcToolchainConfigInfo contém ações com flags e ferramentas associadas 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. 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 "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 Montar com pré-processamento. Normalmente para arquivos .S.
assemble Montar sem pré-processamento. Normalmente para arquivos .s.

Ações do compilador

Ação Descrição
cc-flags-make-variable Propaga CC_FLAGS para genrules.
c-compile Compile como C.
c++-compile Compile como C++.
c++-header-parsing Execute o analisador do compilador em um arquivo de cabeçalho para garantir que ele seja autônomo. Caso contrário, erros de compilação serão gerados. Aplicável apenas a toolchains que oferecem suporte a módulos.
Ação Descrição
c++-link-dynamic-library Vincule uma biblioteca compartilhada que contenha todas as dependências.
c++-link-nodeps-dynamic-library Vincule uma biblioteca compartilhada que contenha apenas fontes cc_library.
c++-link-executable Vincule uma biblioteca final pronta para execução.

Ações de RA

As ações do AR montam arquivos de objeto em bibliotecas de arquivos (arquivos .a) via 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 do ThinLTO que compila bitcodes em objetos nativos.
lto-index Ação ThinLTO que gera o índice global.

Como usar action_config

O action_config é uma estrutura Starlark que descreve uma ação do Bazel especificando a ferramenta (binário) a ser invocada durante a ação e conjuntos de flags, definidos por recursos. Esses flags 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 esta ação corresponde. O Bazel usa esse atributo para descobrir os requisitos de ferramenta e execução por ação.
tools O executável a ser invocado. A ferramenta aplicada à ação será a primeira na lista com um conjunto de recursos que corresponda à configuração de recursos. É necessário informar o valor padrão.
flag_sets Uma lista de flags que se aplicam a um grupo de ações. Igual a um recurso.
env_sets Uma lista de restrições de ambiente que se aplicam a um grupo de ações. Igual a um recurso.

Um action_config pode exigir e implicar outros recursos e action_configs, conforme ditado 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 nos recursos e são incluídos porque algumas ações do Bazel exigem determinadas flags ou variáveis de ambiente. 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 ambiguidade nos caminhos de ferramentas e reforça a intenção por trás de action_config: as propriedades de uma ação são descritas claramente em um único lugar na cadeia de ferramentas.

Como usar o construtor de ferramentas

Um action_config pode especificar um conjunto de ferramentas usando o parâmetro tools. O construtor tool() usa 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 único tool aplica o caminho da ferramenta e os requisitos de execução à ação do Bazel. Uma ferramenta é selecionada iterando o atributo tools em um action_config até que uma ferramenta com um conjunto with_feature correspondente à configuração do recurso seja encontrada. Consulte Relações de recursos nesta página para mais informações. Termine as listas de ferramentas com uma ferramenta padrão que corresponda a uma configuração de recurso vazia.

Exemplo de uso

Recursos e ações podem ser usados juntos para implementar ações do Bazel com semântica multiplataforma diversificada. 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 vinculação para criar um arquivo dsym compactado e a descompactação desse arquivo para produzir o pacote de aplicativo 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 para Linux, que usa fission, ou para 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 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"],
                    ),
                ],
            ),
      ],
    ),
]

Grupos de flags

O CcToolchainConfigInfo permite agrupar flags em grupos que atendem a uma finalidade específica. É possível especificar uma flag usando variáveis predefinidas no valor dela, 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 flags são expandidos para o comando de build na ordem em que aparecem na lista, de cima para baixo e 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}"],
)

é expandido para -I<path> em 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}"],
)

é expandido para -I <path> em cada elemento de 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}"],
)

é expandido para:

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

As variáveis podem corresponder a estruturas acessíveis usando a notação por pontos. 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 nomes 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 do 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 de C++ com sucesso.

Variáveis de build CcToolchainConfigInfo

A seguir, confira uma referência das 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 compile, strip Saída da compilação.
output_assembly_file compile Arquivo de assembly emitido. Só se aplica quando a ação compile emite texto de assembly, normalmente ao usar a flag --save_temps. O conteúdo é o mesmo de output_file.
output_preprocess_file compile Saída pré-processada. Aplicável apenas a ações de compilação que pré-processam apenas os arquivos de origem, normalmente ao usar a flag --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 Sequencia os diretórios em que o compilador procura cabeçalhos incluídos usando #include<foo.h> e #include "foo.h".
quote_include_paths compile Sequência de -iquote inclui diretórios em que o compilador procura cabeçalhos incluídos usando #include "foo.h".
system_include_paths compile 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 flags do atributo de regra copt ou das flags --copt, --cxxopt e --conlyopt.
unfiltered_compile_flags compile Sequência de flags do campo unfiltered_cxx_flag legado CROSSTOOL ou do recurso unfiltered_compile_flags. Eles não são filtrados pelo atributo de 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 Entradas no caminho de pesquisa do vinculador (geralmente definido com a flag -L).
libraries_to_link link Flags que fornecem arquivos para vincular como entradas na invocação do vinculador.
def_file_path link Local do arquivo def usado no Windows com MSVC.
linker_param_file link Local do arquivo de parâmetro do vinculador criado pelo bazel para ultrapassar o limite de comprimento da linha de comando.
output_execpath link Execpath 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 da biblioteca de interface ifso.
interface_library_output_path link Caminho para gerar a biblioteca de interface usando a ferramenta de criação ifso.
legacy_link_flags link Flags do vinculador dos campos legados CROSSTOOL.
user_link_flags link Flags de vinculador vindas do atributo --linkopt ou linkopts.
linkstamp_paths link Uma variável de build que fornece caminhos de carimbos de link.
force_pic link A presença dessa variável indica que o código PIC/PIE precisa ser gerado (a opção do Bazel "--force_pic" foi transmitida).
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) está ativada. As informações de depuração estarão em arquivos .dwo em vez de .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 para 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 na flag --fission.
supports_start_end_lib Se ativado (e se a opção --start_end_lib estiver definida), o Bazel não fará a vinculação com bibliotecas estáticas, mas usará as opções do vinculador --start-lib/--end-lib para vincular diretamente com objetos. Isso acelera o build, já que o Bazel não precisa criar bibliotecas estáticas.
supports_interface_shared_libraries Se ativado (e se a opção --interface_shared_objects estiver definida), o Bazel vai vincular destinos que têm linkstatic definido como False (cc_tests por padrão) a bibliotecas compartilhadas de interface. Isso torna a nova vinculação incremental mais rápida.
supports_dynamic_linker Se ativadas, as regras de C++ vão saber que o conjunto de ferramentas pode produzir bibliotecas compartilhadas.
static_link_cpp_runtimes Se ativado, o Bazel vai vincular o tempo de execução do C++ de maneira estática no modo de vinculação estática e de maneira 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 ativada, a cadeia de ferramentas saberá usar objetos PIC para bibliotecas dinâmicas. A variável "pic" está presente sempre que a compilação PIC é necessária. Se não estiver ativado por padrão e `--force_pic` for transmitido, o Bazel vai solicitar `supports_pic` e validar se o recurso está ativado. Se o recurso estiver faltando 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 Impede que o Bazel adicione recursos legados à configuração do C++ quando presentes. Confira a lista completa de recursos abaixo.
shorten_virtual_includes Se ativado, os arquivos de cabeçalho de inclusão virtual serão vinculados em bin/_virtual_includes/<hash of target path> em vez de bin/<target package path>/_virtual_includes/<target name>. Útil no Windows para evitar o problema de caminho longo com o MSVC.

Lógica de correção 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 a parte de cima da cadeia de ferramentas.
  • Move o recurso default_compile_flags para a parte de cima da cadeia de ferramentas.
  • Adiciona o recurso dependency_file (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso pic (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso per_object_debug_info (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso preprocessor_defines (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso includes (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso include_paths (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso fdo_instrument (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso fdo_optimize (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso cs_fdo_instrument (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso cs_fdo_optimize (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso fdo_prefetch_hints (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso autofdo (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso build_interface_libraries (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso dynamic_library_linker_tool (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso shared_flag (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso linkstamps (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso output_execpath_flags (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso runtime_library_search_directories (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso library_search_directories (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso archiver_flags (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso libraries_to_link (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso force_pic_flags (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso user_link_flags (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso legacy_link_flags (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso static_libgcc (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso fission_support (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso strip_debug_symbols (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso coverage (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso llvm_coverage_map_format (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso gcc_coverage_map_format (se não estiver presente) à parte superior da cadeia de ferramentas.
  • Adiciona o recurso fully_static_link (se ausente) à parte de baixo do conjunto de ferramentas
  • Adiciona o recurso user_compile_flags (se ausente) à parte de baixo do conjunto de ferramentas
  • Adiciona o recurso sysroot (se ausente) à parte de baixo do conjunto de ferramentas
  • Adiciona o recurso unfiltered_compile_flags (se ausente) à parte de baixo do conjunto de ferramentas
  • Adiciona o recurso linker_param_file (se ausente) à parte de baixo do conjunto de ferramentas
  • Adiciona o recurso compiler_input_flags (se ausente) à parte de baixo do conjunto de ferramentas
  • Adiciona o recurso compiler_output_flags (se ausente) à parte de baixo do conjunto de ferramentas

Essa é uma longa lista de recursos. O plano é se livrar deles quando o Crosstool no Starlark estiver concluído. Para o leitor curioso, consulte a implementação em CppActionConfigs, e para toolchains de produção, considere adicionar no_legacy_features para tornar a toolchain mais independente.