Descripción general
Para invocar al compilador con las opciones correctas, Bazel necesita conocimientos sobre los componentes internos del compilador, como directorios de inclusión y marcas importantes. En otras palabras, Bazel necesita un modelo simplificado del compilador para comprender su de su funcionamiento.
Bazel debe saber lo siguiente:
- Si el compilador admite ThiLTO, módulos, vinculación dinámica o PIC. (código independiente de la posición).
- Rutas de acceso a las herramientas requeridas, como gcc, ld, ar, objcopy, etcétera.
- El sistema integrado incluye directorios. Bazel los necesita para validar que
todos los encabezados incluidos en el archivo fuente se declararon correctamente en
el archivo
BUILD
. - Es el sysroot predeterminado.
- Qué marcas usar para la compilación, la vinculación y el archivo
- Qué marcas usar para los modos de compilación admitidos (opt, dbg, fastbuild)
- Haz que el compilador requiera variables específicas.
Si el compilador es compatible con varias arquitecturas, Bazel debe configurar por separado.
CcToolchainConfigInfo
es un proveedor que proporciona el nivel necesario de
nivel de detalle para configurar el comportamiento de las reglas de C++ de Bazel. De forma predeterminada,
Bazel configura automáticamente CcToolchainConfigInfo
para tu compilación, pero puedes
tienes la opción de configurarlo manualmente. Para eso, necesitas una regla de Starlark
que proporcione el CcToolchainConfigInfo
, y debes apuntar el
El atributo toolchain_config
de cc_toolchain
a tu regla.
Para crear el CcToolchainConfigInfo
, llama a
cc_common.create_cc_toolchain_config_info()
Puedes encontrar constructores de Starlark para todas las structs que necesitarás en el proceso en
@rules_cc//cc:cc_toolchain_config_lib.bzl
Cuando un destino de C++ entra en la fase de análisis, Bazel selecciona los servicios
Destino cc_toolchain
basado en el archivo BUILD
y obtiene el
CcToolchainConfigInfo
proveedor del objetivo especificado en el
cc_toolchain.toolchain_config
. El objetivo cc_toolchain
pasa esta información al destino de C++ mediante un CcToolchainProvider
.
Por ejemplo, una acción de compilación o vinculación, cuya instancia se crea mediante una regla como
cc_binary
o cc_library
necesitan la siguiente información:
- El compilador o vinculador que se usará
- Marcas de línea de comandos para el compilador o vinculador
- Marcas de configuración pasadas por las opciones de
--copt/--linkopt
- Variables de entorno
- Los artefactos necesarios en la zona de pruebas en la que se ejecuta la acción
Toda la información anterior, excepto los artefactos requeridos en la zona de pruebas, es
especificado en el objetivo de Starlark al que apunta cc_toolchain
.
Los artefactos que se enviarán a la zona de pruebas se declaran en cc_toolchain
objetivo. Por ejemplo, con el atributo cc_toolchain.linker_files
, puedes
especificar los objetos binarios del vinculador y las bibliotecas de la cadena de herramientas que se enviarán a la zona de pruebas.
Selección de cadenas de herramientas
La lógica de selección de la cadena de herramientas funciona de la siguiente manera:
El usuario especifica un destino
cc_toolchain_suite
en el archivoBUILD
y puntos. Bazel al destino--crosstool_top
opción.El objetivo
cc_toolchain_suite
hace referencia a varias cadenas de herramientas. El Los valores de las marcas--cpu
y--compiler
determinan cuál de ellas de cadenas de herramientas, ya sea según el valor de la marca--cpu
o según un valor conjunto--cpu | --compiler
. El proceso de selección sigue:Si se especifica la opción
--compiler
, Bazel selecciona entrada correspondiente decc_toolchain_suite.toolchains
con--cpu | --compiler
. Si Bazel no encuentra una entrada correspondiente, arroja un error.Si no se especifica la opción
--compiler
, Bazel selecciona la entrada correspondiente decc_toolchain_suite.toolchains
con solo--cpu
.Si no se especifican marcas, Bazel inspecciona el sistema host y selecciona un Valor
--cpu
según sus hallazgos. Consulta la código del mecanismo de inspección.
Una vez que se haya seleccionado la cadena de herramientas, se establecerán los valores de feature
y action_config
correspondientes.
Los objetos de la regla de Starlark rigen la configuración de la compilación (es decir,
los elementos que se describen más adelante). Estos mensajes permiten implementar
funciones completas de C++ en Bazel sin modificar el
Objeto binario de Bazel. Las reglas de C++ admiten varias acciones únicas documentadas en detalle.
en el código fuente de Bazel.
Funciones
Un atributo es una entidad que requiere marcas de línea de comandos, acciones
restricciones en el entorno de ejecución o alteraciones de las dependencias. Una función
puede ser algo tan simple como permitir que los archivos BUILD
seleccionen configuraciones
marcas, como treat_warnings_as_errors
, o interactúan con las reglas de C++ y
incluir nuevas acciones de compilación y entradas a la compilación, como
header_modules
o thin_lto
.
Idealmente, CcToolchainConfigInfo
contiene una lista de atributos, en la que cada
La función consta de uno o más grupos de marcas, cada uno de los cuales define una lista de marcas.
que se aplican a acciones específicas de Bazel.
Un componente se especifica por nombre, lo que permite la separación completa de Starlark.
de reglas de firewall de las versiones de Bazel. En otras palabras, una versión de Bazel no
afectará el comportamiento de las configuraciones de CcToolchainConfigInfo
, siempre y cuando se
configuraciones no requieren el uso de funciones nuevas.
Una función se habilita de una de las siguientes maneras:
- El campo
enabled
del componente se estableció entrue
. - Bazel o el propietario de la regla lo habilitan de forma explícita.
- El usuario lo habilita a través de la opción
--feature
de Bazel o la reglafeatures
. .
Las funciones pueden tener interdependencias y dependen de las marcas de la línea de comandos, archivo BUILD
configuración y otras variables.
Relaciones de los atributos
Por lo general, las dependencias se administran directamente con Bazel, que simplemente aplica los requisitos y maneja conflictos intrínsecos con la naturaleza de las funciones definidos en la compilación. La especificación de la cadena de herramientas permite obtener restricciones para el uso directamente en la regla de Starlark que rigen la asistencia y expansión. Debes realizar las siguientes acciones:
Restricción | Descripción |
requires = [ feature_set (features = [ 'feature-name-1', 'feature-name-2' ]), ] |
A nivel del atributo. La función solo se admite si se especifica
funciones habilitadas. Por ejemplo, cuando una función solo se admite en
ciertos modos de compilación (opt , dbg o
fastbuild ). Si el argumento `requiere` contiene varios `feature_set`
se admite el atributo si se cumple alguno de los atributos `feature_set`
(cuando están habilitadas todas las funciones especificadas).
|
implies = ['feature'] |
A nivel del atributo. Esta función implica los atributos especificados. Cuando se habilita una función, también se habilitan de forma implícita todas las funciones que implica (es decir, funciona de manera recursiva). También permite factorizar subconjuntos comunes de funcionalidad un conjunto de características, como las partes comunes de los desinfectantes. Implícita no se pueden inhabilitar. |
provides = ['feature'] |
A nivel del atributo. Indica que este atributo es uno de varios mutuamente
funciones alternativas exclusivas. Por ejemplo, todos los desinfectantes
especificar Esto mejora el manejo de errores, ya que enumera las alternativas si el usuario lo solicita para dos o más funciones mutuamente excluyentes a la vez. |
with_features = [ with_feature_set( features = ['feature-1'], not_features = ['feature-2'], ), ] |
Nivel de configuración de la marca. Una función puede especificar varios conjuntos de marcas.
Cuando se especifica with_features , el conjunto de marcas solo se expandirá
al comando de compilación si hay al menos un with_feature_set
para el que se establecen todos los atributos del features especificado
están habilitados, y todas las funciones especificadas en not_features
están inhabilitadas.
Si no se especifica with_features , se establecerá la marca
se aplican incondicionalmente para cada acción especificada.
|
Acciones
Las acciones brindan la flexibilidad para modificar las circunstancias
que una acción se ejecuta sin suponer cómo se ejecutará. Los
action_config
especifica el objeto binario de la herramienta que invoca una acción, mientras que una
feature
especifica la configuración (marcas) que determinan cómo esa herramienta
se comporta cuando se invoca la acción.
Las funciones hacen referencia a acciones para indicar cuáles son las acciones de Bazel
que afectan, ya que las acciones pueden modificar el gráfico de acción de Bazel. El
El proveedor CcToolchainConfigInfo
contiene acciones que tienen marcas y herramientas
asociados, por ejemplo, c++-compile
. Se asignan marcas a cada acción
asociándolas a un atributo.
Cada nombre de acción representa un único tipo de acción que realiza Bazel, como
compilar o vincular. Sin embargo, existe una relación de varios a uno entre
y los tipos de acciones de Bazel, en los que un tipo de acción de Bazel hace referencia a una clase de Java
que implementa una acción (como CppCompileAction
). En particular, el
"acciones de ensamblador" y "acciones del compilador" que aparecen en la siguiente tabla
CppCompileAction
, mientras que las acciones de vinculación son CppLinkAction
.
Acciones del ensamblador
Acción | Descripción |
preprocess-assemble
|
Ensambla con el procesamiento previo. Por lo general, para archivos .S .
|
assemble
|
Ensambla sin procesamiento previo. Por lo general, para archivos .s .
|
Acciones del compilador
Acción | Descripción |
cc-flags-make-variable
|
Propaga CC_FLAGS a genrules.
|
c-compile
|
Compilar como C. |
c++-compile
|
Compila como C++. |
c++-header-parsing
|
Ejecuta el analizador del compilador en un archivo de encabezado para asegurarte de que el encabezado sea independiente, ya que, de lo contrario, producirá errores de compilación. Se aplica solo a cadenas de herramientas que admitan módulos. |
Acciones de vínculos
Acción | Descripción |
c++-link-dynamic-library
|
Vincula una biblioteca compartida que contenga todas sus dependencias. |
c++-link-nodeps-dynamic-library
|
Vincula una biblioteca compartida que solo contenga fuentes de cc_library .
|
c++-link-executable
|
Vincula una biblioteca final lista para ejecutarse. |
Acciones de RA
Las acciones de RA ensamblan archivos de objetos en bibliotecas de archivo (.a
archivos) mediante ar
y codificar algo de semántica en el nombre.
Acción | Descripción |
c++-link-static-library
|
Crea una biblioteca estática (archivo). |
Acciones de LTO
Acción | Descripción |
lto-backend
|
Acción de ThinLTO que compila códigos de bits en objetos nativos. |
lto-index
|
Acción ThinLTO que genera un índice global |
Usa action_config
action_config
es un struct de Starlark que describe una Bazel.
acción especificando la herramienta (binaria) que se invocará durante la acción y los conjuntos
de atributos, definidas por los atributos. Estas marcas aplican restricciones a la acción
ejecución.
El constructor action_config()
tiene los siguientes parámetros:
Atributo | Descripción |
action_name
|
La acción de Bazel a la que corresponde esta acción. Bazel usa este atributo para descubrir la herramienta por acción y la ejecución. y los requisitos de cumplimiento. |
tools
|
Es el ejecutable que se invocará. La herramienta aplicada a la acción será la primera herramienta de la lista con un conjunto de atributos que coincide con el atributo configuración. Se debe proporcionar un valor predeterminado. |
flag_sets
|
Una lista de marcas que se aplican a un grupo de acciones. Igual que para un . |
env_sets
|
Una lista de restricciones de entorno que se aplican a un grupo de acciones. Igual que para un atributo. |
Un action_config
puede requerir e implicar otras funciones y
action_config
según lo que dicta el
relaciones de atributos descritas anteriormente. Este comportamiento
es similar al de un atributo.
Los dos últimos atributos son redundantes respecto de los atributos correspondientes en
y se incluyen porque algunas acciones de Bazel requieren ciertas marcas o
variables de entorno y el objetivo es evitar action_config
+feature
innecesarios
pares. Por lo general, compartir un solo atributo entre varios action_config
es
de tu preferencia.
No puedes definir más de un action_config
con el mismo action_name
dentro de la misma cadena de herramientas. Esto evita la ambigüedad en las rutas de las herramientas.
y aplica la intención detrás de action_config
, es decir, que las propiedades de una acción
se describen claramente en un solo lugar en la cadena de herramientas.
Cómo usar el constructor de herramientas
Una action_config
puede especificar un conjunto de herramientas a través de su parámetro tools
.
El constructor tool()
toma los siguientes parámetros:
Campo | Descripción |
path
|
Es la ruta de acceso a la herramienta en cuestión (en relación con la ubicación actual). |
with_features
|
Una lista de conjuntos de funciones con las que se debe cumplir al menos uno para que se aplique esta herramienta. |
Para un action_config
determinado, solo se aplica un tool
.
la ruta de la herramienta y los requisitos de ejecución para la acción de Bazel. Se selecciona una herramienta
iterando a través del atributo tools
en un action_config
hasta que una herramienta
Se encontró un conjunto de with_feature
que coincide con la configuración de funciones
(Consulta Relaciones de los atributos más arriba en esta página)
para obtener más información). Debes finalizar tus listas de herramientas con una configuración
que corresponde a una configuración de atributos vacía.
Ejemplo de uso
Las funciones y acciones se pueden usar en conjunto para implementar acciones de Bazel
con una semántica multiplataforma. Por ejemplo, la generación de símbolos de depuración en
macOS requiere generar símbolos en la acción de compilación y, luego, invocar un
herramienta especializada durante la acción de vínculo para crear un archivo dsym comprimido.
Luego, se descomprime ese archivo para producir el paquete de aplicación y .plist
archivos consumibles por Xcode.
Con Bazel, este proceso se puede implementar de la siguiente manera, con
unbundle-debuginfo
es una acción de 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"],
),
]
Esta misma función puede implementarse de una forma totalmente diferente en Linux, que utiliza
fission
o para Windows, que produce archivos .pdb
. Por ejemplo, el
la implementación para la generación de símbolos de depuración basados en fission
podría verse de la siguiente manera:
sigue:
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 marcas
CcToolchainConfigInfo
te permite agrupar marcas en grupos que entregan un
con un propósito específico. Puedes especificar una marca usando variables predefinidas.
dentro del valor de la marca, que el compilador expande cuando se agrega la marca al
build. Por ejemplo:
flag_group (
flags = ["%{output_execpath}"],
)
En este caso, el contenido de la marca se reemplazará por la ruta de salida del archivo. de la acción.
Los grupos de marcas se expanden al comando de compilación en el orden en que aparecen. en la lista, de arriba a abajo, de izquierda a derecha.
Para marcas que necesitan repetirse con diferentes valores cuando se agregan a la compilación
, el grupo de marcas puede iterar variables de tipo list
. Por ejemplo, el
La variable include_path
de tipo list
:
flag_group (
iterate_over = "include_paths",
flags = ["-I%{include_paths}"],
)
se expande a -I<path>
para cada elemento de la ruta de acceso de la lista include_paths
. Todo
marcas (o flag_group
) en el cuerpo de la declaración de un grupo de marcas se expanden como
por unidad. Por ejemplo:
flag_group (
iterate_over = "include_paths",
flags = ["-I", "%{include_paths}"],
)
se expande a -I <path>
para cada elemento de la ruta de acceso de la lista include_paths
.
Una variable puede repetirse varias veces. Por ejemplo:
flag_group (
iterate_over = "include_paths",
flags = ["-iprefix=%{include_paths}", "-isystem=%{include_paths}"],
)
se expande a:
-iprefix=<inc0> -isystem=<inc0> -iprefix=<inc1> -isystem=<inc1>
Las variables pueden corresponder a estructuras accesibles con la notación de puntos. Por ejemplo:
flag_group (
flags = ["-l%{libraries_to_link.name}"],
)
Las estructuras pueden anidarse y también contener secuencias. Para evitar conflictos de nombres y, para ser explícito, debes especificar la ruta completa en los campos. Por ejemplo:
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}"],
),
],
)
Expansión condicional
Los grupos de marcas admiten la expansión condicional en función de la presencia de una función en particular
variable o su campo con las variables expand_if_available
, expand_if_not_available
,
atributos expand_if_true
, expand_if_false
o expand_if_equal
. Por ejemplo:
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"],
),
],
),
],
)
Referencia de CcToolchainConfigInfo
En esta sección, se proporciona una referencia de variables de compilación, funciones y otros la información requerida para configurar correctamente las reglas de C++.
Variables de compilación CcToolchainConfigInfo
A continuación, se incluye una referencia de las variables de compilación CcToolchainConfigInfo
.
Variable | Acción | Descripción |
source_file
|
compile | Archivo de origen para compilar. |
input_file
|
strip | Artefacto que se eliminará. |
output_file
|
compile | Resultado de compilación. |
output_assembly_file
|
compile | Archivo de ensamblado emitido. Se aplica solo cuando el
La acción compile emite texto de ensamblado, por lo general, cuando se usa el
--save_temps . El contenido es el mismo que para
output_file
|
output_preprocess_file
|
compile | Resultado procesado previamente. Solo se aplica a la compilación
que solo procesan los archivos de origen, generalmente cuando se usa
--save_temps . El contenido es el mismo que para
output_file
|
includes
|
compile | Secuencia de archivos que debe tener el compilador incluir incondicionalmente en la fuente compilada. |
include_paths
|
compile | Directorios de secuencias en los que el compilador
busca encabezados incluidos con #include<foo.h>
y #include "foo.h" .
|
quote_include_paths
|
compile | La secuencia de -iquote incluye lo siguiente:
directorios en los que el compilador busca encabezados incluidos usando
#include "foo.h"
|
system_include_paths
|
compile | La secuencia de -isystem incluye lo siguiente:
directorios en los que el compilador busca encabezados incluidos usando
#include <foo.h>
|
dependency_file
|
compile | El archivo de dependencia .d que genera el compilador.
|
preprocessor_defines
|
compile | Secuencia de defines , como --DDEBUG
|
pic
|
compile | Compila el resultado como código de posición independiente. |
gcov_gcno_file
|
compile | El archivo de cobertura gcov
|
per_object_debug_info_file
|
compile | El archivo de información de depuración por objeto (.dwp ).
|
stripotps
|
strip | Secuencia de stripopts
|
legacy_compile_flags
|
compile | Secuencia de marcas de la heredada
Campos CROSSTOOL , como compiler_flag ,
optional_compiler_flag , cxx_flag y
optional_cxx_flag
|
user_compile_flags
|
compile | Secuencia de marcas de los
el atributo de regla copt o el --copt ,
--cxxopt y --conlyopt .
|
unfiltered_compile_flags
|
compile | Secuencia de marcas del
unfiltered_cxx_flag heredado CROSSTOOL o el
unfiltered_compile_flags . Estos no se filtran por
el atributo de regla nocopts .
|
sysroot
|
El tipo sysroot .
|
|
runtime_library_search_directories
|
vínculo | Entradas en la ruta de búsqueda del entorno de ejecución del vinculador (normalmente
configurado con la marca -rpath ).
|
library_search_directories
|
vínculo | Entradas en la ruta de búsqueda del vinculador (generalmente, establecidas con
la marca -L ).
|
libraries_to_link
|
vínculo | Marcas que proporcionan archivos para vincular como entradas en la invocación del vinculador. |
def_file_path
|
vínculo | Ubicación del archivo def utilizado en Windows con MSVC. |
linker_param_file
|
vínculo | Ubicación del archivo de parámetros del vinculador creado por Bazel para se supera el límite de longitud de la línea de comandos. |
output_execpath
|
vínculo | Execpath de la salida del vinculador. |
generate_interface_library
|
vínculo | "yes" o "no" , lo cual depende de si la biblioteca de la interfaz debe
que se generará.
|
interface_library_builder_path
|
vínculo | Ruta de acceso a la herramienta de compilación de la biblioteca de interfaces. |
interface_library_input_path
|
vínculo | Entrada para la herramienta del compilador de ifso de la biblioteca de interfaz.
|
interface_library_output_path
|
vínculo | Es la ruta de acceso a la que se generará la biblioteca de la interfaz con el compilador de ifso .
|
legacy_link_flags
|
vínculo | Marcas del vinculador que provienen de los campos CROSSTOOL heredados.
|
user_link_flags
|
vínculo | Marcas del vinculador provenientes de --linkopt
o linkopts .
|
linkstamp_paths
|
vínculo | Una variable de compilación que proporciona rutas de acceso de linkstamp. |
force_pic
|
vínculo | La presencia de esta variable indica que el código PIC/PIE debe generarse (se pasó la opción de Bazel `--force_pic`). |
strip_debug_symbols
|
vínculo | La presencia de esta variable indica que la capa de los símbolos deben quedar seccionados. |
is_cc_test
|
vínculo | Verdadero cuando la acción actual es cc_test
acción de vinculación. De lo contrario, es falso.
|
is_using_fission
|
compilar, vincular | La presencia de esta variable indica que la fisión (información de depuración por objeto)
esté activado. En su lugar, la información de depuración estará en .dwo archivos
de archivos .o , y el compilador y el vinculador deben saber esto.
|
fdo_instrument_path
|
compilar, vincular | Es la ruta de acceso al directorio que almacena el perfil de instrumentación de FDO. |
fdo_profile_path
|
compile | Ruta de acceso al perfil de FDO. |
fdo_prefetch_hints_path
|
compile | Ruta de acceso al perfil de carga previa de caché. |
csfdo_instrument_path
|
compilar, vincular | Ruta de acceso al directorio que almacena el FDO sensible al contexto perfil de instrumentación. |
Funciones conocidas
La siguiente es una referencia de las funciones y su activación condiciones.
Función | Documentación |
opt | dbg | fastbuild
|
Está habilitada de forma predeterminada en función del modo de compilación. |
static_linking_mode | dynamic_linking_mode
|
Habilitada de forma predeterminada según el modo de vinculación. |
per_object_debug_info
|
Se habilita si se especifica la función supports_fission y
y el modo de compilación actual se especifica en el
--fission .
|
supports_start_end_lib
|
Si se habilita (y la opción --start_end_lib está configurada), Bazel
no se vincularán con bibliotecas estáticas, sino que usarán
Opciones del vinculador --start-lib/--end-lib para vincular con objetos
directamente. Esto acelera la compilación, ya que Bazel no tiene que compilar
estáticas.
|
supports_interface_shared_libraries
|
Si está habilitada (y la opción --interface_shared_objects es
), Bazel vinculará los destinos que tengan linkstatic establecido como
Falso (cc_test de forma predeterminada) en comparación con la interfaz compartida
bibliotecas. Esto hace que la revinculación incremental sea más rápida.
|
supports_dynamic_linker
|
Si se habilitan, las reglas de C++ sabrán que la cadena de herramientas puede producir archivos compartidos bibliotecas. |
static_link_cpp_runtimes
|
Si se habilita, Bazel vinculará el tiempo de ejecución C++ de forma estática en la vinculación estática.
y, de forma dinámica,
en el modo de vinculación dinámica. Artefactos
especificadas en el cc_toolchain.static_runtime_lib o
cc_toolchain.dynamic_runtime_lib (según la
modo de vinculación) a las acciones de vinculación.
|
supports_pic
|
Si se habilita, la cadena de herramientas sabrá usar objetos PIC para bibliotecas dinámicas. La variable `pic` está presente cuando se necesita compilación de PIC. Si no está habilitada de forma predeterminada y se pasa `--force_pic`, Bazel solicitará `supports_pic` y validar que la función esté habilitada. Si falta la función o no se pudo habilitarse, no se puede usar `--force_pic`. |
static_linking_mode | dynamic_linking_mode
|
Habilitada de forma predeterminada según el modo de vinculación. |
no_legacy_features
|
Impide que Bazel agregue funciones heredadas a la configuración de C++ cuando está presente. Consulta la lista completa de a continuación. |
Lógica de aplicación de parches de funciones heredadas
Bazel aplica los siguientes cambios a las funciones de la cadena de herramientas para versiones anteriores. compatibilidad:
- Mueve la función
legacy_compile_flags
a la parte superior de la cadena de herramientas. - Mueve la función
default_compile_flags
a la parte superior de la cadena de herramientas. - Agrega la función
dependency_file
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
pic
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
per_object_debug_info
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
preprocessor_defines
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
includes
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
include_paths
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
fdo_instrument
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
fdo_optimize
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
cs_fdo_instrument
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
cs_fdo_optimize
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
fdo_prefetch_hints
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
autofdo
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
build_interface_libraries
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
dynamic_library_linker_tool
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
shared_flag
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
linkstamps
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
output_execpath_flags
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
runtime_library_search_directories
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
library_search_directories
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
archiver_flags
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
libraries_to_link
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
force_pic_flags
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
user_link_flags
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
legacy_link_flags
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
static_libgcc
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
fission_support
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
strip_debug_symbols
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
coverage
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
llvm_coverage_map_format
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
gcc_coverage_map_format
(si no está presente) a la parte superior de la cadena de herramientas. - Agrega la función
fully_static_link
(si no está presente) al final de la cadena de herramientas. - Agrega la función
user_compile_flags
(si no está presente) al final de la cadena de herramientas. - Agrega la función
sysroot
(si no está presente) al final de la cadena de herramientas. - Agrega la función
unfiltered_compile_flags
(si no está presente) al final de la cadena de herramientas. - Agrega la función
linker_param_file
(si no está presente) al final de la cadena de herramientas. - Agrega la función
compiler_input_flags
(si no está presente) al final de la cadena de herramientas. - Agrega la función
compiler_output_flags
(si no está presente) al final de la cadena de herramientas.
Esta es una lista larga de funciones. El plan es deshacerse de ellos una vez
Crosstool en Starlark es
listo. Para los lectores curiosos, pueden ver la implementación en
CppActionConfigs,
Para las cadenas de herramientas de producción, considera agregar no_legacy_features
a fin de hacer que
la cadena de herramientas más independiente.