Para obtener documentación sobre versiones estables, usa el menú desplegable "Documentos con versiones". La vista predeterminada refleja la versión más reciente en el encabezado.

Se usó la API de Cloud Translation para traducir esta página.

Configuración de la cadena de herramientas de C++

Informar un problema Ver fuente

Descripción general

Para invocar al compilador con las opciones correctas, Bazel necesita conocimientos sobre sus componentes internos, como marcas importantes y directorios de inclusión. En otras palabras, Bazel necesita un modelo simplificado del compilador para comprender su funcionamiento.

Bazel necesita saber lo siguiente:

Determina si el compilador admite estrechos, módulos, vinculación dinámica o PIC (código independiente de la posición).
Rutas a las herramientas requeridas como gcc, ld, ar, objcopy, etc.
En el sistema integrado, se incluyen directorios. Bazel los necesita para validar que todos los encabezados que se incluyeron en el archivo fuente se declararon correctamente en el archivo BUILD.
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)
Crea variables que el compilador requiera específicamente.

Si el compilador es compatible con varias arquitecturas, Bazel debe configurarlas por separado.

CcToolchainConfigInfo es un proveedor que proporciona el nivel de detalle necesario para configurar el comportamiento de las reglas de C++ de Bazel. De forma predeterminada, Bazel configura automáticamente CcToolchainConfigInfo para tu compilación, pero tienes la opción de configurarlo de forma manual. Para ello, necesitas una regla de Starlark que proporcione el CcToolchainConfigInfo y apuntar el atributo toolchain_config de cc_toolchain a tu regla. Puedes llamar a cc_common.create_cc_toolchain_config_info() para crear el CcToolchainConfigInfo. Puedes encontrar los constructores de Starlark para todos los struct 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 el objetivo cc_toolchain apropiado según el archivo BUILD y obtiene el proveedor CcToolchainConfigInfo del destino especificado en el atributo cc_toolchain.toolchain_config. El destino cc_toolchain pasa esta información al destino de C++ a través de un CcToolchainProvider.

Por ejemplo, una acción de compilación o vínculo, en la que se creó una instancia mediante una regla como cc_binary o cc_library, necesita 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 que se pasan a través de las opciones --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, se especifica en el destino de Starlark al que apunta cc_toolchain.

Los artefactos que se enviarán a la zona de pruebas se declaran en el destino cc_toolchain. Por ejemplo, con el atributo cc_toolchain.linker_files, puedes especificar el objeto binario del vinculador y las bibliotecas de cadenas de herramientas para enviar a la zona de pruebas.

Selección de cadena 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 archivo BUILD y apunta Bazel al destino mediante la opción --crosstool_top.
El destino cc_toolchain_suite hace referencia a varias cadenas de herramientas. Los valores de las marcas --cpu y --compiler determinan cuál de esas cadenas de herramientas se selecciona, ya sea en función del valor de la marca --cpu o de un valor conjunto --cpu | --compiler. El proceso de selección es el siguiente:
- Si se especifica la opción --compiler, Bazel selecciona la entrada correspondiente del atributo cc_toolchain_suite.toolchains con --cpu | --compiler. Si Bazel no encuentra la entrada correspondiente, arroja un error.
- Si no se especifica la opción --compiler, Bazel selecciona la entrada correspondiente del atributo cc_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 el código del mecanismo de inspección.

Una vez que se selecciona una cadena de herramientas, los objetos feature y action_config correspondientes de la regla de Starlark controlan la configuración de la compilación (es decir, los elementos que se describen más adelante). Estos mensajes permiten la implementación de funciones de C++ completas 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

Una función es una entidad que requiere marcas de línea de comandos, acciones, restricciones en el entorno de ejecución o alteraciones de dependencia. Una función puede ser algo tan simple como permitir que los archivos BUILD seleccionen configuraciones de marcas, como treat_warnings_as_errors, o interactuar con las reglas de C++ e incluir nuevas acciones de compilación y entradas a la compilación, como header_modules o thin_lto.

Idealmente, CcToolchainConfigInfo contiene una lista de funciones, en la que cada función consiste en uno o más grupos de marcas, y cada uno define una lista de marcas que se aplican a acciones específicas de Bazel.

Una función se especifica por nombre, lo que permite la separación completa de la configuración de reglas de Starlark de las versiones de Bazel. En otras palabras, una versión de Bazel no afecta el comportamiento de las configuraciones de CcToolchainConfigInfo, siempre que esas configuraciones no requieran el uso de funciones nuevas.

Una función se habilita de una de las siguientes maneras:

El campo enabled del componente se estableció en true.
Bazel o el propietario de la regla lo habilitan de forma explícita.
El usuario la habilita mediante la opción --feature de Bazel o el atributo de la regla features.

Las funciones pueden tener interdependencias, depender de marcas de línea de comandos, la configuración del archivo BUILD y otras variables.

Relaciones de los atributos

Por lo general, las dependencias se administran directamente con Bazel, que simplemente aplica los requisitos y administra conflictos intrínsecos a la naturaleza de las funciones definidas en la compilación. La especificación de la cadena de herramientas permite restricciones más detalladas para usar directamente dentro de la regla de Starlark que rige la expansión y la compatibilidad de funciones. Debes realizar las siguientes acciones:

Restricción	Descripción
requires = [ feature_set (features = [ 'feature-name-1', 'feature-name-2' ]), ]	A nivel del atributo. Esta función solo se admite si están habilitadas las funciones requeridas especificadas. Por ejemplo, cuando una función solo es compatible en ciertos modos de compilación (`opt`, `dbg` o `fastbuild`). Si "requires" contiene varios atributos "feature_set", se admite la función si se cumple alguno de los "feature_set" (cuando todas las funciones especificadas están habilitadas).
implies = ['feature']	A nivel del atributo. Este atributo implica los atributos especificados. Cuando habilitas una función, también se habilitan de forma implícita todas las funciones que esta implica (es decir, funciona de manera recursiva). También proporciona la capacidad de factorizar subconjuntos comunes de funcionalidad de un conjunto de funciones, como las partes comunes de los limpiadores. Las funciones implícitas no se pueden inhabilitar.
provides = ['feature']	A nivel del atributo. Indica que esta función es una de varias funciones alternativas mutuamente excluyentes. Por ejemplo, todos los limpiadores podrían especificar `provides = ["sanitizer"]`. Esto mejora el manejo de errores, ya que se enumeran las alternativas si el usuario solicita dos o más funciones mutuamente excluyentes a la vez.
with_features = [ with_feature_set( features = ['feature-1'], not_features = ['feature-2'], ), ]	Nivel de conjunto de marcas. Una función puede especificar varios conjuntos de marcas con varios. 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 estén habilitadas todas las funciones del conjunto de `features` especificado y si todas las funciones especificadas en el conjunto `not_features` están inhabilitadas. Si no se especifica `with_features`, el conjunto de marcas se aplicará incondicionalmente para cada acción especificada.

Acciones

Las acciones brindan la flexibilidad de modificar las circunstancias en las que se ejecuta una acción sin suponer cómo se ejecutará. Una 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 se comporta esa herramienta cuando se invoca la acción.

Las funciones hacen referencia a las acciones para indicar a qué acciones de Bazel afectan, ya que estas pueden modificar el gráfico de acciones de Bazel. El proveedor CcToolchainConfigInfo contiene acciones que tienen marcas y herramientas asociadas, como c++-compile. Las marcas se asignan a cada acción mediante la asociación con un componente.

Cada nombre de acción representa un solo tipo de acción que realiza Bazel, como compilación o vinculación. Sin embargo, existe una relación de varios a uno entre las acciones y los tipos de acción de Bazel, en la que un tipo de acción de Bazel hace referencia a una clase de Java que implementa una acción (como CppCompileAction). En particular, las "acciones del ensamblador" y las "acciones del compilador" de la siguiente tabla son CppCompileAction, mientras que las acciones de vínculo son CppLinkAction.

Acciones del ensamblador

Acción	Descripción
`preprocess-assemble`	Ensamblar con el procesamiento previo Por lo general, para archivos `.S`.
`assemble`	Ensamblar 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`	Compila 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, se producirían errores de compilación. Solo se aplica a las cadenas de herramientas que admiten 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`	Vincular una biblioteca compartida que solo contenga fuentes `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 (archivos .a) a través de ar y codifican algunas semánticas en el nombre.

Acción	Descripción
`c++-link-static-library`	Crear una biblioteca estática (archivo)

Acciones de LTO

Acción	Descripción
`lto-backend`	Acción ThinLTO que compila códigos de bits en objetos nativos.
`lto-index`	Acción de ThinLTO que genera un índice global.

Usa action_config

action_config es una struct de Starlark que describe una acción de Bazel especificando la herramienta (binaria) que se invocará durante la acción y los conjuntos de marcas, definidos por los atributos. Estas marcas aplican restricciones a la ejecución de la acción.

El constructor action_config() tiene los siguientes parámetros:

Attribute	Descripción
`action_name`	La acción de Bazel a la que corresponde esta acción. Bazel usa este atributo para descubrir los requisitos de ejecución y de la herramienta por acción.
`tools`	El ejecutable que se invocará. La herramienta que se aplique a la acción será la primera de la lista con un conjunto de atributos que coincida con la configuración correspondiente. Se debe proporcionar un valor predeterminado.
`flag_sets`	Una lista de marcas que se aplican a un grupo de acciones. Es igual que para un atributo.
`env_sets`	Una lista de restricciones de entorno que se aplica a un grupo de acciones. Es igual que para un atributo.

Un action_config puede requerir e implicar otras funciones y action_config según lo dictan las relaciones de atributos que se describieron antes. Este comportamiento es similar al de un componente.

Los últimos dos atributos son redundantes con respecto a los atributos correspondientes de las funciones y se incluyen porque algunas acciones de Bazel requieren ciertas marcas o variables de entorno, y el objetivo es evitar pares action_config+feature necesarios. Por lo general, es preferible compartir una sola función en varios action_config.

No puedes definir más de un action_config con el mismo action_name dentro de la misma cadena de herramientas. De esta manera, se evita la ambigüedad en las rutas de acceso de la herramienta y se aplica la intención detrás de action_config: que las propiedades de una acción se describan con claridad en un solo lugar de la cadena de herramientas.

Cómo usar el constructor de herramientas

Un action_config puede especificar un conjunto de herramientas a través de su parámetro tools. El constructor tool() adopta los siguientes parámetros:

Campo	Descripción
`path`	Es la ruta a la herramienta en cuestión (relativa a la ubicación actual).
`with_features`	Es una lista de conjuntos de atributos, de los cuales se debe cumplir al menos uno para que se aplique esta herramienta.

Para una action_config determinada, una sola tool aplica la ruta de la herramienta y los requisitos de ejecución a la acción de Bazel. Para seleccionar una herramienta, se itera a través del atributo tools en una action_config hasta que se encuentre una herramienta con un conjunto with_feature que coincida con la configuración del componente (consulta Relaciones entre funciones más arriba en esta página para obtener más información). Debes finalizar tus listas de herramientas con una herramienta predeterminada que corresponda a una configuración de funciones vacía.

Ejemplo de uso

Las funciones y las acciones se pueden usar en conjunto para implementar acciones de Bazel con diversas semánticas 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, invocar una herramienta especializada durante la acción de vinculación para crear un archivo dsym comprimido y, luego, descomprimir ese archivo para producir el paquete de aplicación y los archivos .plist consumibles por Xcode.

Con Bazel, este proceso se puede implementar de la siguiente manera, y 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 se puede implementar de manera totalmente diferente en Linux, que usa fission, o en Windows, que produce archivos .pdb. Por ejemplo, la implementación para la generación de símbolos de depuración basada en fission podría verse de la siguiente manera:

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

Marcar grupos

CcToolchainConfigInfo te permite agrupar marcas en grupos que tienen un propósito específico. Puedes especificar una marca usando variables predefinidas dentro del valor de la marca, que el compilador expande cuando agrega la marca al comando de compilación. Por ejemplo:

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

En este caso, el contenido de la marca se reemplazará por la ruta de acceso del archivo de salida 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 abajo, de izquierda a derecha.

En el caso de las marcas que se deben repetir con valores diferentes cuando se agregan al comando de compilación, el grupo de marcas puede iterar variables de tipo list. Por ejemplo, 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 ruta de acceso en la lista include_paths. Todas las marcas (o flag_group) en el cuerpo de una declaración de grupo de marcas se expanden como una unidad. Por ejemplo:

flag_group (
    iterate_over = "include_paths",
    flags = ["-I", "%{include_paths}"],
)

se expande a -I <path> para cada elemento de ruta de acceso en 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 mediante la notación de puntos. Por ejemplo:

flag_group (
    flags = ["-l%{libraries_to_link.name}"],
)

Las estructuras pueden anidarse y también pueden contener secuencias. Para evitar conflictos de nombres y ser explícito, debes especificar la ruta de acceso completa a través de 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 según la presencia de una variable en particular o su campo mediante los atributos expand_if_available, expand_if_not_available, 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 otra información necesaria para configurar correctamente las reglas de C++.

Variables de compilación CcToolchainConfigInfo

La siguiente es una referencia de variables de compilación CcToolchainConfigInfo.

Variable	Acción	Descripción
`source_file`	compile	Archivo fuente para compilar.
`input_file`	strip	Artefacto que se quitará.
`output_file`	compile	Resultado de la compilación
`output_assembly_file`	compile	Archivo de ensamblado emitido. Se aplica solo cuando la acción `compile` emite texto ensamblado, por lo general, cuando se usa la marca `--save_temps`. El contenido es el mismo que para `output_file`.
`output_preprocess_file`	compile	Resultado previamente procesado. Se aplica solo a las acciones de compilación que solo procesan previamente los archivos de origen, por lo general, cuando se usa la marca `--save_temps`. El contenido es el mismo que para `output_file`.
`includes`	compile	Secuencia de archivos que el compilador debe incluir de manera incondicional en la fuente compilada.
`include_paths`	compile	Directorios de secuencias en los que el compilador busca encabezados incluidos mediante `#include<foo.h>` y `#include "foo.h"`
`quote_include_paths`	compile	La secuencia de `-iquote` incluye directorios en los que el compilador busca encabezados incluidos mediante `#include "foo.h"`.
`system_include_paths`	compile	La secuencia de `-isystem` incluye directorios en los que el compilador busca encabezados incluidos mediante `#include <foo.h>`.
`dependency_file`	compile	El archivo de dependencia `.d` generado por el compilador.
`preprocessor_defines`	compile	Secuencia de `defines`, como `--DDEBUG`.
`pic`	compile	Compila la salida como código independiente de la posición.
`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 campos `CROSSTOOL` heredados, como `compiler_flag`, `optional_compiler_flag`, `cxx_flag` y `optional_cxx_flag`.
`user_compile_flags`	compile	Secuencia de marcas del atributo de la regla `copt` o de las marcas `--copt`, `--cxxopt` y `--conlyopt`.
`unfiltered_compile_flags`	compile	Secuencia de marcas del campo `CROSSTOOL` heredado `unfiltered_cxx_flag` o de la función `unfiltered_compile_flags`. Estas no se filtran con el atributo de regla `nocopts`.
`sysroot`		El tipo `sysroot`.
`runtime_library_search_directories`	vínculo	Entradas en la ruta de búsqueda del tiempo de ejecución del vinculador (por lo general, se establecen con la marca `-rpath`).
`library_search_directories`	vínculo	Entradas en la ruta de búsqueda del vinculador (por lo general, se establecen 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 que se usa en Windows con MSVC.
`linker_param_file`	vínculo	Ubicación del archivo de parámetros del vinculador creado por Bazel para superar 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 se debe generar la biblioteca de interfaces.
`interface_library_builder_path`	vínculo	Ruta de acceso a la herramienta del compilador de bibliotecas 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	Ruta de acceso en la que se genera la biblioteca de la interfaz con la herramienta del 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 que provienen del atributo `--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 se debe generar el código PIC/PIE (se pasó la opción de Bazel "--force_pic").
`strip_debug_symbols`	vínculo	La presencia de esta variable indica que se deben quitar los símbolos de depuración.
`is_cc_test`	vínculo	Es verdadera cuando la acción actual es una acción de vinculación `cc_test`; 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á activada. La información de depuración estará en archivos `.dwo` en lugar de archivos `.o`, y el compilador y el vinculador deben saber esto.
`fdo_instrument_path`	compilar, vincular	Ruta de acceso al directorio que almacena el perfil de instrumentación de FDO.
`fdo_profile_path`	compile	Ruta al perfil FDO.
`fdo_prefetch_hints_path`	compile	Ruta de acceso al perfil de carga previa de la caché.
`cs_fdo_instrument_path`	compilar, vincular	Es la ruta de acceso al directorio que almacena el perfil de instrumentación FDO sensible al contexto.

Funciones conocidas

A continuación, se incluye una referencia de las funciones y sus condiciones de activación.

Función	Documentación
`opt \| dbg \| fastbuild`	Está habilitada de forma predeterminada según el 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`	Habilitado si se especifica y habilita la función `supports_fission`, y se especifica el modo de compilación actual en la marca `--fission`.
`supports_start_end_lib`	Si se habilita (y se configura la opción `--start_end_lib`), Bazel no se vinculará a bibliotecas estáticas, sino que usará las opciones del vinculador `--start-lib/--end-lib` para vincular directamente con los objetos. Esto acelera la compilación, ya que Bazel no tiene que compilar bibliotecas estáticas.
`supports_interface_shared_libraries`	Si se habilita (y se configura la opción `--interface_shared_objects`), Bazel vinculará los destinos que tengan `linkstatic` configurado como falso (`cc_test` de forma predeterminada) con las bibliotecas compartidas de la interfaz. Esto agiliza la revinculación incremental.
`supports_dynamic_linker`	Si se habilita, las reglas de C++ sabrán que la cadena de herramientas puede producir bibliotecas compartidas.
`static_link_cpp_runtimes`	Si se habilita, Bazel vinculará el tiempo de ejecución de C++ de forma estática en modo de vinculación estático y de forma dinámica en modo de vinculación dinámica. Los artefactos especificados en los atributos `cc_toolchain.static_runtime_lib` o `cc_toolchain.dynamic_runtime_lib` (según el modo de vinculación) se agregarán a las acciones de vinculación.
`supports_pic`	Si se habilita, la cadena de herramientas sabrá que debe usar objetos PIC para bibliotecas dinámicas. La variable `pic` está presente cuando se necesita la compilación de PIC. Si no está habilitado 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 habilitar, 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án presentes. Consulta la lista completa de funciones a continuación.

Lógica de aplicación de parches para las funciones heredadas

Bazel aplica los siguientes cambios a las funciones de la cadena de herramientas para brindar retrocompatibilidad:

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) a la parte inferior de la cadena de herramientas.
Agrega la función user_compile_flags (si no está presente) a la parte inferior de la cadena de herramientas.
Agrega la función sysroot (si no está presente) a la parte inferior de la cadena de herramientas.
Agrega la función unfiltered_compile_flags (si no está presente) a la parte inferior de la cadena de herramientas.
Agrega la función linker_param_file (si no está presente) a la parte inferior de la cadena de herramientas.
Agrega la función compiler_input_flags (si no está presente) a la parte inferior de la cadena de herramientas.
Agrega la función compiler_output_flags (si no está presente) a la parte inferior de la cadena de herramientas.

Es una larga lista de funciones. El plan es deshacerse de ellos una vez que Crosstool en Starlark esté listo. Para los lectores curiosos, puede ver la implementación en CppActionConfigs y, para las cadenas de herramientas de producción, considera agregar no_legacy_features para hacer que la cadena de herramientas sea más independiente.