Ya comenzó el registro para BazelCon 2024

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

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

Denuncia un problema Ver fuente Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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 funcionamiento.

Bazel necesita saber lo siguiente:

Indica si el compilador admite thinLTO, módulos, vinculación dinámica o PIC (código independiente de la posición).
Rutas de acceso a las herramientas necesarias, como gcc, ld, ar, objcopy, etcétera.
El sistema integrado incluye 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 archivado
Qué marcas usar para los modos de compilación admitidos (opt, dbg, fastbuild)
Haz que el compilador requiera variables específicas.

Si el compilador admite 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 puedes tienes la opción de configurarlo manualmente. Para eso, necesitas una regla de Starlark que proporcione el CcToolchainConfigInfo y debes apuntar el atributo toolchain_config del cc_toolchain a su regla. Para crear el CcToolchainConfigInfo, llama a cc_common.create_cc_toolchain_config_info(). Puedes encontrar constructores de Starlark para todos los structs que necesitarás en el proceso en @rules_cc//cc:cc_toolchain_config_lib.bzl.

Cuando un destino C++ ingresa a la fase de análisis, Bazel selecciona el destino 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 C++ a través de 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 el vinculador
Marcas de configuración que se pasan a través de las opciones --copt/--linkopt
Variables de entorno
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 las bibliotecas binarias del vinculador y de la cadena de herramientas para enviarlas 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 objetivo cc_toolchain_suite en el archivo BUILD y dirige Bazel al objetivo con la opción --crosstool_top.
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 de cc_toolchain_suite.toolchains con --cpu | --compiler. Si Bazel no encuentra una entrada correspondiente, muestra un error.
- Si no se especifica la opción --compiler, Bazel selecciona la entrada correspondiente del atributo cc_toolchain_suite.toolchains solo con --cpu.
- Si no se especifican marcas, Bazel inspecciona el sistema host y selecciona un valor de --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 de marcas, como treat_warnings_as_errors, o interactuar con las reglas de C++ y, además, incluir nuevas acciones de compilación y entradas en 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.

Una función se especifica por nombre, lo que permite la desvinculación completa de la configuración de la regla Starlark 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ó en true.
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 el atributo de la regla features.

Las funciones pueden tener interdependencias, depender de marcas de línea de comandos, de la configuración del archivo BUILD y de 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 la asistencia y la expansión. Debes realizar las siguientes acciones:

Restricción	Descripción
requires = [ feature_set (features = [ 'feature-name-1', 'feature-name-2' ]), ]	A nivel de la función. La función solo es compatible si están habilitadas las funciones requeridas especificadas. Por ejemplo, cuando una función solo es compatible con ciertos modos de compilación (`opt`, `dbg` o `fastbuild`). Si "requires" contiene varios "feature_set", la función es compatible si se cumple alguno de los "feature_set" (cuando se habilitan todas las funciones especificadas).
implies = ['feature']	A nivel de la función. Esta función implica las funciones especificadas. 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 esta función es una de varias funciones alternativas mutuamente excluyentes. Por ejemplo, todos los desinfectantes especificar `provides = ["sanitizer"]`. Esto mejora la administración de errores, ya que enumera 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 configuración de la marca. Un componente 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 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 proporcionan la flexibilidad para modificar las circunstancias en las que se ejecuta una acción 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 solo tipo de acción que realiza Bazel, como la compilación o la vinculación. Sin embargo, existe una relación de varios a uno entre y los tipos de acción 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, se producirán 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`	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 (archivos .a) 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 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 una estructura 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 funciones. Estas marcas aplican restricciones a la acción ejecución.

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

Atributo	Descripción
`action_name`	Es la acción de Bazel a la que corresponde esta acción. Bazel usa este atributo para descubrir la herramienta y los requisitos de ejecución por acción.
`tools`	Es el ejecutable que se invocará. La herramienta que se aplique a la acción será la primera en la lista con un conjunto de atributos que coincida con la configuración de atributos. 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 aplica 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 una función.

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 herramienta predeterminada que corresponda a una configuración de funciones 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 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 que puede consumir 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 se puede implementar de manera completamente diferente para Linux, que usa 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 con variables predefinidas dentro del valor de la marca, que el compilador expande cuando se 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 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. 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 la lista include_paths.

Una variable se puede repetir varias veces. Por ejemplo:

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

se expande a lo siguiente:

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

Las variables pueden corresponder a estructuras a las que se puede acceder con 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. Cómo 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 según la presencia de una variable particular o su campo con 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 otros necesaria para configurar correctamente las reglas de C++.

Variables de compilación de CcToolchainConfigInfo

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

Variable	Acción	Descripción
`source_file`	compile	Archivo de origen para compilar.
`input_file`	strip	Artefacto que se eliminará.
`output_file`	compilar, quitar	Resultado de compilación.
`output_assembly_file`	compile	Archivo de ensamblado emitido. Solo se aplica cuando la acción `compile` emite texto de 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 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	Es la secuencia de archivos que el compilador debe incluir de forma incondicional 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 directorios en los que el compilador busca encabezados incluidos con `#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	Es el archivo de dependencia `.d` que genera el compilador.
`preprocessor_defines`	compile	Es una 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`).
`stripopts`	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 tiempo de ejecución del vinculador (por lo general, se configura con la marca `-rpath`).
`library_search_directories`	vínculo	Entradas en la ruta de búsqueda del vinculador (por lo general, se establece 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 de definición que se usa en Windows con MSVC.
`linker_param_file`	vínculo	Es la ubicación del archivo de parámetros del vinculador que creó 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 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 de compilación `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 se debe generar 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 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á activada. 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	Es la ruta de acceso al perfil de FDO.
`fdo_prefetch_hints_path`	compile	Ruta de acceso al perfil de carga previa de caché.
`cs_fdo_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`	Se habilita de forma predeterminada según el modo de compilación.
`static_linking_mode \| dynamic_linking_mode`	Se habilita de forma predeterminada según el modo de vinculación.
`per_object_debug_info`	Se habilita 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 está habilitada (y se establece la opción `--start_end_lib`), Bazel no vinculará bibliotecas estáticas, sino que usará las opciones del vinculador `--start-lib/--end-lib` para vincular objetos directamente. Esto acelera la compilación, ya que Bazel no tiene que compilar estáticas.
`supports_interface_shared_libraries`	Si está habilitado (y se establece la opción `--interface_shared_objects`), Bazel vinculará los destinos que tengan `linkstatic` establecido como "False" (`cc_test` de forma predeterminada) con las bibliotecas compartidas de la interfaz. Esto hace que la vinculación incremental sea más rápida.
`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 está habilitado, Bazel vinculará el entorno de ejecución de C++ de forma estática en el modo de 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 está habilitada, la cadena de herramientas sabrá usar objetos PIC para bibliotecas dinámicas. La variable "pic" está presente cada vez que se necesita la 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`	Evita que Bazel agregue funciones heredadas a la configuración de C++ cuando esté presente. Consulta la lista completa de funciones a continuación.

Lógica de parcheo de funciones heredadas

Bazel aplica los siguientes cambios a las funciones de la cadena de herramientas para la 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) al final 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) al final 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.

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.