Configuração do conjunto de ferramentas C++

Informações gerais

Para invocar o compilador com as opções corretas, o Bazel precisa de algum conhecimento sobre os componentes internos do compilador, como diretórios de inclusão e sinalizações 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 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 e assim por diante.
  • O sistema integrado inclui diretórios. 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 serão usadas para compilação, vinculação e arquivamento.
  • Quais flags serão usadas nos modos de compilação compatíveis (opt, dbg, fastbuild).
  • Torna variáveis exigidas pelo compilador.

Se o compilador tiver suporte a várias arquiteturas, o Bazel vai precisar configurá-las 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 CcToolchainConfigInfo automaticamente 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. Para criar o CcToolchainConfigInfo, chame 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 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 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
  • Sinalizações 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 onde 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 do binário e do conjunto de ferramentas do vinculador a serem enviadas ao sandbox.

Seleção do conjunto de ferramentas

A lógica de seleção do conjunto de ferramentas opera 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 sinalizações --cpu e --compiler determinam qual desses conjuntos de ferramentas é selecionado, com base apenas no valor da sinalização --cpu ou com base em um valor de --cpu | --compiler conjunta. 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 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 um conjunto de ferramentas é selecionado, os objetos feature e action_config correspondentes na regra do Starlark controlam a configuração do build (ou seja, os itens descritos posteriormente). Essas mensagens permitem a implementação de recursos C++ completos no Bazel sem modificar o binário do Bazel. As regras do C++ são compatíveis com várias ações únicas 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 mudanças na 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 incluem novas ações e entradas para a 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 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 da regra do Starlark das versões do Bazel. Em outras palavras, uma versão do Bazel não afeta o comportamento das configurações de 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 a ativa pela opção --feature Bazel ou pelo atributo de regra features.

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

Relações de 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 estes:

Restrição Descrição 
requires = [
   feature_set (features = [
       'feature-name-1',
       'feature-name-2'
   ]),
]
 Nível do recurso. O recurso só será aceito se os recursos obrigatórios especificados estiverem ativados. Por exemplo, quando um recurso só tem suporte em determinados modos de build (opt, dbg ou fastbuild). Se "require" contiver vários "feature_set", o recurso vai ser aceito se algum dos "feature_sets" for atendido (quando todos os recursos especificados estiverem ativados). 
implies = ['feature']

Nível do recurso. Este recurso implica os recursos especificados. A ativação de um recurso também ativa implicitamente todos os recursos implícitos por ele (ou seja, ele funciona de maneira recursiva).

Também oferece a capacidade de fatorar subconjuntos comuns de funcionalidade fora de um conjunto de recursos, como as partes comuns de limpadores. Os recursos implícitos não podem ser desativados.

 
provides = ['feature']

Nível do recurso. Indica que esse é 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 caso o usuário solicite dois ou mais recursos mutuamente exclusivos de uma só vez.

 
with_features = [
  with_feature_set(
    features = ['feature-1'],
    not_features = ['feature-2'],
  ),
]
 Sinalização no nível do conjunto. Um recurso pode especificar vários conjuntos de sinalizações com vários. Quando with_features for especificado, a sinalização definida só 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, 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 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 (sinalizações) que determinam como essa ferramenta se comporta quando a ação é invocada.

Ações de referência dos recursos para sinalizar quais ações do Bazel elas afetam, já que elas podem modificar o gráfico de ações. O provedor CcToolchainConfigInfo contém ações que têm flags e ferramentas associadas, como c++-compile. As sinalizações 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). Especificamente, as "ações do assembler" e as "ações do compilador" na tabela abaixo são CppCompileAction, enquanto as ações de link 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 regras gerais.
c-compile Compile como C.
c++-compile Compile como C++.
c++-header-parsing Execute o analisador do compilador em um arquivo principal para garantir que o cabeçalho seja independente. Caso contrário, ele vai produzir erros de compilação. Aplica-se apenas a conjuntos de ferramentas compatíveis com módulos.
Ação Descrição
c++-link-dynamic-library Vincule uma biblioteca compartilhada que contém todas as dependências dela.
c++-link-nodeps-dynamic-library Vincular uma biblioteca compartilhada que contenha apenas cc_library fontes.
c++-link-executable Vincule uma biblioteca final pronta para execução.

Ações de RA

As ações de RA reúnem arquivos de objetos em bibliotecas de arquivo (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 com compilação de bitcodes em objetos nativos.
lto-index Ação do ThinLTO que gera um índice global.

Como usar action_config

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

O construtor action_config() tem estes parâmetros:

Attribute Descrição
action_name A ação do Bazel à qual esta ação corresponde. O Bazel usa esse atributo para descobrir requisitos de execução e ferramenta por ação.
tools O executável a ser invocado. A ferramenta aplicada à ação será a primeira ferramenta da lista com um conjunto de recursos correspondente à configuração do recurso. É preciso fornecer o valor padrão.
flag_sets Uma lista de sinalizações aplicáveis 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 atributo.

Uma 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, e o objetivo é evitar pares action_config+feature desnecessários. Normalmente, é preferível compartilhar um único recurso entre vários action_configs.

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

Como usar o construtor de ferramentas

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

Campo Descrição
tool_path Caminho para a ferramenta em questão (relativo à localização atual).
with_features Uma lista de conjuntos de recursos em que pelo menos um precisa estar satisfeito para que essa ferramenta seja aplicada.

Para uma determinada action_config, apenas uma tool aplica o caminho da ferramenta e os requisitos de execução à ação do Bazel. Uma ferramenta é selecionada pela iteração com o atributo tools em um action_config até que uma ferramenta com um conjunto de with_feature correspondente à configuração do recurso seja encontrada. Consulte Relacionamentos de recursos anteriormente nesta 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 diversas 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 e, em seguida, 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 do aplicativo e os arquivos .plist consumíveis pelo Xcode.

No 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 (
        config_name = ACTION_NAMES.cpp_link_executable,
        action_name = ACTION_NAMES.cpp_link_executable,
        tools = [
            tool(
                with_features = [
                    with_feature(features=["generate-debug-symbols"]),
                ],
                tool_path = "toolchain/mac/ld-with-dsym-packaging",
            ),
            tool (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(
                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

CcToolchainConfigInfo permite agrupar sinalizações em grupos que servem a uma finalidade específica. Você pode especificar uma sinalização usando variáveis predefinidas no valor dela, que o compilador expande ao adicionar a sinalização ao comando de build. Exemplo:

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

Nesse caso, o conteúdo da sinalização 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, da esquerda para a direita.

Para sinalizações que precisam ser repetidas com valores diferentes quando adicionadas ao comando de build, 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}"],
)

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}"],
)

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

se expande para:

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

As variáveis podem corresponder a estruturas acessíveis por meio da notação por pontos. 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 nomes e ser explícito, é preciso especificar o caminho completo nos campos. 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 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 as regras C++.

Variáveis de build CcToolchainConfigInfo

Esta é 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 compile Saída de compilação.
output_assembly_file compile Arquivo assembly emitido. Aplica-se somente quando a ação compile emite texto de montagem, normalmente ao usar a sinalização --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 somente os arquivos de origem, geralmente ao usar a 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 pesquisa 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 pesquisa 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 um 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 sinalizações 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 definidos com a sinalização -L
libraries_to_link link Sinalizações que fornecem arquivos para vincular 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 Excesso da saída do vinculador.
generate_interface_library link "yes" ou "no", dependendo da geração da biblioteca de interface.
interface_library_builder_path link Caminho para a ferramenta Criador de biblioteca de interfaces.
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 interface será gerada usando a ferramenta de criação ifso.
legacy_link_flags link Sinalizações do vinculador provenientes dos campos CROSSTOOL legados.
user_link_flags link Sinalizações do vinculador provenientes do atributo --linkopt ou linkopts.
symbol_counts_output link Caminho em que as contagens de símbolos serão gravadas.
linkstamp_paths link Uma variável de build que fornece caminhos para linkstamp.
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 Truthy 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 vão estar em arquivos .dwo em vez de .o. 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 em cache.
csfdo_instrument_path compilar, vincular Caminho para o diretório que armazena o perfil de instrumentação FDO com contexto sensível.

Recursos conhecidos

Confira a seguir uma referência dos 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 na sinalização --fission.
supports_start_end_lib Se ativado, e a opção --start_end_lib estiver definida, o Bazel não vinculará as bibliotecas estáticas, mas usará as opções do vinculador --start-lib/--end-lib para fazer a vinculação direta aos objetos. Isso acelera o build, 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 vinculará destinos que tenham linkstatic definido como falso (cc_tests por padrão) em relação a bibliotecas compartilhadas de interface. Isso torna a revinculação incremental mais rápida.
supports_dynamic_linker Se ativadas, as regras C++ saberão que o conjunto de ferramentas pode produzir bibliotecas compartilhadas.
static_link_cpp_runtimes Se ativado, o Bazel vai vincular o ambiente de execução do C++ estaticamente no modo de vinculação estática e dinamicamente 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.
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 PIC é necessária. Se essa opção não for ativada por padrão e "--force_pic" for transmitida, o Bazel solicitará "supports_pic" e validará se o recurso está ativado. Se o recurso estiver ausente ou não puder ser 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 Impede que o Bazel adicione recursos legados à configuração do C++, quando presente. Confira a lista completa dos recursos abaixo.

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

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

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

Essa é uma lista longa de recursos. O plano é se livrar deles assim que o Crosstool em Starlark for concluído. Para o leitor curioso, consulte a implementação em CppActionConfigs. Para conjuntos de ferramentas de produção, adicione no_legacy_features para tornar o conjunto de ferramentas mais autônomo.