Reglas C y C++

Informar un problema . Ver fuente . Por la noche · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Reglas

• cc_binary
• cc_import
• cc_library
• cc_proto_library
• cc_shared_library
• cc_static_library
• cc_test
• cc_toolchain
• cc_toolchain_suite
• fdo_prefetch_hints
• fdo_profile
• memprof_profile
• propeller_optimize

cc_binary

Ver el código fuente de la regla

cc_binary(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, dynamic_deps, env, exec_compatible_with, exec_properties, features, hdrs_check, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local_defines, malloc, module_interfaces, nocopts, output_licenses, reexport_deps, restricted_to, stamp, tags, target_compatible_with, testonly, toolchains, visibility, win_def_file)

Produce un objeto binario ejecutable.

El name del destino debe ser el mismo que el nombre del que es el punto de entrada principal de la aplicación (menos la extensión). Por ejemplo, si tu punto de entrada está en main.cc, entonces tu nombre debe ser main.

Destinos de salida implícitos

• name.stripped (solo se compila si se solicita de forma explícita): Es un fragmento versión del objeto binario. Se ejecuta strip -g en el objeto binario para quitar la depuración. símbolos. Se pueden proporcionar opciones adicionales de barra en la línea de comandos mediante --stripopt=-foo
• name.dwp (solo se compila si se solicita explícitamente): Si La fisión está habilitada: una depuración archivo del paquete de información adecuado para depurar objetos binarios implementados de manera remota. De lo contrario, un archivo vacío.

Argumentos

Atributos
name	Nombre: obligatorio. Un nombre único para este destino.
deps	Lista de etiquetas; el valor predeterminado es [] Es la lista de otras bibliotecas que se vincularán al objetivo binario. Pueden ser cc_library o objc_library. objetivos. También se permite colocar secuencias de comandos del vinculador (.lds) en dependencias y hacer referencia a ellas en linkopts.
srcs	Lista de etiquetas; el valor predeterminado es [] Es la lista de archivos C y C++ que se procesan para crear el destino de la biblioteca. Estos son archivos de origen y encabezado C/C++, ya sean no generados (fuente normal) código) o que se generó. Se harán los cambios en todos los archivos .cc, .c y .cpp compilarse. Estos pueden ser archivos generados: si un archivo nombrado se encuentra en la outs de otra regla, esta cc_library dependerá automáticamente de esa otra regla. Los archivos ensambladores puros (.s, .asm) no se procesan previamente y, por lo general, se compilan con el ensamblador. Los archivos de ensamblado previamente procesados (.S) se procesan previamente y, por lo general, se compilan con el compilador C/C++. No se compilará un archivo .h, pero estará disponible para la inclusión por fuentes en esta regla. Tanto .cc como Los archivos .h pueden incluir directamente los encabezados enumerados en estos srcs o en la hdrs de esta regla, o cualquiera lista en el argumento deps. Todos los archivos #included deben mencionarse en el Atributo hdrs de este valor o cc_library al que se hace referencia reglas de firewall, o deben aparecer en srcs si son privadas a esta biblioteca. Consulta "Verificación de inclusión de encabezados" para obtener una descripción más detallada. Los archivos .so, .lo y .a tienen las siguientes características: archivos compilados previamente. Es posible que tu biblioteca tenga estos srcs si usa código de terceros para el cual no lo hacemos tienen código fuente. Si el atributo srcs incluye la etiqueta de otra regla, cc_library usará los archivos de salida de esa regla como archivos de origen para lo siguiente: compilar. Esto es útil para la generación única de código fuente (para más de usar, es mejor implementar una clase de regla de Starlark y usar la clase cc_common API) Tipos de archivos srcs permitidos: Archivos de origen C y C++: .c, .cc, .cpp, .cxx, .c++ y .C Archivos de encabezado C y C++: .h, .hh, .hpp, .hxx, .inc, .inl y .H Ensamblador con preprocesador en C: .S Archivo: .a, .pic.a "Vincular siempre" biblioteca: .lo, .pic.lo Biblioteca compartida, con o sin versiones: .so, .so.version Archivo de objeto: .o, .pic.o ... y cualquier regla que genere esos archivos (p.ej., cc_embed_data). Las diferentes extensiones denotan diferentes lenguajes de programación en de acuerdo con la convención de GCC.
data	Lista de etiquetas; el valor predeterminado es [] Es la lista de archivos que necesita esta biblioteca en el entorno de ejecución. Consulta los comentarios generales sobre data en Atributos típicos definidos por la mayoría de las reglas de compilación. Si data es el nombre de un archivo generado, este cc_library depende automáticamente de la regla . Si data es el nombre de una regla, este La regla cc_library depende automáticamente de ella, y los outs de esa regla se agregan los archivos de datos de cc_library. Tu código C++ puede acceder a estos archivos de datos de la siguiente manera: const std::string path = devtools_build::GetDataDependencyFilepath( "my/test/data/file");
additional_linker_inputs	Lista de etiquetas; el valor predeterminado es [] Pasa estos archivos al comando del vinculador de C++. Por ejemplo, aquí se pueden proporcionar archivos .res compilados de Windows para incorporarlos en el objeto binario.
copts	Lista de cadenas; el valor predeterminado es [] Agrega estas opciones al comando de compilación de C++. Con la sustitución "Make variable" y Asignación de token de shell de Bourne. Cada cadena de este atributo se agrega en el orden determinado a COPTS antes de compilando el objetivo binario. Las marcas solo tienen efecto en la compilación de este destino, no sus dependencias, por lo que debes tener cuidado con los archivos de encabezado que se incluyan en otro lugar. Todas las rutas de acceso deben estar relacionadas con el lugar de trabajo, no con el paquete actual. Este atributo no debería ser necesario fuera de third_party. Si el paquete declara la función no_copts_tokenization: La asignación de token de shell de Bourne se aplica solo a las cadenas. que constan de un solo “Marca” de salida.
defines	Lista de cadenas; el valor predeterminado es [] Lista de definiciones para agregar a la línea de compilación. Sujeto a "Marca" de variable y Asignación de token de shell de Bourne. Cada cadena, que debe constar de un solo token de shell de Bourne, se antepone -D y se agrega a la línea de comandos de compilación de este destino, así como a cada regla que depende de él. Ten mucho cuidado, ya que esto podría haber efectos de largo alcance. Si tienes dudas, agrega valores definidos a local_defines en su lugar.
dynamic_deps	Lista de etiquetas; el valor predeterminado es [] Estas son otras dependencias de cc_shared_library de las que depende el destino actual. La implementación de cc_shared_library usará la lista de dynamic_deps (de forma transitiva, es decir, también la dynamic_deps del objeto el dynamic_deps del objetivo actual) para decidir en qué cc_libraries de No se deben vincular los deps transitivos porque ya se proporcionaron por un cc_shared_library diferente.
hdrs_check	String; el valor predeterminado es "" Obsoleto, no-op.
includes	Lista de cadenas; el valor predeterminado es [] Lista de dir de inclusión que se agregarán a la línea de compilación. Sujeto a la sustitución "Make variable". A cada cadena se le antepone la ruta del paquete y se pasa a la cadena de herramientas de C++ para de expansión mediante el comando MÚLTIPLE Una cadena de herramientas que se ejecuta en un sistema POSIX con definiciones de atributos típicas producirán -isystem path_to_package/include_entry Solo debe usarse para bibliotecas de terceros que no cumplen con el estilo de redacción de Google. A diferencia de COPTS, estas marcas se agregan a esta regla. y cada regla que depende de él. (Nota: No depende de las reglas de las que depende). Sé esto puede tener efectos de largo alcance. Si tienes dudas, agrega “-I” a COPTS. Las rutas de acceso include agregadas incluirán archivos generados, así como en el árbol de fuentes.
link_extra_lib	Etiqueta; el valor predeterminado es "@bazel_tools//tools/cpp:link_extra_lib" Controla la vinculación de bibliotecas adicionales. De forma predeterminada, los objetos binarios de C++ están vinculados con //tools/cpp:link_extra_lib. que, de forma predeterminada, depende de la marca de etiqueta //tools/cpp:link_extra_libs. Si no se configura la marca, esta biblioteca estará vacía de forma predeterminada. Configura la marca de la etiqueta permite vincular dependencias opcionales, como anulaciones de símbolos débiles, interceptores para funciones de bibliotecas compartidas o bibliotecas de tiempo de ejecución especiales (para reemplazos de malloc, preferir malloc o --custom_malloc). Establecer este atributo en None inhabilita este comportamiento.
linkopts	Lista de cadenas; el valor predeterminado es [] Agrega estas marcas al comando del vinculador de C++. Sujeto a "Marca" de variable, la asignación de token de shell de Bourne y expansión de etiquetas. Cada cadena de este atributo se agrega a LINKOPTS antes de que vincula el objetivo binario. Cada elemento de esta lista que no comienza con $ o - se se supone que es la etiqueta de un objetivo en deps. El La lista de archivos que genera ese destino se agrega al vinculador opciones de estado. Se informa un error si la etiqueta no es válida o no se declaró en deps.
linkshared	Booleano; el valor predeterminado es False Crea una biblioteca compartida. Para habilitar este atributo, incluye linkshared=True en tu regla. De forma predeterminada esta opción está desactivada. La presencia de esta marca significa que la vinculación se produce con la marca -shared. en gcc, y la biblioteca compartida resultante es adecuada para la carga en ejemplo, un programa de Java. Sin embargo, para fines de compilación, nunca se vinculará con binario dependiente, ya que se supone que las bibliotecas compartidas cc_binary solo las cargan manualmente otros programas, por lo que No debe considerarse un sustituto de cc_library. . Por motivos de escalabilidad, recomendamos evitar este enfoque por completo simplemente permitiendo que java_library dependa de las reglas cc_library en su lugar. Si especificas linkopts=['-static'] y linkshared=True, obtienes una sola unidad completamente independiente. Si especificas ambos linkstatic=True y linkshared=True, obtienes un solo clic, mayormente unidad independiente.
linkstatic	Booleano; el valor predeterminado es True Para cc_binary y cc_test: vincula el objeto binario en estático . Para cc_library.link_static: consulta a continuación. De forma predeterminada, esta opción está activada para cc_binary y desactivada para el resto. Si se habilita y es un objeto binario o de prueba, esta opción le indica a la herramienta de compilación que se vincule en Usa .a en lugar de .so para las bibliotecas de usuario siempre que sea posible. Bibliotecas de sistema como libc (pero no las bibliotecas en tiempo de ejecución C/C++, (consulta a continuación) siguen vinculadas de forma dinámica, al igual que las bibliotecas para las cuales no hay una biblioteca estática. Por lo tanto, el ejecutable resultante seguirá siendo dinámico vinculadas, por lo que solo son mayormente estáticas. En realidad, existen tres formas diferentes de vincular un archivo ejecutable: STATIC con el atributo full_static_link, en el que todo está vinculado estáticamente; p.ej., “gcc -static foo.o libbar.a libbaz.a -lm”. Este modo se habilita especificando fully_static_link en el atributo features. ESTÁTICA, en la que todas las bibliotecas de usuario están vinculadas estáticamente (si un elemento está disponible), pero donde las bibliotecas del sistema (excluidas las bibliotecas en tiempo de ejecución C/C++) se vinculan de forma dinámica; p.ej., “gcc foo.o libfoo.a libbaz.a -lm”. Para habilitar este modo, debes especificar linkstatic=True. DINÁMICA, en la que todas las bibliotecas se vinculan de forma dinámica (si se trata de una versión disponibles), p.ej., “gcc foo.o libfoo.so libbaz.so -lm”. Para habilitar este modo, debes especificar linkstatic=False. Si el atributo linkstatic o fully_static_link en features se usa fuera de //third_party incluya un comentario cerca de la regla para explicar el motivo. El atributo linkstatic tiene un significado diferente si se usa en un Regla cc_library(). Para una biblioteca C++, linkstatic=True indica que solo Se permite la vinculación estática, por lo que no se producirá un .so. linkstatic=Falso hace no impide la creación de bibliotecas estáticas. El atributo sirve para controlar el la creación de bibliotecas dinámicas. Debería haber muy poco código compilado con linkstatic=False en producción. Si es linkstatic=False, la herramienta de compilación creará symlinks a depende de bibliotecas compartidas en el área *.runfiles.
local_defines	Lista de cadenas; el valor predeterminado es [] Lista de definiciones para agregar a la línea de compilación. Sujeto a "Marca" de variable y Asignación de token de shell de Bourne. Cada cadena, que debe constar de un solo token de shell de Bourne, se antepone -D y se agrega a la línea de comandos de compilación para este destino, pero no a sus dependientes.
malloc	Etiqueta; el valor predeterminado es "@bazel_tools//tools/cpp:malloc" Anula la dependencia predeterminada en malloc. De forma predeterminada, los objetos binarios de C++ están vinculados con //tools/cpp:malloc. que es una biblioteca vacía, por lo que el objeto binario termina usando libc malloc. Esta etiqueta debe hacer referencia a un cc_library. Si la compilación es para una compilación que no es de C++ regla, esta opción no tiene efecto. El valor de este atributo se ignora si Se especifica linkshared=True.
module_interfaces	Lista de etiquetas; el valor predeterminado es [] La lista de archivos se considera interfaz de módulos de C++20. C++ Standard no tiene restricciones sobre la extensión de archivo de la interfaz del módulo. Usa cppm de Clang GCC puede usar cualquier extensión de archivo fuente. Uso de ixx de MSVC El uso está protegido por la marca --experimental_cpp_modules
nocopts	String; el valor predeterminado es "" Se quitaron las opciones coincidentes del comando de compilación de C++. Sujeto a "Marca" de variables. El valor de este atributo se interpreta como una expresión regular. Cualquier COPTS preexistente que coincida con esta expresión regular (incluidos los valores especificados explícitamente en el atributo copts de la regla) se quitará de COPTS a los efectos de compilar esta regla. Este atributo no debe ser necesario ni usarse fuera de third_party. Los valores no se procesan de ninguna manera que no sea con la sustitución de variables.
reexport_deps	Lista de etiquetas; el valor predeterminado es []
stamp	Número entero; el valor predeterminado es -1 Establece si se debe codificar información de compilación en el objeto binario. Valores posibles: stamp = 1: Siempre marca la información de la compilación en el objeto binario, incluso en --nostamp. Este de configuración debe evitarse, ya que puede finalizar el almacenamiento en caché remoto binario y las acciones descendentes que dependan de él. stamp = 0: Siempre reemplaza la información de compilación por valores constantes. Esta brinda un buen almacenamiento en caché de resultados de compilación. stamp = -1: la incorporación de la información de la compilación está controlada por el --[no]stamp. Los objetos binarios sellados no se vuelven a compilar, a menos que cambien sus dependencias.
win_def_file	Etiqueta; el valor predeterminado es None El archivo DEF de Windows que se pasará al vinculador. Este atributo solo debe usarse cuando Windows es la plataforma de destino. Se puede usar para exportar símbolos durante la vinculación de una biblioteca compartida

cc_import

Ver el código fuente de la regla

cc_import(name, deps, data, hdrs, alwayslink, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, includes, interface_library, linkopts, objects, pic_objects, pic_static_library, restricted_to, shared_library, static_library, system_provided, tags, target_compatible_with, testonly, toolchains, visibility)

Las reglas cc_import permiten a los usuarios importar bibliotecas C/C++ precompiladas.

Estos son los casos de uso típicos:
1) Vincula una biblioteca estática

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  static_library = "libmylib.a",
  # If alwayslink is turned on,
  # libmylib.a will be forcely linked into any binary that depends on it.
  # alwayslink = 1,
)

2) Cómo vincular una biblioteca compartida (Unix)

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  shared_library = "libmylib.so",
)

3) Cómo vincular una biblioteca compartida con una biblioteca de interfaz

En Unix:

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  # libmylib.ifso is an interface library for libmylib.so which will be passed to linker
  interface_library = "libmylib.ifso",
  # libmylib.so will be available for runtime
  shared_library = "libmylib.so",
)

En Windows:

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  # mylib.lib is an import library for mylib.dll which will be passed to linker
  interface_library = "mylib.lib",
  # mylib.dll will be available for runtime
  shared_library = "mylib.dll",
)

4) Vincula una biblioteca compartida con system_provided=True

En Unix:

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  interface_library = "libmylib.ifso", # Or we can also use libmylib.so as its own interface library
  # libmylib.so is provided by system environment, for example it can be found in LD_LIBRARY_PATH.
  # This indicates that Bazel is not responsible for making libmylib.so available.
  system_provided = 1,
)

En Windows:

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  # mylib.lib is an import library for mylib.dll which will be passed to linker
  interface_library = "mylib.lib",
  # mylib.dll is provided by system environment, for example it can be found in PATH.
  # This indicates that Bazel is not responsible for making mylib.dll available.
  system_provided = 1,
)

5) Cómo vincular a bibliotecas estáticas o compartidas

En Unix:

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  static_library = "libmylib.a",
  shared_library = "libmylib.so",
)

En Windows:

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  static_library = "libmylib.lib", # A normal static library
  interface_library = "mylib.lib", # An import library for mylib.dll
  shared_library = "mylib.dll",
)

El resto es el mismo en Unix y Windows:

# first will link to libmylib.a (or libmylib.lib)
cc_binary(
  name = "first",
  srcs = ["first.cc"],
  deps = [":mylib"],
  linkstatic = 1, # default value
)

# second will link to libmylib.so (or libmylib.lib)
cc_binary(
  name = "second",
  srcs = ["second.cc"],
  deps = [":mylib"],
  linkstatic = 0,
)

cc_import admite un atributo de inclusión. Por ejemplo:

cc_import(
  name = "curl_lib",
  hdrs = glob(["vendor/curl/include/curl/*.h"]),
  includes = ["vendor/curl/include"],
  shared_library = "vendor/curl/lib/.libs/libcurl.dylib",
)

Argumentos

Atributos
name	Nombre: obligatorio. Un nombre único para este destino.
deps	Lista de etiquetas; el valor predeterminado es [] Es la lista de otras bibliotecas de las que depende el destino. Consulta los comentarios generales sobre deps en Atributos típicos definidos por la mayoría de las reglas de compilación.
hdrs	Lista de etiquetas; el valor predeterminado es [] La lista de archivos de encabezado publicados por esta biblioteca precompilada para que las fuentes la incluyan directamente en reglas dependientes.
alwayslink	Booleano; el valor predeterminado es False Si es 1, cualquier objeto binario que depende (directa o indirectamente) de este C++ ya compilada se vincularán con todos los archivos de objetos archivados en la biblioteca estática incluso si algunos no contienen símbolos a los que el binario hace referencia. Esto es útil si no se llama explícitamente a tu código en el objeto binario, p.ej., si tu código se registra para recibir alguna devolución de llamada proporcionados por algún servicio. Si Alwayslink no funciona con VS 2017 en Windows, se debe a un problema conocido, actualiza tu versión de VS 2017 a la más reciente.
includes	Lista de cadenas; el valor predeterminado es [] Lista de dir de inclusión que se agregarán a la línea de compilación. Sujeto a la sustitución "Make variable". A cada cadena se le antepone la ruta del paquete y se pasa a la cadena de herramientas de C++ para de expansión mediante el comando MÚLTIPLE Una cadena de herramientas que se ejecuta en un sistema POSIX con definiciones de atributos típicas producirán -isystem path_to_package/include_entry Solo debe usarse para bibliotecas de terceros que no cumplen con el estilo de redacción de Google. A diferencia de COPTS, estas marcas se agregan a esta regla. y cada regla que depende de él. (Nota: No depende de las reglas de las que depende). Sé esto puede tener efectos de largo alcance. Si tienes dudas, agrega “-I” a COPTS. La ruta de acceso include predeterminada no incluye archivos. Si necesitas #include un encabezado generado , enuméralo en srcs.
interface_library	Etiqueta; el valor predeterminado es None Una biblioteca de interfaz única para vincular la biblioteca compartida. Tipos de archivos permitidos: .ifso, .tbd, .lib, .so o .dylib
linkopts	Lista de cadenas; el valor predeterminado es [] Agrega estas marcas al comando del vinculador de C++. Sujeto a "Marca" de variable, la asignación de token de shell de Bourne y expansión de etiquetas. Cada cadena de este atributo se agrega a LINKOPTS antes de que vincula el objetivo binario. Cada elemento de esta lista que no comienza con $ o - se se supone que es la etiqueta de un objetivo en deps. El La lista de archivos que genera ese destino se agrega al vinculador opciones de estado. Se informa un error si la etiqueta no es válida o no se declaró en deps.
objects	Lista de etiquetas; el valor predeterminado es []
pic_objects	Lista de etiquetas; el valor predeterminado es []
pic_static_library	Etiqueta; el valor predeterminado es None
shared_library	Etiqueta; el valor predeterminado es None Una única biblioteca compartida precompilada Bazel se asegura de que esté disponible para el binario que depende de él durante el tiempo de ejecución. Tipos de archivos permitidos: .so, .dll o .dylib
static_library	Etiqueta; el valor predeterminado es None Una única biblioteca estática precompilada Tipos de archivos permitidos: .a, .pic.a o .lib
system_provided	Booleano; el valor predeterminado es False Si es 1, indica que el sistema proporciona la biblioteca compartida requerida en el tiempo de ejecución. En este caso, se debe especificar interface_library y El campo shared_library debe estar vacío.

cc_library

Ver el código fuente de la regla

cc_library(name, deps, srcs, data, hdrs, additional_compiler_inputs, additional_linker_inputs, alwayslink, compatible_with, copts, defines, deprecation, distribs, exec_compatible_with, exec_properties, features, hdrs_check, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, module_interfaces, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)

Usa cc_library() para las bibliotecas compiladas con C++. El resultado es .so, .lo o .a, según lo que se necesite.

Si compilas algo con vinculación estática que depende Un cc_library, el resultado de una regla de biblioteca dependiente es el archivo .a. Si especificas alwayslink=True, obtendrás el archivo .lo.

El nombre real del archivo de salida es libfoo.so para la biblioteca compartida, donde foo es el nombre de la regla. El otros tipos de bibliotecas terminan con .lo y .a, respectivamente. Si necesitas un nombre específico de biblioteca compartida, por Por ejemplo, para definir un módulo de Python, usa una genrule a fin de copiar la biblioteca con el nombre deseado.

Verificación de inclusión de encabezado

Todos los archivos de encabezado que se utilizan en la compilación se deben declarar en las reglas hdrs o srcs de cc_*. Esto se aplica de manera forzosa.

Para las reglas cc_library, los encabezados en hdrs comprenden las interfaz pública de la biblioteca y se pueden incluir directamente a partir de los archivos en hdrs y srcs de la biblioteca así como de los archivos en hdrs y srcs de cc_* reglas que enumeran la biblioteca en su deps. Los encabezados de srcs solo deben incluirse directamente desde los archivos en hdrs y srcs de la propia biblioteca. Cuándo decidir si colocar un encabezado en hdrs o srcs debe preguntar si desea que los consumidores incluirlo directamente. Esta es más o menos la misma decisión que entre la visibilidad de public y private en los lenguajes de programación.

Las reglas cc_binary y cc_test no tienen un interfaz, por lo que tampoco tienen un atributo hdrs. Todos los encabezados que pertenecen al objeto binario o la prueba directamente deben estar enumerados en srcs

Para ilustrar estas reglas, mira el siguiente ejemplo.

cc_binary(
    name = "foo",
    srcs = [
        "foo.cc",
        "foo.h",
    ],
    deps = [":bar"],
)

cc_library(
    name = "bar",
    srcs = [
        "bar.cc",
        "bar-impl.h",
    ],
    hdrs = ["bar.h"],
    deps = [":baz"],
)

cc_library(
    name = "baz",
    srcs = [
        "baz.cc",
        "baz-impl.h",
    ],
    hdrs = ["baz.h"],
)

Las inclusiones directas permitidas en este ejemplo se enumeran en la siguiente tabla. Por ejemplo, a foo.cc se le permite Incluyen foo.h y bar.h, pero no baz.h.

Incluyendo archivo	Inclusiones permitidas
foo.h	bar.h
foo.cc	foo.h bar.h
bar.h	bar-impl.h baz.h
bar-impl.h	bar.h baz.h
bar.cc	bar.h bar-impl.h baz.h
baz.h	baz-impl.h
baz-impl.h	baz.h
baz.cc	baz.h baz-impl.h

Las reglas de verificación de inclusión solo se aplican a las solicitudes directas inclusiones. En el ejemplo anterior, se permite que foo.cc incluir bar.h, que puede incluir baz.h, que en giro está permitido incluir baz-impl.h. Técnicamente, el La compilación de un archivo .cc puede incluir de forma transitiva cualquier encabezado en el archivo hdrs o srcs en cualquier cc_library en el cierre transitivo deps En En este caso, el compilador puede leer baz.h y baz-impl.h. cuando se compila foo.cc, pero foo.cc no debe contienen #include "baz.h". Para que eso sea permitido, baz se debe agregar a deps de foo.

Bazel depende de la compatibilidad con la cadena de herramientas para aplicar las reglas de verificación de inclusión. La función layering_check debe ser compatible con la cadena de herramientas. y solicitados de forma explícita, por ejemplo, a través de la la marca de línea de comandos de --features=layering_check o la Parámetro features de la función package. Las cadenas de herramientas que proporciona Bazel solo admiten esta función con Clang en Unix y macOS.

Ejemplos

Usamos la marca alwayslink para forzar la vinculación del vinculador. aunque el código binario principal no haga referencia a él.

cc_library(
    name = "ast_inspector_lib",
    srcs = ["ast_inspector_lib.cc"],
    hdrs = ["ast_inspector_lib.h"],
    visibility = ["//visibility:public"],
    deps = ["//third_party/llvm/llvm/tools/clang:frontend"],
    # alwayslink as we want to be able to call things in this library at
    # debug time, even if they aren't used anywhere in the code.
    alwayslink = 1,
)

El siguiente ejemplo proviene de third_party/python2_4_3/BUILD Parte del código usa la biblioteca dl (para cargar otra biblioteca dinámica), por lo que este especifica la opción de vínculo -ldl para vincular la dl.

cc_library(
    name = "python2_4_3",
    linkopts = [
        "-ldl",
        "-lutil",
    ],
    deps = ["//third_party/expat"],
)

El siguiente ejemplo proviene de third_party/kde/BUILD. Mantenemos en el depósito los archivos .so compilados previamente. Los archivos de encabezado se encuentran en un subdirectorio llamado include.

cc_library(
    name = "kde",
    srcs = [
        "lib/libDCOP.so",
        "lib/libkdesu.so",
        "lib/libkhtml.so",
        "lib/libkparts.so",
        ...more .so files...,
    ],
    includes = ["include"],
    deps = ["//third_party/X11"],
)

El siguiente ejemplo proviene de third_party/gles/BUILD. El código de terceros suele necesitar un poco de defines y linkopts

cc_library(
    name = "gles",
    srcs = [
        "GLES/egl.h",
        "GLES/gl.h",
        "ddx.c",
        "egl.c",
    ],
    defines = [
        "USE_FLOAT",
        "__GL_FLOAT",
        "__GL_COMMON",
    ],
    linkopts = ["-ldl"],  # uses dlopen(), dl library
    deps = [
        "es",
        "//third_party/X11",
    ],
)

Argumentos

Atributos
name	Nombre: obligatorio. Un nombre único para este destino.
deps	Lista de etiquetas; el valor predeterminado es [] Es la lista de otras bibliotecas de las que depende la biblioteca objetivo. Estos pueden ser objetivos de cc_library o objc_library. Consulta los comentarios generales sobre deps en Atributos típicos definidos por la mayoría de las reglas de compilación. Estos deberían ser nombres de reglas de la biblioteca C++. Cuando compilas un objeto binario que vincula la biblioteca de esta regla, también vincularás las bibliotecas en deps. A pesar de las “dependencias” nombre, no todos los clientes de esta biblioteca pertenecen aquí. Las dependencias de datos del entorno de ejecución pertenecen a data. Los archivos de origen generados por otras reglas pertenecen a srcs. Para vincular una biblioteca de terceros precompilada, agrega el nombre a srcs en su lugar. Para depender de un elemento sin vincularlo a esta biblioteca, agrega su nombre a la data en su lugar.
srcs	Lista de etiquetas; el valor predeterminado es [] Es la lista de archivos C y C++ que se procesan para crear el destino de la biblioteca. Estos son archivos de origen y encabezado C/C++, ya sean no generados (fuente normal) código) o que se generó. Se harán los cambios en todos los archivos .cc, .c y .cpp compilarse. Estos pueden ser archivos generados: si un archivo nombrado se encuentra en la outs de otra regla, esta cc_library dependerá automáticamente de esa otra regla. Los archivos ensambladores puros (.s, .asm) no se procesan previamente y, por lo general, se compilan con el ensamblador. Los archivos de ensamblado previamente procesados (.S) se procesan previamente y, por lo general, se compilan con el compilador C/C++. No se compilará un archivo .h, pero estará disponible para la inclusión por fuentes en esta regla. Tanto .cc como Los archivos .h pueden incluir directamente los encabezados enumerados en estos srcs o en la hdrs de esta regla, o cualquiera lista en el argumento deps. Todos los archivos #included deben mencionarse en el Atributo hdrs de este valor o cc_library al que se hace referencia reglas de firewall, o deben aparecer en srcs si son privadas a esta biblioteca. Consulta "Verificación de inclusión de encabezados" para obtener una descripción más detallada. Los archivos .so, .lo y .a tienen las siguientes características: archivos compilados previamente. Es posible que tu biblioteca tenga estos srcs si usa código de terceros para el cual no lo hacemos tienen código fuente. Si el atributo srcs incluye la etiqueta de otra regla, cc_library usará los archivos de salida de esa regla como archivos de origen para lo siguiente: compilar. Esto es útil para la generación única de código fuente (para más de usar, es mejor implementar una clase de regla de Starlark y usar la clase cc_common API) Tipos de archivos srcs permitidos: Archivos de origen C y C++: .c, .cc, .cpp, .cxx, .c++ y .C Archivos de encabezado C y C++: .h, .hh, .hpp, .hxx, .inc, .inl y .H Ensamblador con preprocesador en C: .S Archivo: .a, .pic.a "Vincular siempre" biblioteca: .lo, .pic.lo Biblioteca compartida, con o sin versiones: .so, .so.version Archivo de objeto: .o, .pic.o ... y cualquier regla que genere esos archivos (p.ej., cc_embed_data). Las diferentes extensiones denotan diferentes lenguajes de programación en de acuerdo con la convención de GCC.
data	Lista de etiquetas; el valor predeterminado es [] Es la lista de archivos que necesita esta biblioteca en el entorno de ejecución. Consulta los comentarios generales sobre data en Atributos típicos definidos por la mayoría de las reglas de compilación. Si data es el nombre de un archivo generado, este cc_library depende automáticamente de la regla . Si data es el nombre de una regla, este La regla cc_library depende automáticamente de ella, y los outs de esa regla se agregan los archivos de datos de cc_library. Tu código C++ puede acceder a estos archivos de datos de la siguiente manera: const std::string path = devtools_build::GetDataDependencyFilepath( "my/test/data/file");
hdrs	Lista de etiquetas; el valor predeterminado es [] La lista de archivos de encabezado publicados por esta biblioteca para que la incluyan directamente las fuentes en las reglas dependientes. Esta es la ubicación más recomendable para declarar archivos de encabezado que describen la interfaz de la biblioteca. Estos encabezados tendrán disponibles para que las incluyan las fuentes en esta regla o en reglas dependientes. Los encabezados que no sean incluidos por un cliente de esta biblioteca deben ser en el atributo srcs, incluso si están se incluye en un encabezado publicado. Consulta "Inclusión de encabezados" verificación" para obtener una descripción más detallada. Tipos de archivos headers permitidos: .h, .hh, .hpp, .hxx
additional_compiler_inputs	Lista de etiquetas; el valor predeterminado es [] Cualquier archivo adicional que quieras pasar a la línea de comandos del compilador, como sanitizer listas de elementos ignorados, por ejemplo. Los archivos especificados aquí se pueden utilizar en copias con la función $(location).
additional_linker_inputs	Lista de etiquetas; el valor predeterminado es [] Pasa estos archivos al comando del vinculador de C++. Por ejemplo, aquí se pueden proporcionar archivos .res compilados de Windows para incorporarlos en el objeto binario.
alwayslink	Booleano; el valor predeterminado es False Si es 1, cualquier objeto binario que depende (directa o indirectamente) de este C++ biblioteca vinculará todos los archivos de objeto de los archivos enumerados en srcs, incluso si algunos no contienen símbolos a los que hace referencia el objeto binario. Esto es útil si no se llama explícitamente a tu código en el objeto binario, p.ej., si tu código se registra para recibir alguna devolución de llamada proporcionados por algún servicio. Si Alwayslink no funciona con VS 2017 en Windows, se debe a un problema conocido, actualiza tu versión de VS 2017 a la más reciente.
copts	Lista de cadenas; el valor predeterminado es [] Agrega estas opciones al comando de compilación de C++. Con la sustitución "Make variable" y Asignación de token de shell de Bourne. Cada cadena de este atributo se agrega en el orden determinado a COPTS antes de compilando el objetivo binario. Las marcas solo tienen efecto en la compilación de este destino, no sus dependencias, por lo que debes tener cuidado con los archivos de encabezado que se incluyan en otro lugar. Todas las rutas de acceso deben estar relacionadas con el lugar de trabajo, no con el paquete actual. Este atributo no debería ser necesario fuera de third_party. Si el paquete declara la función no_copts_tokenization: La asignación de token de shell de Bourne se aplica solo a las cadenas. que constan de un solo “Marca” de salida.
defines	Lista de cadenas; el valor predeterminado es [] Lista de definiciones para agregar a la línea de compilación. Sujeto a "Marca" de variable y Asignación de token de shell de Bourne. Cada cadena, que debe constar de un solo token de shell de Bourne, se antepone -D y se agrega a la línea de comandos de compilación de este destino, así como a cada regla que depende de él. Ten mucho cuidado, ya que esto podría haber efectos de largo alcance. Si tienes dudas, agrega valores definidos a local_defines en su lugar.
hdrs_check	String; el valor predeterminado es "" Obsoleto, no-op.
implementation_deps	Lista de etiquetas; el valor predeterminado es [] Es la lista de otras bibliotecas de las que depende la biblioteca objetivo. Desmarcar Me gusta con deps, los encabezados y las rutas de acceso de inclusión de estas bibliotecas (y todas sus dependencias transitivas) solo se usan para compilar esta biblioteca, no las bibliotecas que dependen de él. Las bibliotecas especificadas con implementation_deps siguen vinculadas en objetivos binarios que dependen de esta biblioteca. Por ahora, el uso se limita a cc_bibliotecas y está protegido por la función experimental --experimental_cc_implementation_deps
include_prefix	String; el valor predeterminado es "" El prefijo que se agregará a las rutas de acceso de los encabezados de esta regla. Cuando se establece, se puede acceder a los encabezados en el atributo hdrs de esta regla arroba es el valor de este atributo antepuesto a su ruta de acceso relativa del repositorio. Se quitó el prefijo del atributo strip_include_prefix antes de este se agregó el prefijo. Este atributo solo es legal según las third_party.
includes	Lista de cadenas; el valor predeterminado es [] Lista de dir de inclusión que se agregarán a la línea de compilación. Sujeto a la sustitución "Make variable". A cada cadena se le antepone la ruta del paquete y se pasa a la cadena de herramientas de C++ para de expansión mediante el comando MÚLTIPLE Una cadena de herramientas que se ejecuta en un sistema POSIX con definiciones de atributos típicas producirán -isystem path_to_package/include_entry Solo debe usarse para bibliotecas de terceros que no cumplen con el estilo de redacción de Google. A diferencia de COPTS, estas marcas se agregan a esta regla. y cada regla que depende de él. (Nota: No depende de las reglas de las que depende). Sé esto puede tener efectos de largo alcance. Si tienes dudas, agrega “-I” a COPTS. Las rutas de acceso include agregadas incluirán archivos generados, así como en el árbol de fuentes.
linkopts	Lista de cadenas; el valor predeterminado es [] Consulta cc_binary.linkopts. El atributo linkopts también se aplica a cualquier destino que depende, directa o indirectamente, de esta biblioteca a través de deps atributos (o mediante otros atributos que se tratan de manera similar): el malloc de cc_binary). Dependencia Los vínculos optativos tienen prioridad sobre los dependientes (p.ej., los vínculos de dependencia aparecerán más adelante en la línea de comandos). Linkopts especificados en --linkopt tienen prioridad sobre las opciones de vínculos de reglas. Ten en cuenta que el atributo linkopts solo se aplica cuando creas archivos o ejecutables .so, no cuando crees archivos .a o .lo. Por lo tanto, si se establece el atributo linkstatic=True, El atributo linkopts no tiene efecto en la creación de esta biblioteca solo en otros destinos que dependan de ella. Además, es importante tener en cuenta que "-Wl,-soname" o "-Xlinker -soname" no se admiten estas opciones y nunca se deben especificar en este atributo. Los archivos .so producidos por cc_library no están vinculadas a las bibliotecas de las que dependen . Si intentas crear una biblioteca compartida para usar fuera del repositorio principal, p.ej., para uso manual con dlopen() o LD_PRELOAD, quizás sea mejor usar una regla cc_binary con el atributo linkshared=True. Consulta cc_binary.linkshared.
linkstamp	Etiqueta; el valor predeterminado es None De manera simultánea, compila y vincula el archivo de origen C++ especificado en la versión final binario. Este trucos es necesario para ingresar una marca de tiempo información en binarios; si compilamos el archivo fuente en un objeto de la manera usual, la marca de tiempo sería incorrecta. Una compilación de sellos de enlace no puede incluir ningún conjunto particular de indicadores de compilador y, por lo tanto, no deberían depender de ninguna configuración encabezado, opción de compilador y otra variable de compilación. Esta opción solo debería ser necesaria Paquete base.
linkstatic	Booleano; el valor predeterminado es False Para cc_binary y cc_test: vincula el objeto binario en estático . Para cc_library.link_static: consulta a continuación. De forma predeterminada, esta opción está activada para cc_binary y desactivada para el resto. Si se habilita y es un objeto binario o de prueba, esta opción le indica a la herramienta de compilación que se vincule en Usa .a en lugar de .so para las bibliotecas de usuario siempre que sea posible. Bibliotecas de sistema como libc (pero no las bibliotecas en tiempo de ejecución C/C++, (consulta a continuación) siguen vinculadas de forma dinámica, al igual que las bibliotecas para las cuales no hay una biblioteca estática. Por lo tanto, el ejecutable resultante seguirá siendo dinámico vinculadas, por lo que solo son mayormente estáticas. En realidad, existen tres formas diferentes de vincular un archivo ejecutable: STATIC con el atributo full_static_link, en el que todo está vinculado estáticamente; p.ej., “gcc -static foo.o libbar.a libbaz.a -lm”. Este modo se habilita especificando fully_static_link en el atributo features. ESTÁTICA, en la que todas las bibliotecas de usuario están vinculadas estáticamente (si un elemento está disponible), pero donde las bibliotecas del sistema (excluidas las bibliotecas en tiempo de ejecución C/C++) se vinculan de forma dinámica; p.ej., “gcc foo.o libfoo.a libbaz.a -lm”. Para habilitar este modo, debes especificar linkstatic=True. DINÁMICA, en la que todas las bibliotecas se vinculan de forma dinámica (si se trata de una versión disponibles), p.ej., “gcc foo.o libfoo.so libbaz.so -lm”. Para habilitar este modo, debes especificar linkstatic=False. Si el atributo linkstatic o fully_static_link en features se usa fuera de //third_party incluya un comentario cerca de la regla para explicar el motivo. El atributo linkstatic tiene un significado diferente si se usa en un Regla cc_library(). Para una biblioteca C++, linkstatic=True indica que solo Se permite la vinculación estática, por lo que no se producirá un .so. linkstatic=Falso hace no impide la creación de bibliotecas estáticas. El atributo sirve para controlar el la creación de bibliotecas dinámicas. Debería haber muy poco código compilado con linkstatic=False en producción. Si es linkstatic=False, la herramienta de compilación creará symlinks a depende de bibliotecas compartidas en el área *.runfiles.
local_defines	Lista de cadenas; el valor predeterminado es [] Lista de definiciones para agregar a la línea de compilación. Sujeto a "Marca" de variable y Asignación de token de shell de Bourne. Cada cadena, que debe constar de un solo token de shell de Bourne, se antepone -D y se agrega a la línea de comandos de compilación para este destino, pero no a sus dependientes.
module_interfaces	Lista de etiquetas; el valor predeterminado es [] La lista de archivos se considera interfaz de módulos de C++20. C++ Standard no tiene restricciones sobre la extensión de archivo de la interfaz del módulo. Usa cppm de Clang GCC puede usar cualquier extensión de archivo fuente. Uso de ixx de MSVC El uso está protegido por la marca --experimental_cpp_modules
strip_include_prefix	String; el valor predeterminado es "" El prefijo para quitar las rutas de acceso de los encabezados de esta regla. Cuando se establece, se puede acceder a los encabezados en el atributo hdrs de esta regla en su ruta con el prefijo cortado. Si es una ruta de acceso relativa, se toma como una ruta relativa de paquete. Si se trata de un dato absoluto, se entiende como una ruta de acceso relativa al repositorio. El prefijo del atributo include_prefix se agrega después de que este prefijo despojado. Este atributo solo es legal según las third_party.
textual_hdrs	Lista de etiquetas; el valor predeterminado es [] La lista de archivos de encabezado publicados por esta biblioteca para que las fuentes la incluyan textualmente en reglas dependientes. Esta es la ubicación para declarar archivos de encabezado que no se pueden compilar por sí solos. es decir, siempre deben incluirse textualmente en otros archivos de origen para crear código.
win_def_file	Etiqueta; el valor predeterminado es None El archivo DEF de Windows que se pasará al vinculador. Este atributo solo debe usarse cuando Windows es la plataforma de destino. Se puede usar para exportar símbolos durante la vinculación de una biblioteca compartida

cc_proto_library

Ver el código fuente de la regla

cc_proto_library(name, deps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

cc_proto_library genera código C++ a partir de archivos .proto.

deps debe apuntar a las reglas proto_library .

Ejemplo:

cc_library(
    name = "lib",
    deps = [":foo_cc_proto"],
)

cc_proto_library(
    name = "foo_cc_proto",
    deps = [":foo_proto"],
)

proto_library(
    name = "foo_proto",
)

Argumentos

Atributos
name	Nombre: obligatorio. Un nombre único para este destino.
deps	Lista de etiquetas; el valor predeterminado es [] Lista de proto_library para generar el código C++.

cc_shared_library

Ver el código fuente de la regla

cc_shared_library(name, deps, additional_linker_inputs, compatible_with, deprecation, distribs, dynamic_deps, exec_compatible_with, exec_properties, experimental_disable_topo_sort_do_not_use_remove_before_7_0, exports_filter, features, restricted_to, roots, shared_lib_name, static_deps, tags, target_compatible_with, testonly, toolchains, user_link_flags, visibility, win_def_file)

Produce una biblioteca compartida.

Ejemplo

cc_shared_library(
    name = "foo_shared",
    deps = [
        ":foo",
    ],
    dynamic_deps = [
        ":bar_shared",
    ],
    additional_linker_inputs = [
        ":foo.lds",
    ],
    user_link_flags = [
        "-Wl,--version-script=$(location :foo.lds)",
    ],
)
cc_library(
    name = "foo",
    srcs = ["foo.cc"],
    hdrs = ["foo.h"],
    deps = [
        ":bar",
        ":baz",
    ],
)
cc_shared_library(
    name = "bar_shared",
    shared_lib_name = "bar.so",
    deps = [":bar"],
)
cc_library(
    name = "bar",
    srcs = ["bar.cc"],
    hdrs = ["bar.h"],
)
cc_library(
    name = "baz",
    srcs = ["baz.cc"],
    hdrs = ["baz.h"],
)

En el ejemplo, foo_shared vincula de forma estática foo. y baz, que es la última de una dependencia transitiva. No vínculo bar porque ya lo proporciona dinámicamente el bar_shared de dynamic_dep.

foo_shared usa un archivo *.lds de la secuencia de comandos del vinculador para controlar qué los símbolos deben exportarse. La lógica de la regla cc_shared_library no controla qué símbolos se exportan, solo usa lo que se supone que para dar errores durante la fase de análisis si dos bibliotecas compartidas exportan los mismos objetivos.

Se supone que cada dependencia directa de cc_shared_library y exportarse. Por lo tanto, durante el análisis, Bazel supone que se está aplicando foo exportado por foo_shared. No se supone que baz se exportará por foo_shared. Todos los objetivos coincidieron con la exports_filter y se supone que también se exportan.

Cada cc_library del ejemplo debería aparecer como máximo en una cc_shared_library Si quisiéramos vincular baz también a bar_shared tendríamos que agregar tags = ["LINKABLE_MORE_THAN_ONCE"] a baz.

Debido al atributo shared_lib_name, el archivo producido por bar_shared tendrá el nombre bar.so, en lugar de al nombre libbar.so que tendría de forma predeterminada en Linux.

Errores

Two shared libraries in dependencies export the same symbols.

Esto sucederá cuando crees un destino con dos cc_shared_library dependencias que exportan el mismo destino. Para solucionar este problema debes detener la exportación de las bibliotecas en una de las Dependencias cc_shared_library.

Two shared libraries in dependencies link the same library statically

Esto sucederá cada vez que crees un cc_shared_library nuevo con dos dependencias cc_shared_library diferentes que vinculan el mismo destino de forma estática Es similar al error con las exportaciones.

Una forma de solucionar este problema es dejar de vincular la biblioteca a una de las Dependencias cc_shared_library. Al mismo tiempo, la que lo vincula necesita exportar la biblioteca para que la que no la vincule mantenga la visibilidad los símbolos. Otra forma es extraer una tercera biblioteca que exporte el destino. Una tercera forma es etiquetar al culpable cc_library con LINKABLE_MORE_THAN_ONCE. pero esta solución debería ser poco común y debes asegurarte de que el Es seguro vincular cc_library más de una vez.

'//foo:foo' is already linked statically in '//bar:bar' but not exported`

Eso significa que se puede acceder a una biblioteca en el cierre transitivo de tu deps sin pasar por una de las dependencias cc_shared_library, pero ya vinculado a un cc_shared_library diferente en dynamic_deps y no está y exportarse.

La solución es exportarlo desde la dependencia cc_shared_library o extraer un tercer cc_shared_library que lo exporta.

Do not place libraries which only contain a precompiled dynamic library in deps.

Si tienes una biblioteca dinámica precompilada, no es necesario ni se puede vinculada de forma estática al destino actual cc_shared_library al que creando. Por lo tanto, no pertenece a deps de las cc_shared_library Si esta biblioteca dinámica precompilada depende de uno de tu cc_libraries, cc_library debe depender de este directamente.

Trying to export a library already exported by a different shared library

Verás este error si en la regla actual estás declarando que quieres exportar un que ya exporta una de tus dependencias dinámicas.

Para solucionar este problema, quita la segmentación de deps y confía en ella de la campaña dinámica. o asegúrate de que exports_filter no detecte este objetivo.

Argumentos

Atributos
name	Nombre: obligatorio. Un nombre único para este destino.
deps	Lista de etiquetas; el valor predeterminado es [] Bibliotecas de nivel superior que se vincularán de forma estática de forma incondicional a la biblioteca compartida después de que se hayan archivado por completo. Cualquier dependencia transitiva de la biblioteca de estas dependencias directas se vinculará a este biblioteca, siempre y cuando no haya sido vinculada por un cc_shared_library. en dynamic_deps. Durante el análisis, la implementación de la regla considerará todos los objetivos enumerados en deps como exportado por la biblioteca compartida para generar errores cuando varios cc_shared_libraries exportan los mismos destinos. La implementación de reglas no informa al vinculador qué símbolos debe exportar el objeto compartido. El usuario debería encargarse de esto con secuencias de comandos del vinculador o visibilidad. en el código fuente. La implementación también activará errores cada vez que la misma biblioteca esté vinculada de forma estática en más de un cc_shared_library. Esto se puede evitar agregando "LINKABLE_MORE_THAN_ONCE" a cc_library.tags o por ficha `cc_library` como una exportación de una de las bibliotecas compartidas, de manera que se pueda convertir en una dynamic_dep de la otra.
additional_linker_inputs	Lista de etiquetas; el valor predeterminado es [] Cualquier archivo adicional que quieras pasar al vinculador, por ejemplo, secuencias de comandos del vinculador Tienes que pasar por separado las marcas del vinculador que este necesite para estar al tanto de este archivo. Puedes hacerlo mediante el atributo user_link_flags.
dynamic_deps	Lista de etiquetas; el valor predeterminado es [] Estas son otras dependencias de cc_shared_library de las que depende el destino actual. La implementación de cc_shared_library usará la lista de dynamic_deps (de forma transitiva, es decir, también la dynamic_deps del objeto el dynamic_deps del objetivo actual) para decidir en qué cc_libraries de No se deben vincular los deps transitivos porque ya se proporcionaron por un cc_shared_library diferente.
experimental_disable_topo_sort_do_not_use_remove_before_7_0	Booleano; el valor predeterminado es False
exports_filter	Lista de cadenas; el valor predeterminado es [] Este atributo contiene una lista de destinos que se afirma que son exportados por el biblioteca compartida. La Biblioteca compartida ya considera que cualquier deps de destino se exportará. Este atributo se debe usar para enumerar todos los destinos exportados por la biblioteca compartida pero son dependencias transitivas de deps. Ten en cuenta que este atributo en realidad no agrega una arista de dependencia a esos destinos, el en el perímetro de la dependencia, deps.Las entradas de este son solo cadenas. Ten en cuenta que, cuando coloques un destino en este atributo, esto se considera una afirmación de que la biblioteca compartida exporta los símbolos de ese destino. La lógica cc_shared_library no controla, en realidad, indicarle al vinculador qué los símbolos deben exportarse. Se permite la siguiente sintaxis: //foo:__package__ para representar cualquier destino en foo/BUILD //foo:__subpackages__ para representar cualquier destino en foo/BUILD o cualquier otro paquete debajo de foo/ como foo/bar/BUILD
roots	Lista de etiquetas; el valor predeterminado es []
shared_lib_name	String; el valor predeterminado es "" De forma predeterminada, cc_shared_library usará un nombre para el archivo de salida de la biblioteca compartida según el nombre del objetivo y la plataforma. Esto incluye una extensión y, a veces, un prefijo. A veces, es posible que no quieras el nombre predeterminado (por ejemplo, cuando cargas bibliotecas compartidas de C++) Para Python, a menudo no se desea el prefijo lib* predeterminado, en cuyo caso, puedes usar este para elegir un nombre personalizado.
static_deps	Lista de cadenas; el valor predeterminado es []
user_link_flags	Lista de cadenas; el valor predeterminado es [] Cualquier marca adicional que desees pasar al vinculador. Por ejemplo, para que la vinculador reconoce una secuencia de comandos del vinculador pasada a través de additional_linker_inputs. Puedes usar el lo siguiente: cc_shared_library( name = "foo_shared", additional_linker_inputs = select({ "//src/conditions:linux": [ ":foo.lds", ":additional_script.txt", ], "//conditions:default": []}), user_link_flags = select({ "//src/conditions:linux": [ "-Wl,-rpath,kittens", "-Wl,--version-script=$(location :foo.lds)", "-Wl,--script=$(location :additional_script.txt)", ], "//conditions:default": []}), ... )
win_def_file	Etiqueta; el valor predeterminado es None El archivo DEF de Windows que se pasará al vinculador. Este atributo solo debe usarse cuando Windows es la plataforma de destino. Se puede usar para exportar símbolos durante la vinculación de una biblioteca compartida

cc_static_library

Ver el código fuente de la regla

cc_static_library(name, deps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

Produce una biblioteca estática a partir de una lista de destinos y sus dependencias transitivas.

La biblioteca estática resultante contiene los archivos de objeto de los destinos enumerados en deps, así como sus dependencias transitivas, con preferencia PIC.

Grupos de salida

linkdeps

Un archivo de texto que contiene las etiquetas de las dependencias transitivas de los objetivos enumerados en deps que no contribuyeron con ningún archivo de objeto a la biblioteca estática, pero sí Proporcionar al menos una biblioteca estática, dinámica o de interfaz. La biblioteca estática resultante Es posible que estas bibliotecas estén disponibles en el momento del vínculo.

linkopts

Un archivo de texto que contiene el elemento linkopts proporcionado por el usuario de todos los elementos transitivos las dependencias de los objetivos enumerados en deps.

Símbolos duplicados

De forma predeterminada, la regla cc_static_library comprueba que la imagen estática resultante biblioteca no contiene símbolos duplicados. Si existe una superposición, la compilación falla con un error que enumera los símbolos duplicados y los archivos de objeto que los contienen.

Esta verificación se puede inhabilitar por destino o por paquete mediante la configuración features = ["-symbol_check"] o en todo el mundo a través de --features=-symbol_check

Compatibilidad con el conjunto de herramientas de symbol_check

Las cadenas de herramientas de C++ configuradas automáticamente incluidas con Bazel admiten el symbol_check en todas las plataformas. Las cadenas de herramientas personalizadas pueden agregar compatibilidad con de dos maneras:

• Si implementas la acción ACTION_NAMES.validate_static_library y lo habilita con la función symbol_check. El conjunto de herramientas en la acción es invocado con dos argumentos: la biblioteca estática para buscar símbolos duplicados y el la ruta de acceso de un archivo que debe crearse si se aprueba la verificación.
• Hacer que la función symbol_check agregue marcas de Archiver que provoquen el que crea la biblioteca estática para que falle en símbolos duplicados.

Argumentos

Atributos
name	Nombre: obligatorio. Un nombre único para este destino.
deps	Lista de etiquetas; el valor predeterminado es [] La lista de destinos para combinar en una biblioteca estática, incluidas todas sus dependencias. Las dependencias que no proporcionan archivos de objeto no se incluyen en la pero las etiquetas se recopilan en el archivo proporcionado por el Grupo de salida linkdeps.

cc_test

Ver el código fuente de la regla

cc_test(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, dynamic_deps, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, hdrs_check, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local, local_defines, malloc, module_interfaces, nocopts, reexport_deps, restricted_to, shard_count, size, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility, win_def_file)

Una regla cc_test() compila una prueba. Aquí, una prueba es un wrapper binario para un código de prueba.

De forma predeterminada, las pruebas de C++ se vinculan de forma dinámica.
Para vincular estáticamente una prueba de unidades, especifica linkstatic=True Probablemente sea bueno indicarme por qué la prueba necesita linkstatic; esto probablemente no sea obvio.

Destinos de salida implícitos

• name.stripped (solo se compila si se solicita de forma explícita): Es un fragmento versión del objeto binario. Se ejecuta strip -g en el objeto binario para quitar la depuración. símbolos. Se pueden proporcionar opciones adicionales de barra en la línea de comandos mediante --stripopt=-foo
• name.dwp (solo se compila si se solicita explícitamente): Si La fisión está habilitada: una depuración archivo del paquete de información adecuado para depurar objetos binarios implementados de manera remota. De lo contrario, un archivo vacío.

Consulta los argumentos cc_binary(), excepto que el argumento stamp se establece en 0 de forma predeterminada para pruebas y que cc_test tiene extra atributos comunes a todas las reglas de prueba (*_test).

Argumentos

Atributos
name	Nombre: obligatorio. Un nombre único para este destino.
deps	Lista de etiquetas; el valor predeterminado es [] Es la lista de otras bibliotecas que se vincularán al objetivo binario. Pueden ser cc_library o objc_library. objetivos. También se permite colocar secuencias de comandos del vinculador (.lds) en dependencias y hacer referencia a ellas en linkopts.
srcs	Lista de etiquetas; el valor predeterminado es [] Es la lista de archivos C y C++ que se procesan para crear el destino de la biblioteca. Estos son archivos de origen y encabezado C/C++, ya sean no generados (fuente normal) código) o que se generó. Se harán los cambios en todos los archivos .cc, .c y .cpp compilarse. Estos pueden ser archivos generados: si un archivo nombrado se encuentra en la outs de otra regla, esta cc_library dependerá automáticamente de esa otra regla. Los archivos ensambladores puros (.s, .asm) no se procesan previamente y, por lo general, se compilan con el ensamblador. Los archivos de ensamblado previamente procesados (.S) se procesan previamente y, por lo general, se compilan con el compilador C/C++. No se compilará un archivo .h, pero estará disponible para la inclusión por fuentes en esta regla. Tanto .cc como Los archivos .h pueden incluir directamente los encabezados enumerados en estos srcs o en la hdrs de esta regla, o cualquiera lista en el argumento deps. Todos los archivos #included deben mencionarse en el Atributo hdrs de este valor o cc_library al que se hace referencia reglas de firewall, o deben aparecer en srcs si son privadas a esta biblioteca. Consulta "Verificación de inclusión de encabezados" para obtener una descripción más detallada. Los archivos .so, .lo y .a tienen las siguientes características: archivos compilados previamente. Es posible que tu biblioteca tenga estos srcs si usa código de terceros para el cual no lo hacemos tienen código fuente. Si el atributo srcs incluye la etiqueta de otra regla, cc_library usará los archivos de salida de esa regla como archivos de origen para lo siguiente: compilar. Esto es útil para la generación única de código fuente (para más de usar, es mejor implementar una clase de regla de Starlark y usar la clase cc_common API) Tipos de archivos srcs permitidos: Archivos de origen C y C++: .c, .cc, .cpp, .cxx, .c++ y .C Archivos de encabezado C y C++: .h, .hh, .hpp, .hxx, .inc, .inl y .H Ensamblador con preprocesador en C: .S Archivo: .a, .pic.a "Vincular siempre" biblioteca: .lo, .pic.lo Biblioteca compartida, con o sin versiones: .so, .so.version Archivo de objeto: .o, .pic.o ... y cualquier regla que genere esos archivos (p.ej., cc_embed_data). Las diferentes extensiones denotan diferentes lenguajes de programación en de acuerdo con la convención de GCC.
data	Lista de etiquetas; el valor predeterminado es [] Es la lista de archivos que necesita esta biblioteca en el entorno de ejecución. Consulta los comentarios generales sobre data en Atributos típicos definidos por la mayoría de las reglas de compilación. Si data es el nombre de un archivo generado, este cc_library depende automáticamente de la regla . Si data es el nombre de una regla, este La regla cc_library depende automáticamente de ella, y los outs de esa regla se agregan los archivos de datos de cc_library. Tu código C++ puede acceder a estos archivos de datos de la siguiente manera: const std::string path = devtools_build::GetDataDependencyFilepath( "my/test/data/file");
additional_linker_inputs	Lista de etiquetas; el valor predeterminado es [] Pasa estos archivos al comando del vinculador de C++. Por ejemplo, aquí se pueden proporcionar archivos .res compilados de Windows para incorporarlos en el objeto binario.
copts	Lista de cadenas; el valor predeterminado es [] Agrega estas opciones al comando de compilación de C++. Con la sustitución "Make variable" y Asignación de token de shell de Bourne. Cada cadena de este atributo se agrega en el orden determinado a COPTS antes de compilando el objetivo binario. Las marcas solo tienen efecto en la compilación de este destino, no sus dependencias, por lo que debes tener cuidado con los archivos de encabezado que se incluyan en otro lugar. Todas las rutas de acceso deben estar relacionadas con el lugar de trabajo, no con el paquete actual. Este atributo no debería ser necesario fuera de third_party. Si el paquete declara la función no_copts_tokenization: La asignación de token de shell de Bourne se aplica solo a las cadenas. que constan de un solo “Marca” de salida.
defines	Lista de cadenas; el valor predeterminado es [] Lista de definiciones para agregar a la línea de compilación. Sujeto a "Marca" de variable y Asignación de token de shell de Bourne. Cada cadena, que debe constar de un solo token de shell de Bourne, se antepone -D y se agrega a la línea de comandos de compilación de este destino, así como a cada regla que depende de él. Ten mucho cuidado, ya que esto podría haber efectos de largo alcance. Si tienes dudas, agrega valores definidos a local_defines en su lugar.
dynamic_deps	Lista de etiquetas; el valor predeterminado es [] Estas son otras dependencias de cc_shared_library de las que depende el destino actual. La implementación de cc_shared_library usará la lista de dynamic_deps (de forma transitiva, es decir, también la dynamic_deps del objeto el dynamic_deps del objetivo actual) para decidir en qué cc_libraries de No se deben vincular los deps transitivos porque ya se proporcionaron por un cc_shared_library diferente.
hdrs_check	String; el valor predeterminado es "" Obsoleto, no-op.
includes	Lista de cadenas; el valor predeterminado es [] Lista de dir de inclusión que se agregarán a la línea de compilación. Sujeto a la sustitución "Make variable". A cada cadena se le antepone la ruta del paquete y se pasa a la cadena de herramientas de C++ para de expansión mediante el comando MÚLTIPLE Una cadena de herramientas que se ejecuta en un sistema POSIX con definiciones de atributos típicas producirán -isystem path_to_package/include_entry Solo debe usarse para bibliotecas de terceros que no cumplen con el estilo de redacción de Google. A diferencia de COPTS, estas marcas se agregan a esta regla. y cada regla que depende de él. (Nota: No depende de las reglas de las que depende). Sé esto puede tener efectos de largo alcance. Si tienes dudas, agrega “-I” a COPTS. Las rutas de acceso include agregadas incluirán archivos generados, así como en el árbol de fuentes.
link_extra_lib	Etiqueta; el valor predeterminado es "@bazel_tools//tools/cpp:link_extra_lib" Controla la vinculación de bibliotecas adicionales. De forma predeterminada, los objetos binarios de C++ están vinculados con //tools/cpp:link_extra_lib. que, de forma predeterminada, depende de la marca de etiqueta //tools/cpp:link_extra_libs. Si no se configura la marca, esta biblioteca estará vacía de forma predeterminada. Configura la marca de la etiqueta permite vincular dependencias opcionales, como anulaciones de símbolos débiles, interceptores para funciones de bibliotecas compartidas o bibliotecas de tiempo de ejecución especiales (para reemplazos de malloc, preferir malloc o --custom_malloc). Establecer este atributo en None inhabilita este comportamiento.
linkopts	Lista de cadenas; el valor predeterminado es [] Agrega estas marcas al comando del vinculador de C++. Sujeto a "Marca" de variable, la asignación de token de shell de Bourne y expansión de etiquetas. Cada cadena de este atributo se agrega a LINKOPTS antes de que vincula el objetivo binario. Cada elemento de esta lista que no comienza con $ o - se se supone que es la etiqueta de un objetivo en deps. El La lista de archivos que genera ese destino se agrega al vinculador opciones de estado. Se informa un error si la etiqueta no es válida o no se declaró en deps.
linkshared	Booleano; el valor predeterminado es False Crea una biblioteca compartida. Para habilitar este atributo, incluye linkshared=True en tu regla. De forma predeterminada esta opción está desactivada. La presencia de esta marca significa que la vinculación se produce con la marca -shared. en gcc, y la biblioteca compartida resultante es adecuada para la carga en ejemplo, un programa de Java. Sin embargo, para fines de compilación, nunca se vinculará con binario dependiente, ya que se supone que las bibliotecas compartidas cc_binary solo las cargan manualmente otros programas, por lo que No debe considerarse un sustituto de cc_library. . Por motivos de escalabilidad, recomendamos evitar este enfoque por completo simplemente permitiendo que java_library dependa de las reglas cc_library en su lugar. Si especificas linkopts=['-static'] y linkshared=True, obtienes una sola unidad completamente independiente. Si especificas ambos linkstatic=True y linkshared=True, obtienes un solo clic, mayormente unidad independiente.
linkstatic	Booleano; el valor predeterminado es False Para cc_binary y cc_test: vincula el objeto binario en estático . Para cc_library.link_static: consulta a continuación. De forma predeterminada, esta opción está activada para cc_binary y desactivada para el resto. Si se habilita y es un objeto binario o de prueba, esta opción le indica a la herramienta de compilación que se vincule en Usa .a en lugar de .so para las bibliotecas de usuario siempre que sea posible. Bibliotecas de sistema como libc (pero no las bibliotecas en tiempo de ejecución C/C++, (consulta a continuación) siguen vinculadas de forma dinámica, al igual que las bibliotecas para las cuales no hay una biblioteca estática. Por lo tanto, el ejecutable resultante seguirá siendo dinámico vinculadas, por lo que solo son mayormente estáticas. En realidad, existen tres formas diferentes de vincular un archivo ejecutable: STATIC con el atributo full_static_link, en el que todo está vinculado estáticamente; p.ej., “gcc -static foo.o libbar.a libbaz.a -lm”. Este modo se habilita especificando fully_static_link en el atributo features. ESTÁTICA, en la que todas las bibliotecas de usuario están vinculadas estáticamente (si un elemento está disponible), pero donde las bibliotecas del sistema (excluidas las bibliotecas en tiempo de ejecución C/C++) se vinculan de forma dinámica; p.ej., “gcc foo.o libfoo.a libbaz.a -lm”. Para habilitar este modo, debes especificar linkstatic=True. DINÁMICA, en la que todas las bibliotecas se vinculan de forma dinámica (si se trata de una versión disponibles), p.ej., “gcc foo.o libfoo.so libbaz.so -lm”. Para habilitar este modo, debes especificar linkstatic=False. Si el atributo linkstatic o fully_static_link en features se usa fuera de //third_party incluya un comentario cerca de la regla para explicar el motivo. El atributo linkstatic tiene un significado diferente si se usa en un Regla cc_library(). Para una biblioteca C++, linkstatic=True indica que solo Se permite la vinculación estática, por lo que no se producirá un .so. linkstatic=Falso hace no impide la creación de bibliotecas estáticas. El atributo sirve para controlar el la creación de bibliotecas dinámicas. Debería haber muy poco código compilado con linkstatic=False en producción. Si es linkstatic=False, la herramienta de compilación creará symlinks a depende de bibliotecas compartidas en el área *.runfiles.
local_defines	Lista de cadenas; el valor predeterminado es [] Lista de definiciones para agregar a la línea de compilación. Sujeto a "Marca" de variable y Asignación de token de shell de Bourne. Cada cadena, que debe constar de un solo token de shell de Bourne, se antepone -D y se agrega a la línea de comandos de compilación para este destino, pero no a sus dependientes.
malloc	Etiqueta; el valor predeterminado es "@bazel_tools//tools/cpp:malloc" Anula la dependencia predeterminada en malloc. De forma predeterminada, los objetos binarios de C++ están vinculados con //tools/cpp:malloc. que es una biblioteca vacía, por lo que el objeto binario termina usando libc malloc. Esta etiqueta debe hacer referencia a un cc_library. Si la compilación es para una compilación que no es de C++ regla, esta opción no tiene efecto. El valor de este atributo se ignora si Se especifica linkshared=True.
module_interfaces	Lista de etiquetas; el valor predeterminado es [] La lista de archivos se considera interfaz de módulos de C++20. C++ Standard no tiene restricciones sobre la extensión de archivo de la interfaz del módulo. Usa cppm de Clang GCC puede usar cualquier extensión de archivo fuente. Uso de ixx de MSVC El uso está protegido por la marca --experimental_cpp_modules
nocopts	String; el valor predeterminado es "" Se quitaron las opciones coincidentes del comando de compilación de C++. Sujeto a "Marca" de variables. El valor de este atributo se interpreta como una expresión regular. Cualquier COPTS preexistente que coincida con esta expresión regular (incluidos los valores especificados explícitamente en el atributo copts de la regla) se quitará de COPTS a los efectos de compilar esta regla. Este atributo no debe ser necesario ni usarse fuera de third_party. Los valores no se procesan de ninguna manera que no sea con la sustitución de variables.
reexport_deps	Lista de etiquetas; el valor predeterminado es []
stamp	Número entero; el valor predeterminado es 0 Establece si se debe codificar información de compilación en el objeto binario. Valores posibles: stamp = 1: Siempre marca la información de la compilación en el objeto binario, incluso en --nostamp. Este de configuración debe evitarse, ya que puede finalizar el almacenamiento en caché remoto binario y las acciones descendentes que dependan de él. stamp = 0: Siempre reemplaza la información de compilación por valores constantes. Esta brinda un buen almacenamiento en caché de resultados de compilación. stamp = -1: la incorporación de la información de la compilación está controlada por el --[no]stamp. Los objetos binarios sellados no se vuelven a compilar, a menos que cambien sus dependencias.
win_def_file	Etiqueta; el valor predeterminado es None El archivo DEF de Windows que se pasará al vinculador. Este atributo solo debe usarse cuando Windows es la plataforma de destino. Se puede usar para exportar símbolos durante la vinculación de una biblioteca compartida

cc_toolchain

Ver el código fuente de la regla

cc_toolchain(name, all_files, ar_files, as_files, compatible_with, compiler_files, compiler_files_without_includes, coverage_files, deprecation, distribs, dwp_files, dynamic_runtime_lib, exec_compatible_with, exec_properties, exec_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, output_licenses, restricted_to, static_runtime_lib, strip_files, supports_header_parsing, supports_param_files, tags, target_compatible_with, testonly, toolchain_config, toolchain_identifier, toolchains, visibility)

Representa una cadena de herramientas de C++.

Esta regla es responsable de lo siguiente:

• Recopila todos los artefactos necesarios para que se ejecuten las acciones de C++. Esto lo hace atributos, como all_files, compiler_files linker_files o algún otro atributo que termina en _files). Son por lo general, los grupos de archivos que globalizan todos los archivos necesarios.
• Generando líneas de comandos correctas para las acciones de C++. Esto se hace usando CcToolchainConfigInfo proveedor (más detalles a continuación).

Usa el atributo toolchain_config para configurar la cadena de herramientas de C++. Ver también esto página para obtener documentación elaborada de la cadena de herramientas de C++ y de la selección de la cadena de herramientas.

Usa tags = ["manual"] para evitar que se compilen y configuren cadenas de herramientas. innecesariamente cuando se invoca bazel build //...

Argumentos

Atributos
name	Nombre: obligatorio. Un nombre único para este destino.
all_files	Etiqueta; obligatorio. Es una colección de todos los artefactos de cc_toolchain. Estos artefactos se agregarán como entradas a todos acciones relacionadas con rules_cc (con la excepción de las acciones que usen conjuntos más precisos de artefactos de los atributos que se indican a continuación). Bazel supone que all_files es un superconjunto. de todos los demás atributos que proporcionan artefactos (p.ej., la compilación de huella de vínculos necesita compilación y archivos de vínculo, por lo que toma all_files). Esto es lo que contiene cc_toolchain.files, y todo Starlark lo usa. con la cadena de herramientas de C++.
ar_files	Etiqueta; el valor predeterminado es None Es una colección de todos los artefactos cc_toolchain necesarios para archivar acciones.
as_files	Etiqueta; el valor predeterminado es None Es una colección de todos los artefactos cc_toolchain necesarios para las acciones de ensamblado.
compiler_files	Etiqueta; obligatorio. Es una colección de todos los artefactos cc_toolchain necesarios para las acciones de compilación.
compiler_files_without_includes	Etiqueta; el valor predeterminado es None Es una colección de todos los artefactos cc_toolchain necesarios para las acciones de compilación en caso de que ocurra lo siguiente: es compatible con el descubrimiento de entradas (por el momento, solo es compatible con Google).
coverage_files	Etiqueta; el valor predeterminado es None Es una colección de todos los artefactos cc_toolchain necesarios para las acciones de cobertura. Si no se especifica, all_files.
dwp_files	Etiqueta; obligatorio. Es una colección de todos los artefactos cc_toolchain necesarios para las acciones de dwp.
dynamic_runtime_lib	Etiqueta; el valor predeterminado es None Artefacto de biblioteca dinámica para la biblioteca en tiempo de ejecución C++ (p.ej., libstdc++.so). Se usará cuando “static_link_cpp_runtimes” está habilitada y vincularemos dependencias de forma dinámica.
exec_transition_for_inputs	Booleano; el valor predeterminado es False Obsoleta. No-ops.
libc_top	Etiqueta; el valor predeterminado es None Es un conjunto de artefactos para libc que se pasan como entradas a las acciones de compilación y vinculación.
linker_files	Etiqueta; obligatorio. Es una colección de todos los artefactos cc_toolchain necesarios para las acciones de vinculación.
module_map	Etiqueta; el valor predeterminado es None Artefacto de mapa de módulos que se usará en compilaciones modulares.
objcopy_files	Etiqueta; obligatorio. Es una colección de todos los artefactos cc_toolchain necesarios para las acciones de objcopy.
output_licenses	Lista de cadenas; el valor predeterminado es []
static_runtime_lib	Etiqueta; el valor predeterminado es None Artefacto de biblioteca estática para la biblioteca en tiempo de ejecución C++ (p.ej., libstdc++.a). Se usará cuando “static_link_cpp_runtimes” está habilitada y vincularemos dependencias de forma estática.
strip_files	Etiqueta; obligatorio. Es una colección de todos los artefactos cc_toolchain necesarios para las acciones de eliminación.
supports_header_parsing	Booleano; el valor predeterminado es False Se establece en True cuando cc_toolchain admite acciones de análisis de encabezados.
supports_param_files	Booleano; el valor predeterminado es True Se establece en True cuando cc_toolchain admite archivos de parámetros para acciones de vinculación.
toolchain_config	Etiqueta; obligatorio. La etiqueta de la regla que proporciona cc_toolchain_config_info.
toolchain_identifier	String; el valor predeterminado es "" El identificador que se usa para hacer coincidir esta cc_toolchain con el crosstool_config.toolchain. Hasta que se corrija el problema #5380 esta es la forma recomendada de asociar cc_toolchain con CROSSTOOL.toolchain Se reemplazará por toolchain_config (#5380).

cc_toolchain_suite

Ver el código fuente de la regla

cc_toolchain_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

Obsoleto: la regla no es operativa y se quitará.

Argumentos

Atributos
name	Nombre: obligatorio. Un nombre único para este destino.

fdo_prefetch_hints

Ver el código fuente de la regla

fdo_prefetch_hints(name, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

Representa un perfil de sugerencias de carga previa de FDO que se encuentra en el lugar de trabajo. Ejemplos:

fdo_prefetch_hints(
    name = "hints",
    profile = "//path/to/hints:profile.afdo",
)

Argumentos

Atributos
name	Nombre: obligatorio. Un nombre único para este destino.
profile	Etiqueta; obligatorio. Etiqueta del perfil de sugerencias. El archivo de sugerencias tiene la extensión .afdo. La etiqueta también puede apuntar a una regla de perfil fdo_ muchísima_ruta.

fdo_profile

Ver el código fuente de la regla

fdo_profile(name, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, memprof_profile, profile, proto_profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

Representa un perfil de FDO que está en el lugar de trabajo. Ejemplo:

fdo_profile(
    name = "fdo",
    profile = "//path/to/fdo:profile.zip",
)

Argumentos

Atributos
name	Nombre: obligatorio. Un nombre único para este destino.
memprof_profile	Etiqueta; el valor predeterminado es None Etiqueta del perfil de MemProf. Se espera que el perfil tenga una extensión .profdata (para un archivo Memprof indexado o simbolizado o una extensión .zip para un archivo ZIP que contenga un archivo memprof.profdata. .
profile	Etiqueta; obligatorio. Etiqueta del perfil de FDO o una regla que lo genera. El archivo FDO puede tener uno de los Las siguientes extensiones: .profraw para el perfil de LLVM no indexado, .profdata para el LLVM indexado .zip que contiene un perfil profraw de LLVM, .afdo para el perfil de AutoFDO y .xfdo para el perfil perfil de XBinary. La etiqueta también puede apuntar a una regla de perfil fdo_ muchísima_ruta.
proto_profile	Etiqueta; el valor predeterminado es None Etiqueta del perfil de protobuf.

memprof_profile

Ver el código fuente de la regla

memprof_profile(name, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

Representa un perfil de MEMPROF que se encuentra en el lugar de trabajo. Ejemplo:

memprof_profile(
    name = "memprof",
    profile = "//path/to/memprof:profile.afdo",
)

Argumentos

Atributos
name	Nombre: obligatorio. Un nombre único para este destino.
profile	Etiqueta; obligatorio. Etiqueta del perfil de MEMPROF. Se espera que el perfil tenga una extensión .profdata (para un archivo Memprof indexado o simbolizado o una extensión .zip para un archivo ZIP que contenga un archivo memprof.profdata. . La etiqueta también puede apuntar a una regla de perfil fdo_ muchísima_ruta.

propeller_optimize

Ver el código fuente de la regla

propeller_optimize(name, cc_profile, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, ld_profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

Representa un perfil de optimización de Propeller en el lugar de trabajo. Ejemplo:

propeller_optimize(
    name = "layout",
    cc_profile = "//path:cc_profile.txt",
    ld_profile = "//path:ld_profile.txt"
)

Argumentos

Atributos
name	Nombre: obligatorio. Un nombre único para este destino.
cc_profile	Etiqueta; obligatorio. Etiqueta del perfil que se pasó a las distintas acciones de compilación. Este archivo contiene la extensión .txt.
ld_profile	Etiqueta; obligatorio. Etiqueta del perfil que se pasa a la acción de vinculación. Este archivo contiene la extensión .txt.