Reglas
- cc_binary
- cc_import
- cc_library
- cc_proto_library
- cc_shared_library
- fdo_prefetch_hints
- fdo_profile
- propeller_optimize
- cc_test
- cc_toolchain
- cc_toolchain_suite
CC_binario
Ver el origen de las reglascc_binary(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, includes, licenses, linkopts, linkshared, linkstatic, local_defines, malloc, nocopts, output_licenses, restricted_to, stamp, tags, target_compatible_with, testonly, toolchains, visibility, win_def_file)
Objetivos de salida implícitos
name.stripped
(solo se compila si se solicita de manera explícita): Es una versión sin objetos binarios del objeto binario.strip -g
se ejecuta en el objeto binario para quitar los símbolos de depuración. Se pueden proporcionar opciones de banda adicionales en la línea de comandos mediante--stripopt=-foo
. Este resultado solo se compila si se solicita de manera explícita.name.dwp
(solo compilado si se solicita de forma explícita): Si Fission está habilitado, es un archivo de paquete de información de depuración adecuado para depurar objetos binarios implementados de forma remota. De lo contrario: un archivo vacío.
Argumentos
Atributos | |
---|---|
name |
Es un nombre único para este destino. |
deps
|
Pueden ser objetivos |
srcs
|
Se compilarán todos los archivos No se compilará un archivo Se deben mencionar todos los archivos Si el nombre de una regla está en
Tipos de archivos
...y cualquier regla que produzca esos archivos. Las diferentes extensiones denotan diferentes lenguajes de programación de acuerdo con la convención de GCC. |
additional_linker_inputs
|
Por ejemplo, se pueden proporcionar archivos .res compilados de Windows aquí para incorporarlos en el destino binario. |
copts
|
Cada string de este atributo se agrega en el orden dado a
Si el paquete declara el |
defines
|
-D y se agrega a la línea de comandos de compilación a este destino, así como a cada regla que depende de ella. Ten mucho cuidado, ya que esto puede tener efectos de gran alcance. En caso de duda, agrega valores definidos a local_defines .
|
includes
|
Sujeto a la sustitución "Make variable".
Cada string se antepone con Los encabezados deben agregarse a src o hdr; de lo contrario, no estarán disponibles para las reglas dependientes cuando la compilación se coloque en una zona de pruebas (el valor predeterminado). |
linkopts
|
LINKOPTS antes de vincular el destino binario.
Se supone que cada elemento de esta lista que no comienza con |
linkshared
|
linkshared=True en su regla. Esta opción está desactivada de forma predeterminada.
La presencia de esta marca significa que la vinculación se realiza con la marca
Si especificas |
linkstatic
|
cc_binary y cc_test , vincula el objeto binario en modo estático. Para cc_library.linkstatic , consulta a continuación.
De forma predeterminada, esta opción está activada para
Si está habilitada y es un objeto binario o una prueba, esta opción indica a la herramienta de compilación que se vincule en Existen tres maneras diferentes de vincular un ejecutable:
El atributo
Si es |
local_defines
|
-D y se agrega a la línea de comandos de compilación para este destino, pero no a sus dependientes.
|
malloc
|
De forma predeterminada, los objetos binarios de C++ se vinculan con |
nocopts
|
COPTS preexistente que coincida con esta expresión regular (incluidos los valores especificados de forma explícita en el atributo copts de la regla) se quitará de COPTS a los efectos de compilar esta regla.
Rara vez se necesita este atributo.
|
stamp
|
Los objetos binarios con sellos no se vuelven a compilar, a menos que cambien sus dependencias. |
win_def_file
|
Este atributo solo debe usarse cuando Windows es la plataforma seleccionada. Se puede usar para exportar símbolos durante la vinculación de una biblioteca compartida. |
Cc_importar
Ver el origen de las reglascc_import(name, deps, data, hdrs, alwayslink, compatible_with, deprecation, distribs, features, interface_library, licenses, restricted_to, shared_library, static_library, system_provided, tags, target_compatible_with, testonly, visibility)
Las reglas cc_import
permiten a los usuarios importar bibliotecas C/C++ compiladas previamente.
Los siguientes son casos de uso típicos:
1. Vinculación de 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. Vinculación de una biblioteca compartida con una biblioteca de interfaces (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. Vinculación de una biblioteca compartida con
system_provided=True
(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. Vinculación a una biblioteca estática o compartida
En Unix:
cc_import( name = "mylib", hdrs = ["mylib.h"], static_library = "libmylib.a", shared_library = "libmylib.so", ) # first will link to libmylib.a cc_binary( name = "first", srcs = ["first.cc"], deps = [":mylib"], linkstatic = 1, # default value ) # second will link to libmylib.so cc_binary( name = "second", srcs = ["second.cc"], deps = [":mylib"], linkstatic = 0, )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", ) # first will link to libmylib.lib cc_binary( name = "first", srcs = ["first.cc"], deps = [":mylib"], linkstatic = 1, # default value ) # second will link to mylib.dll through mylib.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 |
Es un nombre único para este destino. |
deps
|
deps en Atributos típicos definidos por la mayoría de las reglas de compilación.
|
hdrs
|
|
alwayslink
|
Si Alwayslink no funciona con VS 2017 en Windows, se debe a un problema conocido. Actualiza VS 2017 a la versión más reciente. |
interface_library
|
Tipos de archivos permitidos: |
shared_library
|
Tipos de archivo permitidos: |
static_library
|
Tipos de archivo permitidos: |
system_provided
|
interface_library y shared_library debe estar vacío.
|
CC_biblioteca
Ver el origen de las reglascc_library(name, deps, srcs, data, hdrs, alwayslink, compatible_with, copts, defines, deprecation, distribs, exec_compatible_with, exec_properties, features, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, nocopts, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)
Verificación de inclusión de encabezados
Todos los archivos de encabezado que se usan en la compilación deben declararse en las reglas hdrs
o srcs
de cc_*
. Esto se aplica de manera forzosa.
Para las reglas cc_library
, los encabezados en hdrs
comprenden la interfaz pública de la biblioteca y se pueden incluir directamente desde los archivos en hdrs
y srcs
de la biblioteca, así como desde archivos en las reglas hdrs
y srcs
de cc_*
que enumeran la biblioteca en su deps
.
Los encabezados de srcs
solo se deben incluir directamente desde los archivos en hdrs
y srcs
de la biblioteca. Cuando decidas si debes colocar un encabezado en hdrs
o srcs
, debes preguntar si deseas que los consumidores de esta biblioteca puedan incluirlo directamente. Esta es más o menos igual a la visibilidad entre public
y private
en los lenguajes de programación.
Las reglas cc_binary
y cc_test
no tienen una interfaz exportada, por lo que tampoco tienen un atributo hdrs
. Todos los encabezados que pertenecen al objeto binario o la prueba directamente deben aparecer en la srcs
.
Para ilustrar estas reglas, observa 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, foo.cc
puede incluir directamente foo.h
y bar.h
, pero no baz.h
.
Incluyendo archivo | Inclusiones permitidas |
---|---|
foo.h | bar |
foo.cc | foo.h bar |
bar | bar-impl.h baz.h |
bar-impl.h | bar.h baz.h |
bar | bar.h bar-impl.h baz.h |
Baz | baz-impl.h |
baz-impl.h | Baz |
baz.cc | baz.h baz-impl.h |
Las reglas de verificación de inclusión solo se aplican a las inclusiones directas. En el ejemplo anterior, foo.cc
puede incluir bar.h
, que puede incluir baz.h
, que, a su vez, puede incluir baz-impl.h
. Técnicamente, la compilación de un archivo .cc
puede incluir de forma transitiva cualquier archivo de encabezado en hdrs
o srcs
en cualquier cc_library
del cierre deps
transitivo. En este caso, el compilador puede leer baz.h
y baz-impl.h
cuando compila foo.cc
, pero foo.cc
no debe contener #include "baz.h"
. Para permitirlo, se debe agregar baz
a deps
de foo
.
Bazel depende de la compatibilidad de 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 solicitarse de forma explícita, por ejemplo, a través de la marca de línea de comandos --features=layering_check
o el 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.
Argumentos
Atributos | |
---|---|
name |
Es un nombre único para este destino. |
deps
|
Pueden ser objetivos |
srcs
|
Se compilarán todos los archivos No se compilará un archivo Se deben mencionar todos los archivos Si el nombre de una regla está en
Tipos de archivos
...y cualquier regla que produzca esos archivos. Las diferentes extensiones denotan diferentes lenguajes de programación de acuerdo con la convención de GCC. |
hdrs
|
Esta es la ubicación preferida para declarar archivos de encabezado que describen la interfaz de la biblioteca. Estos encabezados estarán disponibles para que los fuentes los incluyan en esta regla o en reglas dependientes.
En su lugar, los encabezados que no se pretenden incluir en un cliente de esta biblioteca deben incluirse en el atributo |
alwayslink
|
srcs , incluso si algunos no contienen símbolos a los que el objeto binario haga referencia.
Esto es útil si tu código no lo llama explícitamente en el objeto binario (p.ej., si se registra para recibir la devolución de llamada que proporciona algún servicio).
Si Alwayslink no funciona con VS 2017 en Windows, se debe a un problema conocido. Actualiza VS 2017 a la versión más reciente. |
copts
|
Cada string de este atributo se agrega en el orden dado a
Si el paquete declara el |
defines
|
-D y se agrega a la línea de comandos de compilación a este destino, así como a cada regla que depende de ella. Ten mucho cuidado, ya que esto puede tener efectos de gran alcance. En caso de duda, agrega valores definidos a local_defines .
|
implementation_deps
|
deps , los encabezados y las rutas de inclusión de estas bibliotecas (y todas sus dependencias transitivas) solo se usan para la compilación de esta biblioteca, no para las que dependen de ella. Las bibliotecas especificadas con implementation_deps aún están vinculadas en destinos binarios que dependen de esta biblioteca.
Por ahora, el uso se limita a cc_library y está protegido por la marca |
include_prefix
|
Cuando se establecen, los encabezados del atributo Se quita el prefijo del atributo |
includes
|
Sujeto a la sustitución "Make variable".
Cada string se antepone con Los encabezados deben agregarse a src o hdr; de lo contrario, no estarán disponibles para las reglas dependientes cuando la compilación se coloque en una zona de pruebas (el valor predeterminado). |
linkopts
|
LINKOPTS antes de vincular el destino binario.
Se supone que cada elemento de esta lista que no comienza con |
linkstamp
|
base .
|
linkstatic
|
cc_binary y cc_test , vincula el objeto binario en modo estático. Para cc_library.linkstatic , consulta a continuación.
De forma predeterminada, esta opción está activada para
Si está habilitada y es un objeto binario o una prueba, esta opción indica a la herramienta de compilación que se vincule en Existen tres maneras diferentes de vincular un ejecutable:
El atributo
Si es |
local_defines
|
-D y se agrega a la línea de comandos de compilación para este destino, pero no a sus dependientes.
|
nocopts
|
COPTS preexistente que coincida con esta expresión regular (incluidos los valores especificados de forma explícita en el atributo copts de la regla) se quitará de COPTS a los efectos de compilar esta regla.
Rara vez se necesita este atributo.
|
strip_include_prefix
|
Cuando se configuran, los encabezados del atributo Si es una ruta relativa, se toma como una relativa relativa al paquete. Si es absoluto, se entiende como una ruta relativa al repositorio. El prefijo del atributo |
textual_hdrs
|
Esta es la ubicación para declarar archivos de encabezado que no se pueden compilar por su cuenta; es decir, siempre deben incluirse textualmente en otros archivos de origen para compilar código válido. |
win_def_file
|
Este atributo solo debe usarse cuando Windows es la plataforma seleccionada. Se puede usar para exportar símbolos durante la vinculación de una biblioteca compartida. |
CC_proto_library
Ver el origen de las reglascc_proto_library(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
cc_proto_library
genera código C++ a partir de archivos .proto
.
deps
debe apuntar a reglas de 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 |
Es un nombre único para este destino. |
deps
|
proto_library para las que se generará código C++.
|
CC_biblioteca_compartida
Ver el origen de las reglascc_shared_library(name, deps, additional_linker_inputs, dynamic_deps, exports_filter, shared_lib_name, tags, user_link_flags, 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
, se vinculan de forma estática foo
y baz
, este último es una dependencia transitiva. No vincula bar
porque ya está proporcionado de manera dinámica por el bar_shared
de dynamic_dep
.
foo_shared
usa un archivo *.lds de secuencia de comandos del vinculador para controlar qué símbolos se deben exportar. La lógica de la regla cc_shared_library
no controla qué símbolos se exportan, solo usa lo que se supone que se exportará para dar errores durante la fase de análisis si dos bibliotecas compartidas exportan los mismos destinos.
Se supone que se exporta cada dependencia directa de cc_shared_library
. Por lo tanto, durante el análisis, Bazel supone que foo_shared
exporta
foo
. No se supone que foo_shared
exporte baz
. También se supone que se exportó cada destino que coincide con exports_filter
.
Cada cc_library
del ejemplo debe aparecer como máximo en una cc_shared_library
. Si también quisiéramos vincular baz
a bar_shared
, debemos 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 del nombre libbar.so
que tendría de forma predeterminada en Linux.
Errores
Two shared libraries in dependencies export the same symbols.
Esto sucederá cada vez que crees un destino con dos dependencias
cc_shared_library
diferentes que exporten el mismo destino. Para solucionar este problema, debes detener la exportación de las bibliotecas en una de las dependencias de 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 de cc_shared_library
diferentes que vinculen el mismo destino de forma estática.
Similar al error con las exportaciones.
Una forma de solucionar este problema es dejar de vincular la biblioteca a una de las dependencias de cc_shared_library
. Al mismo tiempo, la que aún lo vincula necesita exportar la biblioteca para que la que no la vincula mantenga la visibilidad de los símbolos. Otra forma es extraer una tercera biblioteca que exporte el destino.
Una tercera manera es etiquetar al culpable cc_library
con LINKABLE_MORE_THAN_ONCE
, pero esta corrección debe ser poco común, y debes asegurarte de que cc_library
sea seguro vincular 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 de cc_shared_library
, pero ya se vinculó a un cc_shared_library
diferente en dynamic_deps
y no se exporta.
La solución es exportarlo desde la dependencia cc_shared_library
o extraer un tercer cc_shared_library
que lo exporte.
Do not place libraries which only contain a precompiled dynamic library in deps.
Si tienes una biblioteca dinámica compilada previamente, no es necesario que no se pueda vincular estáticamente al destino cc_shared_library
actual que estás creando. Por lo tanto, no pertenece a deps
de cc_shared_library
. Si esta biblioteca dinámica precompilada es una dependencia de uno de tus cc_libraries
, cc_library
debe depender directamente de ella.
Trying to export a library already exported by a different shared library
Verás este error si, en la regla actual, reclamas la exportación de un destino que ya exporta una de tus dependencias dinámicas.
Para solucionar este problema, quita el destino de deps
y confía en él de la dependencia dinámica, o asegúrate de que exports_filter
no lo detecte.
Argumentos
Atributos | |
---|---|
name |
Es un nombre único para este destino. |
deps
|
Cualquier dependencia de biblioteca transitiva de estas dependencias directas se vinculará a esta biblioteca
compartida, siempre que no haya sido vinculada por un
Durante el análisis, la implementación de reglas considerará que la biblioteca compartida exportó cualquier destino que se enumera en
La implementación también activará errores cada vez que la misma biblioteca esté vinculada de forma estática a más de un |
additional_linker_inputs
|
user_link_flags .
|
dynamic_deps
|
cc_shared_library dependencias de las que depende el objetivo actual.
La implementación de |
exports_filter
|
Ya se entiende que la biblioteca compartida exportó
Ten en cuenta que, en realidad, este atributo no agrega un perímetro de dependencia a esos objetivos. En su lugar, el borde perimetral debe ser creado por Se permite la siguiente sintaxis:
|
shared_lib_name
|
|
user_link_flags
|
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
|
Este atributo solo debe usarse cuando Windows es la plataforma seleccionada. Se puede usar para exportar símbolos durante la vinculación de una biblioteca compartida. |
sugerencias_de_precarga
Ver el origen de las reglasfdo_prefetch_hints(name, compatible_with, deprecation, distribs, features, licenses, profile, restricted_to, tags, target_compatible_with, testonly, visibility)
Representa un perfil de sugerencias de carga previa de FDO que se encuentra en el lugar de trabajo o en una ruta de acceso absoluta especificada. Ejemplos:
fdo_prefetch_hints( name = "hints", profile = "//path/to/hints:profile.afdo", ) fdo_profile( name = "hints_abs", absolute_path_profile = "/absolute/path/profile.afdo", )
Argumentos
Atributos | |
---|---|
name |
Es un nombre único para este destino. |
profile
|
|
perfil_fdo
Ver el origen de las reglasfdo_profile(name, absolute_path_profile, compatible_with, deprecation, distribs, features, licenses, profile, proto_profile, restricted_to, tags, target_compatible_with, testonly, visibility)
Representa un perfil de FDO que se encuentra en el lugar de trabajo o en una ruta de acceso absoluta específica. Ejemplos:
fdo_profile( name = "fdo", profile = "//path/to/fdo:profile.zip", ) fdo_profile( name = "fdo_abs", absolute_path_profile = "/absolute/path/profile.zip", )
Argumentos
Atributos | |
---|---|
name |
Es un nombre único para este destino. |
absolute_path_profile
|
|
profile
|
|
proto_profile
|
|
propulsor
Ver el origen de las reglaspropeller_optimize(name, compatible_with, deprecation, distribs, features, ld_profile, licenses, restricted_to, tags, target_compatible_with, testonly, 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" ) propeller_optimize( name = "layout_absolute", absolute_cc_profile = "/absolute/cc_profile.txt", absolute_ld_profile = "/absolute/ld_profile.txt" )
Argumentos
Atributos | |
---|---|
name |
Es un nombre único para este destino. |
ld_profile
|
|
Cc_prueba
Ver el origen de las reglascc_test(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, includes, licenses, linkopts, linkstatic, local, local_defines, malloc, nocopts, restricted_to, shard_count, size, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility, win_def_file)
Argumentos
Atributos | |
---|---|
name |
Es un nombre único para este destino. |
deps
|
Pueden ser objetivos |
srcs
|
Se compilarán todos los archivos No se compilará un archivo Se deben mencionar todos los archivos Si el nombre de una regla está en
Tipos de archivos
...y cualquier regla que produzca esos archivos. Las diferentes extensiones denotan diferentes lenguajes de programación de acuerdo con la convención de GCC. |
additional_linker_inputs
|
Por ejemplo, se pueden proporcionar archivos .res compilados de Windows aquí para incorporarlos en el destino binario. |
copts
|
Cada string de este atributo se agrega en el orden dado a
Si el paquete declara el |
defines
|
-D y se agrega a la línea de comandos de compilación a este destino, así como a cada regla que depende de ella. Ten mucho cuidado, ya que esto puede tener efectos de gran alcance. En caso de duda, agrega valores definidos a local_defines .
|
includes
|
Sujeto a la sustitución "Make variable".
Cada string se antepone con Los encabezados deben agregarse a src o hdr; de lo contrario, no estarán disponibles para las reglas dependientes cuando la compilación se coloque en una zona de pruebas (el valor predeterminado). |
linkopts
|
LINKOPTS antes de vincular el destino binario.
Se supone que cada elemento de esta lista que no comienza con |
linkstatic
|
cc_binary y cc_test , vincula el objeto binario en modo estático. Para cc_library.linkstatic , consulta a continuación.
De forma predeterminada, esta opción está activada para
Si está habilitada y es un objeto binario o una prueba, esta opción indica a la herramienta de compilación que se vincule en Existen tres maneras diferentes de vincular un ejecutable:
El atributo
Si es |
local_defines
|
-D y se agrega a la línea de comandos de compilación para este destino, pero no a sus dependientes.
|
malloc
|
De forma predeterminada, los objetos binarios de C++ se vinculan con |
nocopts
|
COPTS preexistente que coincida con esta expresión regular (incluidos los valores especificados de forma explícita en el atributo copts de la regla) se quitará de COPTS a los efectos de compilar esta regla.
Rara vez se necesita este atributo.
|
stamp
|
Los objetos binarios con sellos no se vuelven a compilar, a menos que cambien sus dependencias. |
win_def_file
|
Este atributo solo debe usarse cuando Windows es la plataforma seleccionada. Se puede usar para exportar símbolos durante la vinculación de una biblioteca compartida. |
CC_cadena
Ver el origen de las reglascc_toolchain(name, all_files, ar_files, as_files, compatible_with, compiler, compiler_files, compiler_files_without_includes, coverage_files, cpu, deprecation, distribs, dwp_files, dynamic_runtime_lib, exec_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, restricted_to, static_runtime_lib, strip_files, supports_header_parsing, supports_param_files, tags, target_compatible_with, testonly, toolchain_config, toolchain_identifier, visibility)
Representa una cadena de herramientas de C++.
Esta regla es responsable de lo siguiente:
-
Recopilar todos los artefactos necesarios para que se ejecuten las acciones de C++ Esto se hace mediante atributos como
all_files
,compiler_files
,linker_files
y otros atributos que terminan en_files
. Por lo general, estos son grupos de archivos que globalizan todos los archivos necesarios. -
Generar líneas de comandos correctas para acciones de C++ Puedes hacerlo con el proveedor
CcToolchainConfigInfo
(más detalles a continuación).
Usa el atributo toolchain_config
para configurar la cadena de herramientas de C++.
Consulta también esta
página
para obtener documentación elaborada sobre la configuración de la cadena de herramientas de C++ y la selección de la cadena de herramientas.
Usa tags = ["manual"]
para evitar que se creen y configuren innecesariamente las cadenas de herramientas cuando se invoca a bazel build //...
.
Argumentos
Atributos | |
---|---|
name |
Es un nombre único para este destino. |
all_files
|
all_files es un superconjunto de todos los demás atributos que proporcionan artefactos (p.ej., la compilación de linktamp necesita archivos de compilación y de vínculo, por lo que toma all_files ).
Esto es lo que contiene |
ar_files
|
Recopilación de todos los artefactos de cc_toolchain necesarios para las acciones de archivo. |
as_files
|
Es una colección de todos los artefactos de cc_toolchain necesarios para las acciones de ensamblado. |
compiler
|
toolchain_identifier . Será una noop
después de
la migración de CROSSTOOL a Starlark
y se quitará de
#7075.
Cuando esté configurada, se usará para realizar la selección crosstool_config.toolchain. Esta tendrá prioridad sobre la opción --cpu Bazel. |
compiler_files
|
|
compiler_files_without_includes
|
|
coverage_files
|
|
cpu
|
Cuando esté configurada, se usará para realizar la selección crosstool_config.toolchain. Esta tendrá prioridad sobre la opción --cpu Bazel. |
dwp_files
|
|
dynamic_runtime_lib
|
Se usará cuando se habilite la función “static_link_cpp_runtimes” y vinculemos las dependencias de manera dinámica. |
exec_transition_for_inputs
|
|
libc_top
|
|
linker_files
|
|
module_map
|
|
objcopy_files
|
|
static_runtime_lib
|
Se usará cuando se habilite la función “static_link_cpp_runtimes” y vinculemos las dependencias de manera estática. |
strip_files
|
|
supports_header_parsing
|
|
supports_param_files
|
|
toolchain_config
|
cc_toolchain_config_info .
|
toolchain_identifier
|
Hasta que se solucione el problema #5380, esta es la forma recomendada de asociar |
cc_cadena_paquete
Ver el origen de las reglascc_toolchain_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
Representa una colección de cadenas de herramientas de C++.
Esta regla es responsable de lo siguiente:
- Recopilando todas las cadenas de herramientas de C++ relevantes
-
Selecciona una cadena de herramientas según las opciones
--cpu
y--compiler
que se pasan a Bazel.
Consulta también esta página para obtener documentación elaborada sobre la configuración de la cadena de herramientas de C++ y la selección de la cadena de herramientas.
Argumentos
Atributos | |
---|---|
name |
Es un nombre único para este destino. |
toolchains
|
cc_toolchain "<cpu>" se usará cuando solo se pase --cpu
a Bazel, y se usará "<cpu>|<compiler>" cuando
se pasen --cpu y --compiler a Bazel. Ejemplo:
cc_toolchain_suite( name = "toolchain", toolchains = { "piii|gcc": ":my_cc_toolchain_for_piii_using_gcc", "piii": ":my_cc_toolchain_for_piii_using_default_compiler", }, ) |