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 etc.
- 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).
- Crie as variáveis especificamente exigidas pelo compilador.
Se o compilador tiver suporte a várias arquiteturas, o Bazel vai precisar configurar separadamente.
O 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 CcToolchainConfigInfo
automaticamente para seu build, mas você
você tem a opção de configurá-lo manualmente. Para isso, você precisa
de uma regra Starlark
que fornece o CcToolchainConfigInfo
, e você precisa apontar
toolchain_config
do cc_toolchain
à sua regra.
É possível criar o CcToolchainConfigInfo
chamando
cc_common.create_cc_toolchain_config_info()
.
Você pode encontrar construtores 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
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++ usando 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
- 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 exigidos no sandbox, são
especificado no alvo Starlark para o qual o cc_toolchain
aponta.
Os artefatos a serem enviados para o 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 de
cc_toolchain_suite
no arquivoBUILD
e aponta do Bazel ao destino usando a--crosstool_top
.O destino
cc_toolchain_suite
faz referência a vários conjuntos de ferramentas. A 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 elementocc_toolchain_suite.toolchains
com--cpu | --compiler
. Se o Bazel não encontrar uma entrada correspondente, será gerado um erro.Se a opção
--compiler
não for especificada, o Bazel selecionará a entrada correspondente do objetocc_toolchain_suite.toolchains
com apenas--cpu
.Se nenhuma flag for especificada, o Bazel vai inspecionar o sistema host e selecionar
--cpu
com base nas descobertas. Consulte a código do mecanismo de inspeção.
Depois que um conjunto de ferramentas for selecionado, os feature
e action_config
correspondentes
da regra Starlark controlam a configuração do build (ou seja,
descritos posteriormente). Essas mensagens permitem a implementação de
recursos C++ completos no Bazel sem modificar a
Binário do Bazel. As regras C++ são compatíveis com várias ações únicas 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
sinalizações, como treat_warnings_as_errors
, ou interagem com as regras do C++ e
incluem novas ações e entradas para a 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 elemento é especificado pelo nome, o que permite o desacoplamento total do Starlark.
a configuração de regras de 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 comotrue
. - o Bazel ou o proprietário da regra a ativarem explicitamente.
- o usuário ativa a ferramenta usando a opção
--feature
do Bazel ou a regrafeatures
; .
Os atributos podem ter interdependências, depender de sinalizações de linha de comando, arquivo BUILD
configurações 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 tem suporte apenas se o valor exigido
estejam ativados. Por exemplo, quando um recurso só tem suporte em
certos modos de build (opt , dbg ou
fastbuild ). Se `require` contiver vários `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. Este recurso indica os recursos especificados. Habilitar um recurso também ativa implicitamente todos os recursos implícitos por ele (ou seja, ele funciona de maneira recursiva). 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 Isso melhora o tratamento de erros listando as alternativas se o usuário perguntar 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 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 se referem a ações para sinalizar quais ações do Bazel
afetados, já que as ações podem modificar o gráfico de ações do Bazel. A
O provedor CcToolchainConfigInfo
contém ações que têm flags e ferramentas
associados a elas, como c++-compile
. Flags são atribuídas a cada ação
associando-as a um atributo.
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 configurador
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
|
Compile como C++. |
c++-header-parsing
|
Execute o analisador do compilador em um arquivo principal para garantir que o cabeçalho seja independentes, já que produzirão 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
|
Vincular uma biblioteca compartilhada que contenha apenas cc_library origens.
|
c++-link-executable
|
Vincule uma biblioteca final pronta para execução. |
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
é um struct Starlark que descreve um Bazel.
especificando a ferramenta (binária) a ser invocada durante a ação e os conjuntos de
e flags definidas pelos atributos. 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 essa 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 sinalizações que se aplicam 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_config
s, conforme determinado pelo
as relações de atributos descritas anteriormente. Esse comportamento
é semelhante ao de um atributo.
Os dois últimos atributos são redundantes em relação aos atributos correspondentes
e estão incluídos porque algumas ações do Bazel exigem determinadas flags ou
variáveis de ambiente, e o objetivo é evitar action_config
+feature
pares. Normalmente, compartilhar um único recurso em vários action_config
s é
de preferência.
Não é possível definir mais de um action_config
com a mesma action_name
no mesmo conjunto de ferramentas. Isso evita ambiguidade nos caminhos de ferramentas
e aplica a intenção por trás de action_config
, de que as propriedades de uma ação
são descritos claramente em um único local no conjunto de ferramentas.
Uso do 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 ao local atual). |
with_features
|
uma lista de conjuntos de atributos em que pelo menos um deles precisa ser atendido. para essa ferramenta aplicar. |
Apenas uma tool
é aplicada a um determinado action_config
o caminho da ferramenta e os requisitos de execução para a ação do Bazel. Uma ferramenta é selecionada
iterando o atributo tools
em um action_config
até que uma ferramenta
com um conjunto de with_feature
correspondente à configuração do recurso é encontrado
Consulte Relacionamentos de atributos anteriormente 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 (
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 forma totalmente diferente no Linux, que usa
fission
ou para Windows, que produz arquivos .pdb
. Por exemplo, o
implementação para geração de símbolos de depuração baseados em fission
pode ter a seguinte aparência:
da seguinte forma:
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 flags em grupos que disponibilizam uma
para 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_file_path}"],
)
Nesse caso, o conteúdo da flag será substituído pelo caminho do arquivo de saída. da ação.
Os grupos de sinalizações são expandidos para o comando "build" na ordem em que aparecem. da lista, de cima para baixo, da esquerda para a direita.
Para flags que precisam ser repetidas com valores diferentes quando adicionadas ao build
o grupo de sinalizações poderá iterar variáveis do tipo list
. Por exemplo, o
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 do caminho na lista include_paths
. Todos
as sinalizações (ou flag_group
s) no corpo de uma declaração de grupo de sinalizações são expandidas conforme
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 conter sequências. Para evitar conflitos de nomes e, para ser explícito, você precisa especificar 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 um
variável ou seu campo usando expand_if_available
, expand_if_not_available
,
atributos 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 outros informações necessárias para configurar as regras de 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 retirado. |
output_file
|
compile | Saída de compilação. |
output_assembly_file
|
compile | Arquivo assembly emitido. Essa opção só se aplica quando
A ação compile emite texto Assembly, normalmente ao usar o
sinalização --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 incondicionalmente na fonte 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:
em que o compilador procura cabeçalhos incluídos usando
#include "foo.h" .
|
system_include_paths
|
compile | A sequência de -isystem inclui:
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 ).
|
stripotps
|
strip | Sequência de stripopts .
|
legacy_compile_flags
|
compile | Sequência de flags de elementos legados
Campos CROSSTOOL , 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 sinalizações do
campo CROSSTOOL legado unfiltered_cxx_flag ou o
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 de tempo de execução do vinculador (geralmente
definido com a sinalização -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çõ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 gerados.
|
interface_library_builder_path
|
link | Caminho para a ferramenta de criação da biblioteca de interface. |
interface_library_input_path
|
link | Entrada para a ferramenta builder da biblioteca de interface ifso .
|
interface_library_output_path
|
link | Caminho em que a biblioteca de interfaces será gerada usando a ferramenta de builder ifso .
|
legacy_link_flags
|
link | Sinalizações do vinculador provenientes dos campos CROSSTOOL legados.
|
user_link_flags
|
link | Sinalizações do vinculador provenientes de --linkopt
ou linkopts .
|
symbol_counts_output
|
link | Caminho no qual gravar contagens de símbolos. |
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 gerada (a opção "--force_pic" do Bazel foi passada). |
strip_debug_symbols
|
link | A presença desta variável indica que o script de depuração símbolos devem ser removidos. |
is_cc_test
|
link | Verdade quando a ação atual é um cc_test
ação de vinculação, 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. |
csfdo_instrument_path
|
compilar, vincular | Caminho para o diretório que armazena o FDO sensível ao contexto e o perfil de instrumentação. |
Elementos conhecidos
Confira a seguir uma referência dos recursos e a ativação deles pelas condições
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 ativado, o Bazel vincula o ambiente de execução C++ estaticamente na vinculação estática.
e dinamicamente no modo de vinculação dinâmica. Artefatos
especificado em cc_toolchain.static_runtime_lib ou
cc_toolchain.dynamic_runtime_lib (dependendo do
modo de vinculação) serão adicionadas à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
|
Impede que o Bazel adicione recursos legados ao a configuração do C++ quando presente. 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 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 houver) à parte superior do conjunto de ferramentas. - Adiciona o recurso
include_paths
(se não houver) à parte superior do conjunto 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 houver) à parte superior do conjunto 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 houver) à parte superior do conjunto de ferramentas. - Adiciona o recurso
fdo_prefetch_hints
(se não houver) à parte superior do conjunto de ferramentas. - Adiciona o recurso
autofdo
(se não houver) à parte superior do conjunto 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
symbol_counts
(se não houver) à parte superior do conjunto de ferramentas. - Adiciona o recurso
shared_flag
(se não houver) à parte superior do conjunto 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 houver) à parte superior do conjunto 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 houver) à parte superior do conjunto 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 houver) à parte superior do conjunto de ferramentas. - Adiciona o recurso
fission_support
(se não houver) à parte superior do conjunto 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 houver) à parte superior do conjunto 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 inferior do conjunto de ferramentas. - Adiciona o recurso
user_compile_flags
(se não estiver presente) à parte inferior do conjunto de ferramentas. - Adiciona o recurso
sysroot
(se não estiver presente) à parte inferior do conjunto de ferramentas. - Adiciona o recurso
unfiltered_compile_flags
(se não estiver presente) à parte inferior do conjunto de ferramentas. - Adiciona o recurso
linker_param_file
(se não estiver presente) à parte inferior do conjunto de ferramentas. - Adiciona o recurso
compiler_input_flags
(se não estiver presente) à parte inferior do conjunto de ferramentas. - Adiciona o recurso
compiler_output_flags
(se não estiver presente) à parte inferior do conjunto de ferramentas.
Esta é uma longa lista 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.