Regras
- cc_binary
- cc_import
- cc_library
- cc_proto_library
- cc_shared_library
- cc_static_library
- fdo_prefetch_hints
- fdo_profile
- memprof_profile
- propeller_optimize
- cc_test
- cc_toolchain
- cc_toolchain_suite
cc_binary
Acessar a origem da regracc_binary(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local_defines, malloc, nocopts, output_licenses, restricted_to, stamp, tags, target_compatible_with, testonly, toolchains, visibility, win_def_file)
Alvos de saída implícitos
name.stripped
(somente criado se solicitado explicitamente): uma versão simplificada do binário. Ostrip -g
é executado no binário para remover símbolos de depuração. Outras opções de remoção podem ser fornecidas na linha de comando usando--stripopt=-foo
. Essa saída só é criada se for explicitamente solicitada.name.dwp
(somente criado se solicitado explicitamente): se Fission estiver ativado, um arquivo de pacote de informações de depuração adequado para depurar binários implantados remotamente. Caso contrário: um arquivo vazio.
Argumentos
Atributos | |
---|---|
name |
Nome, obrigatório Um nome exclusivo para essa segmentação. |
deps
|
Lista de rótulos; o padrão é Eles podem ser alvos |
srcs
|
Lista de rótulos; o padrão é Todos os arquivos Um arquivo Todos os arquivos Se o nome de uma regra estiver no
Tipos de arquivos
e as regras que produzem esses arquivos. Extensões diferentes denotam linguagens de programação diferentes de acordo com a convenção gcc. |
additional_linker_inputs
|
Lista de rótulos; o padrão é Por exemplo, arquivos .res do Windows compilados podem ser fornecidos aqui para serem incorporados no destino binário. |
copts
|
Lista de strings. O padrão é
Cada string neste atributo é adicionada na ordem especificada a
Se o pacote declarar o feature
|
defines
|
Lista de strings. O padrão é -D e adicionada à linha de comando de compilação para esse destino, bem como a todas as regras que dependem dele. Tenha muito cuidado, porque isso pode ter efeitos de longo alcance. Em caso de dúvida, adicione valores definidos a
local_defines .
|
includes
|
Lista de strings. O padrão é
Sujeito à substituição de "Make variable".
Cada string é prefixada com Os cabeçalhos precisam ser adicionados a srcs ou hdrs. Caso contrário, eles não estarão disponíveis para regras dependentes quando a compilação estiver em sandbox (padrão). |
link_extra_lib
|
Rótulo: o padrão é
Por padrão, os binários C++ são vinculados a |
linkopts
|
Lista de strings. O padrão é LINKOPTS antes
de vincular o destino binário.
Cada elemento dessa lista que não começa com |
linkshared
|
Booleano; não configurável; o padrão é linkshared=True na regra. Por padrão,
essa opção fica desativada.
A presença dessa flag significa que a vinculação ocorre com a flag
Se você especificar |
linkstatic
|
Booleano. O padrão é cc_binary e
cc_test : vincule o binário no modo
estático. Para cc_library.linkstatic : confira abaixo.
Por padrão, essa opção fica ativada para
Se ativada e se for um binário ou teste, essa opção instrui a ferramenta de build a vincular
Na verdade, há três maneiras diferentes de vincular um executável:
O atributo
Se for |
local_defines
|
Lista de strings. O padrão é -D e adicionada à linha de comando de compilação para esse destino, mas não aos dependentes.
|
malloc
|
Rótulo; o padrão é
Por padrão, os binários C++ são vinculados a |
nocopts
|
String; o padrão é COPTS preexistente que corresponda a essa expressão regular (incluindo valores especificados explicitamente no atributo copts da regra) será removido de COPTS para fins de compilação dessa regra.
Esse atributo raramente é necessário.
|
stamp
|
Inteiro; padrão é
Os binários carimbados não são reconstruídos, a menos que as dependências mudem. |
win_def_file
|
Rótulo: o padrão é Esse atributo só deve ser usado quando o Windows for a plataforma de destino. Ela pode ser usada para exportar símbolos durante a vinculação de uma biblioteca compartilhada. |
cc_import
Acessar a origem da regracc_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)
As regras cc_import
permitem que os usuários importem bibliotecas C/C++ pré-compiladas.
Confira a seguir os casos de uso típicos:
1. Vincular uma 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. Vincular uma biblioteca compartilhada (Unix)
cc_import( name = "mylib", hdrs = ["mylib.h"], shared_library = "libmylib.so", )3. Vincular uma biblioteca compartilhada com a biblioteca de interface (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. Vincular uma biblioteca compartilhada com
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. Vinculação à biblioteca estática ou compartilhada
No 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, )No 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
oferece suporte a um atributo de inclusão. Por exemplo:
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 |
Nome: obrigatório Um nome exclusivo para o destino. |
deps
|
Lista de rótulos; o padrão é deps
em Atributos típicos definidos pela
maioria das regras de build.
|
hdrs
|
Lista de rótulos; o padrão é |
alwayslink
|
Booleano; o padrão é Se sempre o link não funcionar com o VS 2017 no Windows, isso se deve a um problema conhecido, faça upgrade do seu VS 2017 para a versão mais recente. |
interface_library
|
Rótulo: o padrão é Tipos de arquivo permitidos:
|
shared_library
|
Rótulo: o padrão é Tipos de arquivo permitidos:
|
static_library
|
Rótulo: o padrão é Tipos de arquivo permitidos:
|
system_provided
|
Booleano. O padrão é interface_library precisa ser especificado e
shared_library precisa estar vazio.
|
cc_library
Exibir origem da regracc_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, 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)
Verificação de inclusão de cabeçalho
Todos os arquivos de cabeçalho usados no build precisam ser declarados nas regras hdrs
ou
srcs
de cc_*
. Isso é obrigatório.
Para regras cc_library
, os cabeçalhos em hdrs
compreendem a interface pública da
biblioteca e podem ser incluídos diretamente nos arquivos em hdrs
e
srcs
da própria biblioteca, bem como nos arquivos em hdrs
e
srcs
das regras cc_*
que listam a biblioteca no deps
.
Os cabeçalhos em srcs
só podem ser incluídos diretamente dos arquivos em hdrs
e srcs
da própria biblioteca. Ao decidir se vai colocar um cabeçalho em
hdrs
ou srcs
, pergunte se você quer que os consumidores dessa biblioteca
possam incluí-lo diretamente. Essa é aproximadamente a mesma decisão entre
a visibilidade de public
e private
em linguagens de programação.
As regras cc_binary
e cc_test
não têm uma interface exportada, portanto, elas
também não têm um atributo hdrs
. Todos os cabeçalhos que pertencem diretamente ao binário ou ao teste devem ser listados em srcs
.
Para ilustrar essas regras, confira o exemplo a seguir.
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"], )
As inclusões diretas permitidas neste exemplo estão listadas na tabela abaixo. Por exemplo,
foo.cc
pode incluir diretamente foo.h
e bar.h
, mas
não baz.h
.
Incluindo arquivo | Inclusões 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 |
As regras de verificação de inclusão só se aplicam a inclusões diretas. No exemplo acima, foo.cc
pode incluir bar.h
, que pode incluir baz.h
, que, por sua vez, tem permissão para incluir baz-impl.h
. Tecnicamente, a
compilação de um arquivo .cc
pode incluir transitivamente qualquer arquivo de cabeçalho
no hdrs
ou srcs
em
qualquer cc_library
no fechamento transitivo deps
. Nesse
caso, o compilador pode ler baz.h
e baz-impl.h
ao compilar foo.cc
, mas foo.cc
não pode
conter #include "baz.h"
. Para que isso seja
permitido, baz
precisa ser adicionado à deps
de foo
.
O Bazel depende do suporte ao conjunto de ferramentas para aplicar as regras de verificação de inclusão.
O recurso layering_check
precisa ter suporte do conjunto de ferramentas
e ser solicitado explicitamente, por exemplo, usando a
flag de linha de comando --features=layering_check
ou o
parâmetro features
da
função package
. As cadeias de ferramentas
fornecidas pelo Bazel só oferecem suporte a esse recurso com o clang no Unix e no macOS.
Argumentos
Atributos | |
---|---|
name |
Nome, obrigatório Um nome exclusivo para essa segmentação. |
deps
|
Lista de rótulos; o padrão é Eles podem ser alvos |
srcs
|
Lista de rótulos; o padrão é Todos os arquivos Um arquivo Todos os arquivos Se o nome de uma regra estiver em
Tipos de arquivos
e as regras que produzem esses arquivos. Extensões diferentes indicam linguagens de programação distintas de acordo com a convenção gcc. |
hdrs
|
Lista de rótulos; o padrão é Esse é o local preferencial para declarar arquivos de cabeçalho que
descrevem a interface da biblioteca. Esses cabeçalhos serão disponibilizados para inclusão por origens nesta regra ou em regras dependentes.
Os cabeçalhos que não serão incluídos por um cliente dessa biblioteca precisarão ser
listados no atributo |
additional_compiler_inputs
|
Lista de rótulos; o padrão é |
additional_linker_inputs
|
Lista de rótulos; o padrão é Por exemplo, arquivos .res do Windows compilados podem ser fornecidos aqui para serem incorporados no destino binário. |
alwayslink
|
Booleano; o padrão é srcs , mesmo que alguns não contenham símbolos referenciados pelo binário.
Isso é útil se o código não for chamado explicitamente por código no
binário, por exemplo, se o código for registrado para receber algum callback
fornecido por algum serviço.
Se sempre o link não funcionar com o VS 2017 no Windows, isso se deve a um problema conhecido, faça upgrade do seu VS 2017 para a versão mais recente. |
copts
|
Lista de strings. O padrão é
Cada string neste atributo é adicionada na ordem especificada a
Se o pacote declarar o feature
|
defines
|
Lista de strings. O padrão é -D e adicionada à linha de comando de compilação para esse destino,
bem como a todas as regras que dependem dele. Tenha muito cuidado, porque isso pode ter efeitos de longo alcance. Em caso de dúvida, adicione valores definidos a
local_defines .
|
implementation_deps
|
Lista de rótulos; o padrão é deps , os cabeçalhos e os caminhos de inclusão dessas bibliotecas (e todas as
dependências transitivas) são usados apenas para compilação dessa biblioteca, e não para bibliotecas que
dependem dela. As bibliotecas especificadas com implementation_deps ainda são vinculadas em
destinos binários que dependem dessa biblioteca.
Por enquanto, o uso é limitado a cc_libraries e protegido pela flag
|
include_prefix
|
String; o padrão é Quando definido, os cabeçalhos no atributo O prefixo no atributo |
includes
|
Lista de strings. O padrão é
Sujeito à substituição de "Make variable".
Cada string é prefixada com Os cabeçalhos precisam ser adicionados a srcs ou hdrs. Caso contrário, eles não estarão disponíveis para regras dependentes quando a compilação estiver em sandbox (padrão). |
linkopts
|
Lista de strings. O padrão é LINKOPTS antes
de vincular o destino binário.
Cada elemento dessa lista que não começa com |
linkstamp
|
Rótulo: o padrão é base .
|
linkstatic
|
Booleano; o padrão é cc_binary e
cc_test : vincule o binário no modo
estático. Para cc_library.linkstatic : consulte abaixo.
Por padrão, essa opção fica ativada para
Se ativada e se for um binário ou teste, essa opção instrui a ferramenta de build a vincular
Na verdade, há três maneiras diferentes de vincular um executável:
O atributo
Se for |
local_defines
|
Lista de strings. O padrão é -D e adicionada à linha de comando de compilação para esse destino,
mas não aos seus dependentes.
|
nocopts
|
String; o padrão é COPTS preexistente que corresponda a essa expressão regular (incluindo valores especificados explicitamente no atributo copts da regra) será removido de COPTS para fins de compilação dessa regra.
Esse atributo raramente será necessário.
|
strip_include_prefix
|
String; o padrão é Quando definido, os cabeçalhos no atributo Se for um caminho relativo, ele será considerado como relativo ao pacote. Se for absoluto, ele será entendido como um caminho relativo ao repositório. O prefixo no atributo |
textual_hdrs
|
Lista de rótulos; o padrão é Esse é o local para declarar arquivos de cabeçalho que não podem ser compilados por conta própria. Ou seja, eles sempre precisam ser incluídos textualmente por outros arquivos de origem para criar um código válido. |
win_def_file
|
Rótulo; o padrão é Esse atributo só deve ser usado quando o Windows for a plataforma de destino. Ele pode ser usado para exportar símbolos durante a vinculação de uma biblioteca compartilhada. |
cc_proto_library
Exibir origem da regracc_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
gera código C++ de arquivos .proto
.
deps
precisa apontar para regras proto_library
.
Exemplo:
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 |
Nome: obrigatório Um nome exclusivo para o destino. |
deps
|
Lista de rótulos; o padrão é proto_library
para gerar código C++.
|
cc_shared_library
Exibir origem da regracc_shared_library(name, deps, additional_linker_inputs, dynamic_deps, exports_filter, shared_lib_name, tags, user_link_flags, win_def_file)
Ele produz uma biblioteca compartilhada.
Exemplo
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"], )
No exemplo, foo_shared
vincula estaticamente foo
e baz
, sendo que o último é uma dependência transitiva. Ele não
vincula bar
porque já é fornecido dinamicamente pelo
bar_shared
do dynamic_dep
.
O foo_shared
usa um arquivo de script de vinculação *.lds para controlar quais
símbolos devem ser exportados. A lógica da regra cc_shared_library
não
controla quais símbolos são exportados, ela só usa o que é presumido ser
exportado para gerar erros durante a fase de análise se duas bibliotecas compartilhadas exportarem as
mesmas metas.
Todas as dependências diretas de cc_shared_library
são exportadas. Portanto, o Bazel assume durante a análise que foo
está sendo
exportado por foo_shared
. Não se presume que baz
seja exportado
por foo_shared
. Cada destino correspondente ao exports_filter
também é exportado.
Cada cc_library
no exemplo precisa aparecer no máximo em um
cc_shared_library
. Se quiséssemos vincular baz
também a
bar_shared
, precisaríamos adicionar
tags = ["LINKABLE_MORE_THAN_ONCE"]
a baz
.
Devido ao atributo shared_lib_name
, o arquivo produzido por
bar_shared
terá o nome bar.so
, em vez
do nome libbar.so
que ele teria por padrão no Linux.
Erros
Two shared libraries in dependencies export the same symbols.
Isso vai acontecer sempre que você criar um destino com duas dependências
cc_shared_library
diferentes que exportam o mesmo destino. Para corrigir isso,
você precisa interromper a exportação das bibliotecas em uma das
dependências cc_shared_library
.
Two shared libraries in dependencies link the same library statically
Isso vai acontecer sempre que você criar um novo cc_shared_library
com duas
dependências cc_shared_library
diferentes que vinculam o mesmo destino de forma estática.
Semelhante ao erro das exportações.
Uma maneira de corrigir isso é parar de vincular a biblioteca a uma das
dependências cc_shared_library
. Ao mesmo tempo, o que ainda vincula
precisa exportar a biblioteca para que o que não vincula mantenha a visibilidade
dos símbolos. Outra maneira é extrair uma terceira biblioteca que exporta o destino.
Uma terceira maneira é marcar o cc_library
do culpado com LINKABLE_MORE_THAN_ONCE
,
mas essa correção é rara, e você precisa ter certeza de que
o cc_library
pode ser vinculado mais de uma vez.
'//foo:foo' is already linked statically in '//bar:bar' but not exported`
Isso significa que uma biblioteca no fechamento transitivo da deps
pode ser acessada
sem passar por uma das dependências cc_shared_library
, mas já está
vinculada a uma cc_shared_library
diferente em dynamic_deps
e não é
exportada.
A solução é exportá-lo da dependência cc_shared_library
ou extrair
uma terceira cc_shared_library
que o exporta.
Do not place libraries which only contain a precompiled dynamic library in deps.
Se você tiver uma biblioteca dinâmica pré-compilada, ela não precisa e não pode ser
vinculada estaticamente ao destino cc_shared_library
atual que você está
criando. Portanto, ele não pertence a deps
do
cc_shared_library
. Se essa biblioteca dinâmica pré-compilada for uma dependência de um
dos seus cc_libraries
, o cc_library
precisará depender
diretamente dela.
Trying to export a library already exported by a different shared library
Você verá esse erro se, na regra atual, alegar exportar um destino que já está sendo exportado por uma das dependências dinâmicas.
Para corrigir isso, remova o destino de deps
e confie apenas na dependência
dinâmica ou verifique se o exports_filter
não captura esse destino.
Argumentos
Atributos | |
---|---|
name |
Nome: obrigatório Um nome exclusivo para essa segmentação. |
deps
|
Lista de rótulos. O padrão é
Qualquer dependência de biblioteca transitiva dessas dependências diretas será vinculada a essa biblioteca
compartilhada, desde que não tenha sido vinculada por um
Durante a análise, a implementação da regra considera que qualquer destino listado em
A implementação também vai acionar erros sempre que a mesma biblioteca for vinculada estaticamente
a mais de um |
additional_linker_inputs
|
Lista de rótulos; o padrão é user_link_flags .
|
dynamic_deps
|
Lista de rótulos; o padrão é cc_shared_library das quais o destino atual depende.
A implementação de |
exports_filter
|
Lista de strings. O padrão é
Qualquer
Observe que esse atributo não está realmente adicionando uma borda de dependência a esses destinos.
Ela precisa ser criada por A sintaxe a seguir é permitida:
|
shared_lib_name
|
String; o padrão é |
user_link_flags
|
Lista de strings. O padrão é 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
|
Rótulo: o padrão é Esse atributo só deve ser usado quando o Windows for a plataforma de destino. Ela pode ser usada para exportar símbolos durante a vinculação de uma biblioteca compartilhada. |
cc_static_library
Ver origem da regracc_static_library(name, deps, tags)Produz uma biblioteca estática a partir de uma lista de destinos e das respectivas dependências transitivas.
A biblioteca estática resultante contém os arquivos de objeto dos destinos listados em
deps
, bem como as dependências transitivas deles, com preferência dada aos
objetos PIC
.
Grupos de saída
linkdeps
Um arquivo de texto contendo os rótulos dessas dependências transitivas de destinos listados em
deps
que não contribuíram com arquivos de objeto para a biblioteca estática, mas
forneceram pelo menos uma biblioteca estática, dinâmica ou de interface. A biblioteca estática resultante
pode exigir que essas bibliotecas estejam disponíveis no momento da vinculação.
linkopts
Um arquivo de texto contendo o linkopts
fornecido pelo usuário de todas as dependências
transitivas de destinos listados em deps
.
Símbolos duplicados
Por padrão, a regra cc_static_library
verifica se a biblioteca estática
resultante não contém símbolos duplicados. Se isso acontecer, o build vai falhar com uma mensagem
de erro que lista os símbolos duplicados e os arquivos de objeto que os contêm.
Essa verificação pode ser desativada por destino ou pacote definindo
features = ["-symbol_check"]
ou globalmente por
--features=-symbol_check
.
Suporte de ferramental para symbol_check
Os conjuntos de ferramentas C++ configurados automaticamente e enviados com o Bazel são compatíveis com o
recurso symbol_check
em todas as plataformas. As toolchains personalizadas podem adicionar suporte a
ele de duas maneiras:
- Implementar a ação
ACTION_NAMES.validate_static_library
e ativá-la com o recursosymbol_check
. O conjunto de ferramentas na ação é invocado com dois argumentos: a biblioteca estática para procurar símbolos duplicados e o caminho de um arquivo que precisa ser criado se a verificação for aprovada. - O recurso
symbol_check
adiciona flags de arquivador que fazem com que a ação de criação da biblioteca estática falhe em símbolos duplicados.
Argumentos
Atributos | |
---|---|
name |
Nome, obrigatório Um nome exclusivo para essa segmentação. |
deps
|
Lista de rótulos. O padrão é Dependências que não fornecem arquivos de objetos não são incluídas na biblioteca
estática, mas os rótulos são coletados no arquivo fornecido pelo
grupo de saída |
fdo_prefetch_hints
Acessar a origem da regrafdo_prefetch_hints(name, compatible_with, deprecation, distribs, features, licenses, profile, restricted_to, tags, target_compatible_with, testonly, visibility)
Representa um perfil de dicas de pré-carregamento de FDO que está no espaço de trabalho ou em um caminho absoluto especificado. Exemplos:
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 |
Nome: obrigatório Um nome exclusivo para essa segmentação. |
profile
|
Rótulo: o padrão é |
fdo_profile
Acessar a origem da regrafdo_profile(name, absolute_path_profile, compatible_with, deprecation, distribs, features, licenses, profile, proto_profile, restricted_to, tags, target_compatible_with, testonly, visibility)
Representa um perfil de FDO que está no espaço de trabalho ou em um caminho absoluto especificado. Exemplos:
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 |
Nome: obrigatório Um nome exclusivo para essa segmentação. |
absolute_path_profile
|
String; o padrão é |
profile
|
Rótulo; o padrão é |
proto_profile
|
Rótulo; o padrão é |
memprof_profile
Acessar a origem da regramemprof_profile(name, absolute_path_profile, compatible_with, deprecation, distribs, features, licenses, profile, restricted_to, tags, target_compatible_with, testonly, visibility)
Representa um perfil MEMPROF que está no espaço de trabalho ou em um caminho absoluto especificado. Exemplos:
memprof_profile( name = "memprof", profile = "//path/to/memprof:profile.afdo", ) memprof_profile( name = "memprof_abs", absolute_path_profile = "/absolute/path/profile.afdo", )
Argumentos
Atributos | |
---|---|
name |
Nome: obrigatório Um nome exclusivo para o destino. |
absolute_path_profile
|
String. O padrão é |
profile
|
Rótulo: o padrão é |
propeller_optimize
Acessar a origem da regrapropeller_optimize(name, compatible_with, deprecation, distribs, features, ld_profile, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
Representa um perfil de otimização do Propeller no espaço de trabalho. Exemplo:
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 |
Nome: obrigatório Um nome exclusivo para o destino. |
ld_profile
|
Rótulo: o padrão é |
cc_test
Acessar a origem da regracc_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, link_extra_lib, 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 |
Nome: obrigatório Um nome exclusivo para essa segmentação. |
deps
|
Lista de rótulos; o padrão é Eles podem ser destinos |
srcs
|
Lista de rótulos; o padrão é Todos os arquivos Um arquivo Todos os arquivos Se o nome de uma regra estiver em
Tipos de arquivos
...e qualquer regra que produza esses arquivos. Extensões diferentes denotam linguagens de programação diferentes de acordo com a convenção gcc. |
additional_linker_inputs
|
Lista de rótulos; o padrão é Por exemplo, arquivos .res do Windows compilados podem ser fornecidos aqui para serem incorporados no destino binário. |
copts
|
Lista de strings. O padrão é
Cada string neste atributo é adicionada na ordem especificada a
Se o pacote declarar o feature
|
defines
|
Lista de strings. O padrão é -D e adicionada à linha de comando de compilação para esse destino, bem como a todas as regras que dependem dele. Tenha muito cuidado, porque isso pode ter efeitos de longo alcance. Em caso de dúvida, adicione valores definidos a
local_defines .
|
includes
|
Lista de strings. O padrão é
Sujeito à substituição de "Make variable".
Cada string é precedida por Os cabeçalhos precisam ser adicionados a srcs ou hdrs. Caso contrário, eles não estarão disponíveis para regras dependentes quando a compilação estiver em sandbox (padrão). |
link_extra_lib
|
Rótulo; o padrão é
Por padrão, os binários C++ são vinculados a |
linkopts
|
Lista de strings. O padrão é LINKOPTS antes
de vincular o destino binário.
Cada elemento dessa lista que não começa com |
linkstatic
|
Booleano; o padrão é cc_binary e
cc_test : vincule o binário no modo
estático. Para cc_library.linkstatic : confira abaixo.
Por padrão, essa opção fica ativada para
Se ativada e se for um binário ou teste, essa opção instrui a ferramenta de build a vincular
Existem três maneiras diferentes de vincular um executável:
O atributo
Se for |
local_defines
|
Lista de strings. O padrão é -D e adicionada à linha de comando de compilação para esse destino,
mas não aos seus dependentes.
|
malloc
|
Rótulo: o padrão é
Por padrão, os binários C++ são vinculados a |
nocopts
|
String; o padrão é COPTS preexistente que corresponda a essa expressão regular
(incluindo valores especificados explicitamente no atributo copts da regra) será removido de
COPTS para fins de compilação da regra.
Esse atributo raramente será necessário.
|
stamp
|
Inteiro; padrão é
Os binários carimbados não são reconstruídos, a menos que as dependências mudem. |
win_def_file
|
Rótulo: o padrão é Esse atributo só deve ser usado quando o Windows for a plataforma de destino. Ele pode ser usado para exportar símbolos durante a vinculação de uma biblioteca compartilhada. |
cc_toolchain
Acessar a origem da regracc_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_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 um conjunto de ferramentas C++.
Essa regra é responsável por:
-
Coleta de todos os artefatos necessários para a execução de ações em C++. Isso é feito com
atributos como
all_files
,compiler_files
,linker_files
ou outros atributos que terminam com_files
. Esses são os grupos de arquivos mais comuns que agrupam todos os arquivos necessários. -
Geração de linhas de comando corretas para ações C++. Isso é feito usando o provedor
CcToolchainConfigInfo
(detalhes abaixo).
Use o atributo toolchain_config
para configurar a cadeia de ferramentas C++.
Consulte também esta
página
para conferir a documentação de seleção e configuração de conjuntos de ferramentas C++.
Use tags = ["manual"]
para impedir que as cadeias de ferramentas sejam criadas e configuradas
desnecessariamente ao invocar bazel build //...
Argumentos
Atributos | |
---|---|
name |
Nome: obrigatório Um nome exclusivo para o destino. |
all_files
|
Rótulo: obrigatório Coleta de todos os artefatos do cc_toolchain. Esses artefatos serão adicionados como entradas a todas as ações relacionadas a rules_cc, exceto as que usam conjuntos mais precisos de artefatos dos atributos abaixo. O Bazel assume queall_files é um superconjunto
de todos os outros atributos que fornecem artefatos (por exemplo, a compilação de linkstamp precisa de arquivos de compilação
e link, então ela usa all_files ).
É o que |
ar_files
|
Rótulo: o padrão é Coleta de todos os artefatos cc_toolchain necessários para arquivar ações. |
as_files
|
Rótulo; o padrão é Coleta de todos os artefatos do cc_toolchain necessários para ações de montagem. |
compiler_files
|
Rótulo: obrigatório Coleta de todos os artefatos do cc_toolchain necessários para ações de compilação. |
compiler_files_without_includes
|
Rótulo: o padrão é |
coverage_files
|
Rótulo: o padrão é |
dwp_files
|
Rótulo: obrigatório Coleta de todos os artefatos cc_toolchain necessários para ações de dwp. |
dynamic_runtime_lib
|
Rótulo: o padrão é Ele será usado quando o recurso "static_link_cpp_runtimes" estiver ativado e as dependências forem vinculadas dinamicamente. |
exec_transition_for_inputs
|
Booleano; o padrão é |
libc_top
|
Rótulo: o padrão é |
linker_files
|
Rótulo: obrigatório Coleção de todos os artefatos cc_Dataset necessários para ações de vinculação. |
module_map
|
Rótulo; o padrão é |
objcopy_files
|
Rótulo: obrigatório Coleta de todos os artefatos cc_toolchain necessários para ações de objcopy. |
static_runtime_lib
|
Rótulo; o padrão é Isso será usado quando o recurso "static_link_cpp_runtimes" estiver ativado e as dependências forem vinculadas de forma estática. |
strip_files
|
Label, obrigatório Coleta de todos os artefatos cc_toolchain necessários para ações de remoção. |
supports_header_parsing
|
Booleano; o padrão é |
supports_param_files
|
Booleano; o padrão é |
toolchain_config
|
Rótulo: obrigatório O rótulo da regra que fornececc_toolchain_config_info .
|
toolchain_identifier
|
String; não configurável; o padrão é
Até que o problema No 5380 seja corrigido, essa é a maneira recomendada de associar |
cc_toolchain_suite
Acessar a origem da regracc_toolchain_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
Representa uma coleção de conjuntos de ferramentas C++.
Essa regra é responsável por:
- Coletar todas as cadeias de ferramentas C++ relevantes.
-
A seleção de uma toolchain dependendo das opções
--cpu
e--compiler
transmitidas ao Bazel.
Consulte também esta página para ver uma documentação elaborada sobre a configuração do conjunto de ferramentas C++ e a seleção do conjunto de ferramentas.
Argumentos
Atributos | |
---|---|
name |
Nome: obrigatório Um nome exclusivo para essa segmentação. |
toolchains
|
Dicionário que mapeia strings para rótulos, não configuráveis e obrigatório Um mapa de strings "<cpu>" ou "<cpu>|<compiler>" para um marcadorcc_toolchain . "<cpu>" será usado quando apenas --cpu
for transmitido ao Bazel, e "<cpu>|<compiler>" será usado quando
--cpu e --compiler forem transmitidos ao Bazel. Exemplo:
cc_toolchain_suite( name = "toolchain", toolchains = { "piii|gcc": ":my_cc_toolchain_for_piii_using_gcc", "piii": ":my_cc_toolchain_for_piii_using_default_compiler", }, ) |