Visão geral
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 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 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 desses cabeçalhos 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, arquivamento.
- Quais flags serão usadas nos modos de compilação com suporte (opt, dbg, fastbuild).
- Torne as variáveis exigidas especificamente pelo compilador.
Se o compilador tiver suporte para várias arquiteturas, o Bazel precisará configurá-las separadamente.
O CcToolchainConfigInfo
(link em inglês) é um provedor que fornece o nível necessário de
granularidade para configurar o comportamento das regras em C++ do Bazel. Por padrão,
o Bazel configura a CcToolchainConfigInfo
automaticamente para seu build, mas você
tem a opção de configurá-lo manualmente. Para isso, você precisa de uma regra Starlark
que forneça o CcToolchainConfigInfo
e apontar o
atributo toolchain_config
do
cc_toolchain
para sua regra.
É possível criar a 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 extrai o
provedor CcToolchainConfigInfo
do destino especificado no
atributo 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 necessários no sandbox, são
especificadas no destino do Starlark apontado pelo cc_toolchain
.
Os artefatos que serão enviados ao sandbox são declarados no destino
cc_toolchain
. Por exemplo, com o atributo cc_toolchain.linker_files
, você pode
especificar as bibliotecas de conjunto de ferramentas e binário do vinculador que serão enviadas ao sandbox.
Seleção do conjunto de ferramentas
A lógica de seleção do conjunto de ferramentas opera da seguinte maneira:
O usuário especifica um destino
cc_toolchain_suite
no arquivoBUILD
e aponta o Bazel para o destino usando a opção--crosstool_top
.O destino
cc_toolchain_suite
faz referência a vários conjuntos de ferramentas. Os valores das sinalizações--cpu
e--compiler
determinam qual desses conjuntos de ferramentas será selecionado com base apenas no valor da sinalização--cpu
ou em um valor conjunto de--cpu | --compiler
. O processo de seleção é o seguinte:Se a opção
--compiler
for especificada, o Bazel selecionará a entrada correspondente do atributocc_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 atributocc_toolchain_suite.toolchains
com apenas--cpu
.Se nenhuma flag 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 um conjunto de ferramentas é selecionado, os objetos feature
e action_config
correspondentes na regra de 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++ 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 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 comotrue
. - O Bazel ou o proprietário da regra o ativaram explicitamente.
- O usuário o ativa pela opção
--feature
Bazel ou pelo atributo de regrafeatures
.
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 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 na regra de 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ó será compatível 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 "requires" contiver vários "feature_sets",
o recurso terá suporte se algum dos "feature_sets" for atendido
(quando todos os recursos especificados forem 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 funcionalidades a partir de um conjunto de recursos, como as partes comuns de higienizadores. Os recursos implícitos não podem ser desativados. |
provides = ['feature'] |
Nível do recurso. Indica que o recurso é um dos vários recursos alternativos
mutuamente exclusivos. Por exemplo, todos os limpadores podem
especificar 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'], ), ] |
Flag no nível do conjunto. Um recurso pode especificar vários conjuntos de flags com vários.
Quando with_features for especificado, o conjunto de sinalizações só será expandido
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 se todos os recursos especificados no conjunto not_features
estiverem desativados.
Se with_features não for especificado, o conjunto de sinalizações será aplicado 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 determina como essa ferramenta
se comporta quando a ação é invocada.
Ações de referência de recursos para indicar quais ações do Bazel
afetam, já que elas podem modificar o gráfico de ações. O
provedor CcToolchainConfigInfo
contém ações com 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 combinador
Ação | Descrição |
preprocess-assemble
|
Montado 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 regras gerais.
|
c-compile
|
Compilar 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 autossuficiente, porque, caso contrário, ele produzirá erros de compilação. Aplicável 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 tenha 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 arquivos (arquivos .a
) usando ar
e codificam uma semântica no nome.
Ação | Descrição |
c++-link-static-library
|
Criar uma biblioteca estática (arquivo). |
Ações de LTO
Ação | Descrição |
lto-backend
|
Ação do ThinLTO de compilar 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ária) a ser invocada durante a ação e os conjuntos de
sinalizações, definidos pelos 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 esta ação corresponde. O Bazel usa esse atributo para descobrir ferramentas por ação e requisitos de execução. |
tools
|
O executável a ser invocado. A ferramenta aplicada à ação será a primeira da lista com um conjunto de recursos que corresponda à configuração do recurso. É preciso fornecer o valor padrão. |
flag_sets
|
Uma lista de sinalizações que se aplicam a um grupo de ações. Igual a um atributo. |
env_sets
|
Uma lista de restrições de ambiente que se aplica a um grupo de ações. Igual a um atributo. |
Uma action_config
pode exigir e implicar outros recursos e
action_config
s, conforme determinado pelas
relações de atributos 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 em vários action_config
s.
Não é possível definir mais de uma action_config
com o mesmo action_name
no mesmo conjunto de ferramentas. Isso evita ambiguidade nos caminhos da ferramenta
e aplica 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
Uma action_config
pode especificar um conjunto de ferramentas usando o parâmetro tools
.
O construtor tool()
aceita estes parâmetros:
Campo | Descrição |
path
|
Caminho para a ferramenta em questão (em relação à localização atual). |
with_features
|
Uma lista de conjuntos de recursos em que pelo menos um precisa ser atendido para que a ferramenta seja aplicada. |
Para uma determinada action_config
, apenas uma única 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 Relações 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 entre plataformas. 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 apps 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"],
),
],
),
],
),
]
Sinalizar grupos
CcToolchainConfigInfo
permite agrupar sinalizações em grupos que atendem a uma
finalidade específica. É possível especificar uma sinalização usando variáveis predefinidas no valor dela, que o compilador expande ao adicionar a sinalização ao comando de compilação. Exemplo:
flag_group (
flags = ["%{output_execpath}"],
)
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 compilaçã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}"],
)
expande para -I<path>
para cada elemento de caminho na lista include_paths
. Todas as sinalizações (ou flag_group
s) no corpo de uma declaração de grupo de sinalizações 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 usando a notação de ponto. 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 deixar claro, é 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 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"],
),
],
),
],
)
Referência de CcToolchainConfigInfo
Esta seção fornece uma referência de variáveis de build, recursos e outras informações necessárias para configurar regras C++.
Variáveis de build CcToolchainConfigInfo
Veja abaixo 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 | Saída de compilação. |
output_assembly_file
|
compile | Arquivo Assembly emitido. Aplica-se apenas quando a ação
compile emite texto assembly, normalmente ao usar a flag
--save_temps . O conteúdo é o mesmo de
output_file .
|
output_preprocess_file
|
compile | Saída pré-processada. Aplica-se apenas a ações de compilação que somente pré-processam os arquivos de origem, normalmente 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
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 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 definidas com a sinalização -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 | Localização do arquivo de parâmetros do vinculador criado pelo Bazel para superar 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 da geração da biblioteca de interface.
|
interface_library_builder_path
|
link | Caminho para a ferramenta Criador de biblioteca de interface. |
interface_library_input_path
|
link | Entrada para a ferramenta builder ifso da biblioteca de interfaces.
|
interface_library_output_path
|
link | Caminho em que gerar a biblioteca de interface usando a ferramenta builder ifso .
|
legacy_link_flags
|
link | Sinalizações do vinculador que vêm dos campos CROSSTOOL legados.
|
user_link_flags
|
link | Sinalizações do vinculador que vêm dos atributos --linkopt
ou linkopts .
|
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 "--force_pic" do Bazel 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 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 de cache. |
cs_fdo_instrument_path
|
compilar, vincular | Caminho para o diretório que armazena o perfil de instrumentação do FDO sensível ao contexto. |
Recursos conhecidos
Confira a seguir uma referência de recursos e as condições de ativação deles.
Recurso | Documentação |
opt | dbg | fastbuild
|
Ativado por padrão com base no modo de compilação. |
static_linking_mode | dynamic_linking_mode
|
Ativado por padrão com base no modo de vinculação. |
per_object_debug_info
|
Ativado se o recurso supports_fission for especificado e
ativado e o modo de compilação atual for especificado na
flag --fission .
|
supports_start_end_lib
|
Se ativado (e a opção --start_end_lib estiver definida), o Bazel não vinculará bibliotecas estáticas, mas usará as opções do vinculador --start-lib/--end-lib 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 os destinos que têm linkstatic definido como
falso (cc_test s por padrão) nas bibliotecas compartilhadas
de interface. Isso torna a revinculação incremental mais rápida.
|
supports_dynamic_linker
|
Se ativadas, as regras do C++ saberão que o conjunto de ferramentas pode produzir bibliotecas compartilhadas. |
static_link_cpp_runtimes
|
Se ativado, o Bazel vinculará o ambiente de execução 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 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 PIC é necessária. Se essa opção não estiver ativada por padrão e "--force_pic" for transmitida, o Bazel vai 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 de recursos abaixo. |
Lógica de patch 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 ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
pic
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
per_object_debug_info
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
preprocessor_defines
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
includes
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
include_paths
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
fdo_instrument
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
fdo_optimize
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
cs_fdo_instrument
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
cs_fdo_optimize
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
fdo_prefetch_hints
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
autofdo
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
build_interface_libraries
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
dynamic_library_linker_tool
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
shared_flag
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
linkstamps
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
output_execpath_flags
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
runtime_library_search_directories
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
library_search_directories
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
archiver_flags
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
libraries_to_link
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
force_pic_flags
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
user_link_flags
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
legacy_link_flags
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
static_libgcc
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
fission_support
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
strip_debug_symbols
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
coverage
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
llvm_coverage_map_format
(se ausente) à parte de cima do conjunto de ferramentas. - Adiciona o recurso
gcc_coverage_map_format
(se ausente) à parte de cima do conjunto 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.
É uma lista longa de recursos. O plano é se livrar deles assim que o
Crosstool em Starlark for
concluído. Para um leitor curioso, consulte a implementação em
CppActionConfigs.
Para conjuntos de ferramentas de produção, considere adicionar no_legacy_features
para torná-lo
mais autônomo.