Regras C / C++

Informar um problema Ver fonte Nightly · 8.3 · 8.2 · 8.1 ·

Regras

• cc_binary
• cc_import
• cc_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 origem da regra

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

Ele produz um binário executável.

O name do destino precisa ser o mesmo nome do arquivo de origem que é o ponto de entrada principal do aplicativo (sem a extensão). Por exemplo, se o ponto de entrada estiver em main.cc, o nome deverá ser main.

Metas de saída implícitas

• name.stripped (criado somente se solicitado explicitamente): uma versão reduzida do binário. O strip -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.
• name.dwp (criado apenas se solicitado explicitamente): se o 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 é []. A lista de outras bibliotecas a serem vinculadas ao destino binário. Podem ser destinos cc_library ou objc_library. Também é permitido colocar scripts do vinculador (.lds) em deps e referenciá-los em linkopts, mas considere additional_linker_inputs para esse caso de uso.
srcs	Lista de rótulos. O padrão é []. A lista de arquivos C e C++ que são processados para criar o destino da biblioteca. São arquivos de origem e de cabeçalho C/C++, não gerados (código-fonte normal) ou gerados. Todos os arquivos .cc, .c e .cpp serão compilados. Podem ser arquivos gerados: se um arquivo nomeado estiver no outs de alguma outra regra, esse cc_library dependerá automaticamente dessa outra regra. Arquivos de assembler puro (.s, .asm) não são pré-processados e geralmente são criados usando o assembler. Os arquivos de assembly pré-processados (.S) são pré-processados e geralmente criados usando o compilador C/C++. Um arquivo .h não será compilado, mas estará disponível para inclusão por fontes nessa regra. Os arquivos .cc e .h podem incluir diretamente os cabeçalhos listados nesses srcs ou no hdrs desta regra ou de qualquer regra listada no argumento deps. Todos os arquivos #included precisam ser mencionados no atributo hdrs desta ou de regras cc_library referenciadas. Caso contrário, eles precisam ser listados em srcs se forem particulares a esta biblioteca. Consulte "Verificação de inclusão de cabeçalho" para uma descrição mais detalhada. Os arquivos .so, .lo e .a são pré-compilados. Sua biblioteca pode ter esses elementos como srcs se usar código de terceiros para o qual não temos código-fonte. Se o atributo srcs incluir o rótulo de outra regra, o cc_library usará os arquivos de saída dessa regra como arquivos de origem para compilação. Isso é útil para geração única de código-fonte. Para uso mais frequente, é melhor implementar uma classe de regra do Starlark e usar a API cc_common. Tipos de arquivos srcs permitidos: Arquivos de origem C e C++: .c, .cc, .cpp, .cxx, .c++, .C Arquivos de cabeçalho C e C++: .h, .hh, .hpp, .hxx, .inc, .inl, .H Assembler com pré-processador C: .S Arquivo: .a, .pic.a Biblioteca "Sempre vincular": .lo, .pic.lo Biblioteca compartilhada, com ou sem versão: .so, .so.version Arquivo de objeto: .o, .pic.o ... e todas as regras que produzem esses arquivos (por exemplo, cc_embed_data). Diferentes extensões indicam diferentes linguagens de programação de acordo com a convenção do gcc.
data	Lista de rótulos. O padrão é []. A lista de arquivos necessários para essa biblioteca no tempo de execução. Consulte comentários gerais sobre data em Atributos típicos definidos pela maioria das regras de build. Se um data for o nome de um arquivo gerado, essa regra cc_library dependerá automaticamente da regra de geração. Se um data for um nome de regra, essa regra cc_library vai depender automaticamente dessa regra, e os outs dela serão adicionados automaticamente aos arquivos de dados de cc_library. Seu código C++ pode acessar esses arquivos de dados da seguinte maneira: const std::string path = devtools_build::GetDataDependencyFilepath( "my/test/data/file");
additional_linker_inputs	Lista de rótulos. O padrão é []. Dependências que são disponibilizadas apenas para o comando do vinculador C++. Ao contrário de deps, que é conceitualmente feito para compilação e vinculação de dependências, additional_linker_inputs é feito especificamente apenas para o último e sinaliza uma dependência necessária apenas para vinculação (por exemplo, arquivos referenciados em linkopts). Por exemplo, arquivos .res do Windows compilados podem ser fornecidos aqui para serem incorporados ao destino binário.
conlyopts	Lista de strings. O padrão é []. Adicione essas opções ao comando de compilação em C. Sujeito à substituição de "Criar variável" e à tokenização do shell Bourne.
copts	Lista de strings. O padrão é []. Adicione essas opções ao comando de compilação C/C++. Sujeito à substituição de "Criar variável" e à tokenização do shell Bourne. Cada string nesse atributo é adicionada na ordem especificada a COPTS antes de compilar o destino binário. As flags entram em vigor apenas para a compilação dessa meta, não das dependências dela. Portanto, tenha cuidado com os arquivos de cabeçalho incluídos em outro lugar. Todos os caminhos precisam estar relacionados ao espaço de trabalho, não ao pacote atual. Esse atributo não deve ser necessário fora de third_party. Se o pacote declarar o recurso no_copts_tokenization, a tokenização do shell Bourne será aplicada apenas a strings que consistem em uma única variável "Make".
cxxopts	Lista de strings. O padrão é []. Adicione essas opções ao comando de compilação do C++. Sujeito à substituição de "Criar variável" e à tokenização do shell Bourne.
defines	Lista de strings. O padrão é []. Lista de definições a serem adicionadas à linha de compilação deste e de todos os destinos dependentes. Sujeito à substituição da variável"Make" e à tokenização do shell Bourne. Cada string, que precisa consistir em um único token do shell Bourne, é precedida por -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. As definições são adicionadas a todos os destinos que dependem desse destino. Em caso de dúvida, adicione valores de definição a local_defines.
dynamic_deps	Lista de rótulos. O padrão é []. Essas são outras dependências de cc_shared_library de que o destino atual depende. A implementação cc_shared_library vai usar a lista de dynamic_deps (transitivamente, ou seja, também o dynamic_deps do dynamic_deps do destino atual) para decidir quais cc_libraries no deps transitivo não devem ser vinculados porque já são fornecidos por um cc_shared_library diferente.
hdrs_check	String; o padrão é "" Descontinuado, sem operação.
includes	Lista de strings. O padrão é []. Lista de diretórios de inclusão a serem adicionados à linha de compilação. Sujeito à substituição "Criar variável". Cada string é precedida pelo caminho do pacote e transmitida à cadeia de ferramentas C++ para expansão usando o recurso "include_paths" do CROSSTOOL. Uma cadeia de ferramentas executada em um sistema POSIX com definições de recursos típicas produzirá -isystem path_to_package/include_entry. Isso só deve ser usado para bibliotecas de terceiros que não estão em conformidade com o estilo do Google de escrever instruções #include. Ao contrário do COPTS, essas flags são adicionadas a essa regra e a todas as regras que dependem dela. Observação: não as regras de que ele depende. Tome muito cuidado, porque isso pode ter efeitos abrangentes. Em caso de dúvida, adicione flags "-I" a COPTS. Os caminhos include adicionados vão incluir arquivos gerados e arquivos na árvore de origem.
link_extra_lib	Rótulo; o padrão é "@bazel_tools//tools/cpp:link_extra_lib" Controla a vinculação de bibliotecas extras. Por padrão, os binários C++ são vinculados a //tools/cpp:link_extra_lib, que depende da flag de rótulo //tools/cpp:link_extra_libs. Sem definir a flag, essa biblioteca fica vazia por padrão. Definir a flag de rótulo permite vincular dependências opcionais, como substituições para símbolos fracos, interceptadores para funções de biblioteca compartilhada ou bibliotecas de tempo de execução especiais (para substituições de malloc, prefira malloc ou --custom_malloc). Definir esse atributo como None desativa esse comportamento.
linkopts	Lista de strings. O padrão é []. Adicione essas flags ao comando do vinculador C++. Sujeito à substituição da variável"Make", tokenização do shell Bourne e expansão de rótulos. Cada string nesse atributo é adicionada a LINKOPTS antes de vincular o destino binário. Cada elemento dessa lista que não começa com $ ou - é considerado o rótulo de um destino em deps. A lista de arquivos gerados por essa meta é anexada às opções do vinculador. Um erro é informado se o rótulo for inválido ou não for declarado em deps.
linkshared	Booleano; o padrão é False Crie uma biblioteca compartilhada. Para ativar esse atributo, inclua linkshared=True na sua regra. Por padrão, essa opção fica desativada. A presença dessa flag significa que a vinculação ocorre com a flag -shared para gcc, e a biblioteca compartilhada resultante é adequada para carregamento em, por exemplo, um programa Java. No entanto, para fins de build, ela nunca será vinculada ao binário dependente, já que se presume que as bibliotecas compartilhadas criadas com uma regra cc_binary só são carregadas manualmente por outros programas. Portanto, ela não deve ser considerada um substituto para a regra cc_library. Para fins de escalonabilidade, recomendamos evitar essa abordagem e simplesmente deixar java_library depender das regras de cc_library. Se você especificar linkopts=['-static'] e linkshared=True, vai receber uma única unidade completamente independente. Se você especificar linkstatic=True e linkshared=True, vai receber uma unidade única e quase independente.
linkstatic	Booleano; o padrão é True Para cc_binary e cc_test: vincule o binário no modo estático. Para cc_library.link_static: consulte abaixo. Por padrão, essa opção fica ativada para cc_binary e desativada para o restante. Se ativada e se for um binário ou teste, essa opção vai instruir a ferramenta de build a vincular .as em vez de .sos para bibliotecas de usuários sempre que possível. Bibliotecas do sistema, como libc (mas não as bibliotecas de tempo de execução C/C++, consulte abaixo), ainda são vinculadas dinamicamente, assim como bibliotecas para as quais não há uma biblioteca estática. Assim, o executável resultante ainda será vinculado de forma dinâmica, sendo, portanto, apenas principalmente estático. Há três maneiras diferentes de vincular um executável: STATIC com o recurso fully_static_link, em que tudo é vinculado de forma estática.Por exemplo, "gcc -static foo.o libbar.a libbaz.a -lm". . Esse modo é ativado especificando fully_static_link no atributo features. STATIC, em que todas as bibliotecas do usuário são vinculadas de forma estática (se uma versão estática estiver disponível), mas em que as bibliotecas do sistema (exceto as bibliotecas de tempo de execução C/C++) são vinculadas dinamicamente, por exemplo, "gcc foo.o libfoo.a libbaz.a -lm". Esse modo é ativado especificando linkstatic=True. DYNAMIC, em que todas as bibliotecas são vinculadas dinamicamente (se uma versão dinâmica estiver disponível), por exemplo, "gcc foo.o libfoo.so libbaz.so -lm". Esse modo é ativado especificando linkstatic=False. Se o atributo linkstatic ou fully_static_link em features for usado fora de //third_party, inclua um comentário perto da regra para explicar o motivo. O atributo linkstatic tem um significado diferente se usado em uma regra de cc_library(). Para uma biblioteca C++, linkstatic=True indica que apenas a vinculação estática é permitida, portanto, nenhum .so será produzido. linkstatic=False não impede a criação de bibliotecas estáticas. O atributo controla a criação de bibliotecas dinâmicas. É preciso haver muito pouco código criado com linkstatic=False em produção. Se linkstatic=False, a ferramenta de build vai criar symlinks para bibliotecas compartilhadas dependentes na área *.runfiles.
local_defines	Lista de strings. O padrão é []. Lista de definições a serem adicionadas à linha de compilação. Sujeito à substituição da variável"Make" e à tokenização do shell Bourne. Cada string, que precisa consistir em um único token do shell Bourne, é precedida por -D e adicionada à linha de comando de compilação para essa meta, mas não para os dependentes dela. Ao contrário de defines, as definições só são adicionadas à linha de comando de compilação para essa meta.
malloc	Rótulo; o padrão é "@bazel_tools//tools/cpp:malloc" Substitua a dependência padrão de malloc. Por padrão, os binários C++ são vinculados a //tools/cpp:malloc, uma biblioteca vazia. Assim, o binário acaba usando o malloc da libc. Esse rótulo precisa se referir a um cc_library. Se a compilação for para uma regra que não seja de C++, essa opção não terá efeito. O valor desse atributo é ignorado se linkshared=True for especificado.
module_interfaces	Lista de rótulos. O padrão é []. A lista de arquivos é considerada uma interface de módulos C++20. O padrão C++ não tem restrição sobre a extensão do arquivo de interface do módulo. Clang usa cppm O GCC pode usar qualquer extensão de arquivo de origem MSVC usa ixx O uso é protegido pela flag --experimental_cpp_modules.
nocopts	String; o padrão é "" Remova as opções correspondentes do comando de compilação em C++. Sujeito à substituição da variável "Make". O valor desse atributo é interpretado como uma expressão regular. Qualquer 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 não deve ser necessário nem usado fora de third_party. Os valores não são pré-processados de nenhuma outra forma além da substituição da variável "Make".
reexport_deps	Lista de rótulos. O padrão é [].
stamp	Número inteiro. O padrão é -1. Determina se as informações de build serão codificadas no binário. Valores possíveis: stamp = 1: sempre adicione as informações de build ao binário, mesmo em builds --nostamp. Evite essa configuração, já que ela pode encerrar o armazenamento em cache remoto para o binário e qualquer ação downstream que dependa dele. stamp = 0: sempre substitua as informações de build por valores constantes. Isso oferece um bom cache de resultados de build. stamp = -1: o embedding de informações de build é controlado pela flag --[no]stamp. Os binários carimbados não são recriados, a menos que as dependências mudem.
win_def_file	Rótulo; o padrão é None O arquivo DEF do Windows a ser transmitido para o vinculador. Esse atributo só deve ser usado quando o Windows é a plataforma de destino. Ele pode ser usado para exportar símbolos durante a vinculação de uma biblioteca compartilhada.

cc_import

Ver origem da regra

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

As regras do cc_import permitem que os usuários importem bibliotecas C/C++ pré-compiladas.

Confira os casos de uso típicos:
1. Como 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 = True,
)

2. Como vincular uma biblioteca compartilhada (Unix)

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

3. Como vincular uma biblioteca compartilhada a uma biblioteca de interface

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

No 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. Como vincular uma biblioteca compartilhada com system_provided=True

No 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 = True,
)

No 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 = True,
)

5. Vinculação a uma biblioteca estática ou compartilhada

No Unix:

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

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

O restante é igual no Unix e no Windows:

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

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

O cc_import oferece suporte a um atributo de inclusão. 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 essa segmentação.
deps	Lista de rótulos. O padrão é []. A lista de outras bibliotecas de que o destino depende. Consulte comentários gerais sobre deps em Atributos típicos definidos pela maioria das regras de build.
hdrs	Lista de rótulos. O padrão é []. A lista de arquivos de cabeçalho publicados por esta biblioteca pré-compilada para serem incluídos diretamente por fontes em regras dependentes.
alwayslink	Booleano; o padrão é False Se for 1, qualquer binário que dependa (direta ou indiretamente) dessa biblioteca pré-compilada em C++ vai vincular todos os arquivos de objeto arquivados na biblioteca estática, mesmo que alguns não contenham símbolos referenciados pelo binário. Isso é útil se o código não for chamado explicitamente pelo código no binário, por exemplo, se o código se registrar para receber algum callback fornecido por algum serviço. Se o alwayslink não funcionar com o VS 2017 no Windows, isso é devido a um problema conhecido. Faça upgrade do VS 2017 para a versão mais recente.
includes	Lista de strings. O padrão é []. Lista de diretórios de inclusão a serem adicionados à linha de compilação. Sujeito à substituição "Criar variável". Cada string é precedida pelo caminho do pacote e transmitida à cadeia de ferramentas C++ para expansão usando o recurso "include_paths" do CROSSTOOL. Uma cadeia de ferramentas executada em um sistema POSIX com definições de recursos típicas produzirá -isystem path_to_package/include_entry. Isso só deve ser usado para bibliotecas de terceiros que não estão em conformidade com o estilo do Google de escrever instruções #include. Ao contrário do COPTS, essas flags são adicionadas a essa regra e a todas as regras que dependem dela. Observação: não as regras de que ele depende. Tome muito cuidado, porque isso pode ter efeitos abrangentes. Em caso de dúvida, adicione flags "-I" a COPTS. O caminho include padrão não inclui arquivos gerados. Se você precisar #include um arquivo de cabeçalho gerado, liste-o no srcs.
interface_library	Rótulo; o padrão é None Uma única biblioteca de interface para vincular a biblioteca compartilhada. Tipos de arquivos permitidos: .ifso, .tbd, .lib, .so ou .dylib
linkopts	Lista de strings. O padrão é []. Adicione essas flags ao comando do vinculador C++. Sujeito à substituição da variável"Make", tokenização do shell Bourne e expansão de rótulos. Cada string nesse atributo é adicionada a LINKOPTS antes de vincular o destino binário. Cada elemento dessa lista que não começa com $ ou - é considerado o rótulo de um destino em deps. A lista de arquivos gerados por essa meta é anexada às opções do vinculador. Um erro será informado se o rótulo for inválido ou não for declarado em deps.
objects	Lista de rótulos. O padrão é [].
pic_objects	Lista de rótulos. O padrão é [].
pic_static_library	Rótulo; o padrão é None
shared_library	Rótulo; o padrão é None Uma única biblioteca compartilhada pré-compilada. O Bazel garante que ele esteja disponível para o binário que depende dele durante a execução. Tipos de arquivo permitidos: .so, .dll ou .dylib
static_library	Rótulo; o padrão é None Uma única biblioteca estática pré-compilada. Tipos de arquivo permitidos: .a, .pic.a ou .lib
strip_include_prefix	String; o padrão é "" O prefixo a ser removido dos caminhos dos cabeçalhos desta regra. Quando definido, os cabeçalhos no atributo hdrs dessa regra ficam acessíveis no caminho deles com esse prefixo cortado. Se for um caminho relativo, ele será considerado relativo ao pacote. Se for absoluto, ele será entendido como um caminho relativo ao repositório. O prefixo no atributo include_prefix é adicionado depois que o prefixo é removido. Esse atributo só é permitido em third_party.
system_provided	Booleano; o padrão é False Se for 1, isso indica que a biblioteca compartilhada necessária no tempo de execução é fornecida pelo sistema. Nesse caso, interface_library precisa ser especificado e shared_library precisa estar vazio.

cc_library

Ver origem da regra

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

Use cc_library() para bibliotecas compiladas em C++. O resultado é um .so, .lo ou .a, dependendo do que for necessário.

Se você criar algo com vinculação estática que dependa de um cc_library, a saída de uma regra de biblioteca dependente será o arquivo .a. Se você especificar alwayslink=True, vai receber o arquivo .lo.

O nome real do arquivo de saída é libfoo.so para a biblioteca compartilhada, em que foo é o nome da regra. Os outros tipos de bibliotecas terminam com .lo e .a, respectivamente. Se você precisar de um nome de biblioteca compartilhada específico, por exemplo, para definir um módulo Python, use uma genrule para copiar a biblioteca com o nome desejado.

Verificação da inclusão de cabeçalho

Todos os arquivos de cabeçalho usados no build precisam ser declarados no hdrs ou srcs das regras cc_*. Isso é aplicado.

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 um cabeçalho vai para hdrs ou srcs, pergunte se você quer que os consumidores dessa biblioteca possam incluí-la diretamente. Essa é aproximadamente a mesma decisão que entre a visibilidade public e private em linguagens de programação.

As regras cc_binary e cc_test não têm uma interface exportada e, portanto, também não têm um atributo hdrs. Todos os cabeçalhos que pertencem diretamente ao binário ou ao teste precisam ser listados no 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, pode incluir baz-impl.h. Tecnicamente, a compilação de um arquivo .cc pode incluir transitivamente qualquer arquivo de cabeçalho em hdrs ou srcs em qualquer cc_library no fechamento transitivo de 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 ao deps de foo.

O Bazel depende do suporte do conjunto de ferramentas para aplicar as regras de verificação de inclusão. O recurso layering_check precisa ser compatível com a cadeia de ferramentas e solicitado explicitamente, por exemplo, usando a flag de linha de comando --features=layering_check ou o parâmetro features da função package. As toolchains fornecidas pelo Bazel só oferecem suporte a esse recurso com clang no Unix e no macOS.

Exemplos

Usamos a flag alwayslink para forçar o vinculador a vincular esse código, mesmo que o código binário principal não o referencie.

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 = True,
)

O exemplo a seguir vem de third_party/python2_4_3/BUILD. Parte do código usa a biblioteca dl (para carregar outra biblioteca dinâmica), então essa regra especifica a opção de vinculação -ldl para vincular a biblioteca dl.

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

O exemplo a seguir vem de third_party/kde/BUILD. Mantemos arquivos .so pré-criados no depósito. Os arquivos de cabeçalho ficam em um subdiretório chamado 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"],
)

O exemplo a seguir vem de third_party/gles/BUILD. O código de terceiros geralmente precisa de um pouco de defines e 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	Nome: obrigatório Um nome exclusivo para essa segmentação.
deps	Lista de rótulos. O padrão é []. A lista de outras bibliotecas de que o destino da biblioteca depende. Podem ser destinos cc_library ou objc_library. Consulte comentários gerais sobre deps em Atributos típicos definidos pela maioria das regras de build. Eles precisam ser nomes de regras de biblioteca C++. Ao criar um binário que vincula a biblioteca dessa regra, você também vincula as bibliotecas em deps. Apesar do nome "deps", nem todos os clientes dessa biblioteca pertencem a este lugar. As dependências de dados de tempo de execução pertencem a data. Os arquivos de origem gerados por outras regras pertencem a srcs. Para vincular uma biblioteca de terceiros pré-compilada, adicione o nome dela ao srcs. Para depender de algo sem vincular a esta biblioteca, adicione o nome ao data.
srcs	Lista de rótulos. O padrão é []. A lista de arquivos C e C++ que são processados para criar o destino da biblioteca. São arquivos de origem e de cabeçalho C/C++, não gerados (código-fonte normal) ou gerados. Todos os arquivos .cc, .c e .cpp serão compilados. Podem ser arquivos gerados: se um arquivo nomeado estiver no outs de alguma outra regra, esse cc_library dependerá automaticamente dessa outra regra. Arquivos de assembler puro (.s, .asm) não são pré-processados e geralmente são criados usando o assembler. Os arquivos de assembly pré-processados (.S) são pré-processados e geralmente criados usando o compilador C/C++. Um arquivo .h não será compilado, mas estará disponível para inclusão por fontes nessa regra. Os arquivos .cc e .h podem incluir diretamente os cabeçalhos listados nesses srcs ou no hdrs desta regra ou de qualquer regra listada no argumento deps. Todos os arquivos #included precisam ser mencionados no atributo hdrs desta ou de regras cc_library referenciadas. Caso contrário, eles precisam ser listados em srcs se forem particulares a esta biblioteca. Consulte "Verificação de inclusão de cabeçalho" para uma descrição mais detalhada. Os arquivos .so, .lo e .a são pré-compilados. Sua biblioteca pode ter esses elementos como srcs se usar código de terceiros para o qual não temos código-fonte. Se o atributo srcs incluir o rótulo de outra regra, o cc_library usará os arquivos de saída dessa regra como arquivos de origem para compilação. Isso é útil para geração única de código-fonte. Para uso mais frequente, é melhor implementar uma classe de regra do Starlark e usar a API cc_common. Tipos de arquivos srcs permitidos: Arquivos de origem C e C++: .c, .cc, .cpp, .cxx, .c++, .C Arquivos de cabeçalho C e C++: .h, .hh, .hpp, .hxx, .inc, .inl, .H Assembler com pré-processador C: .S Arquivo: .a, .pic.a Biblioteca "Sempre vincular": .lo, .pic.lo Biblioteca compartilhada, com ou sem versão: .so, .so.version Arquivo de objeto: .o, .pic.o ... e todas as regras que produzem esses arquivos (por exemplo, cc_embed_data). Diferentes extensões indicam diferentes linguagens de programação de acordo com a convenção do gcc.
data	Lista de rótulos. O padrão é []. A lista de arquivos necessários para essa biblioteca no tempo de execução. Consulte comentários gerais sobre data em Atributos típicos definidos pela maioria das regras de build. Se um data for o nome de um arquivo gerado, essa regra cc_library dependerá automaticamente da regra de geração. Se um data for um nome de regra, essa regra cc_library vai depender automaticamente dessa regra, e os outs dela serão adicionados automaticamente aos arquivos de dados de cc_library. Seu código C++ pode acessar esses arquivos de dados da seguinte maneira: const std::string path = devtools_build::GetDataDependencyFilepath( "my/test/data/file");
hdrs	Lista de rótulos. O padrão é []. A lista de arquivos de cabeçalho publicados por esta biblioteca para serem incluídos diretamente por fontes em regras dependentes. Esse é o local preferido para declarar arquivos de cabeçalho que descrevem a interface da biblioteca. Esses cabeçalhos serão disponibilizados para inclusão por fontes nesta regra ou em regras dependentes. Os cabeçalhos que não devem ser incluídos por um cliente dessa biblioteca precisam ser listados no atributo srcs, mesmo que sejam incluídos por um cabeçalho publicado. Consulte "Verificação da inclusão de cabeçalho" para uma descrição mais detalhada. Tipos de arquivos headers permitidos: .h, .hh, .hpp, .hxx.
additional_compiler_inputs	Lista de rótulos. O padrão é []. Qualquer arquivo adicional que você queira transmitir para a linha de comando do compilador, como listas de ignorados do sanitizador, por exemplo. Os arquivos especificados aqui podem ser usados em copts com a função $(location).
additional_linker_inputs	Lista de rótulos. O padrão é []. Dependências que são disponibilizadas apenas para o comando do vinculador C++. Ao contrário de deps, que é conceitualmente feito para compilação e vinculação de dependências, additional_linker_inputs é feito especificamente apenas para o último e sinaliza uma dependência necessária apenas para vinculação (por exemplo, arquivos referenciados em linkopts). Por exemplo, arquivos .res do Windows compilados podem ser fornecidos aqui para serem incorporados ao destino binário.
alwayslink	Booleano; o padrão é False Se for 1, qualquer binário que dependa (direta ou indiretamente) dessa biblioteca C++ vai vincular todos os arquivos de objeto dos arquivos listados em srcs, mesmo que alguns não contenham símbolos referenciados pelo binário. Isso é útil se o código não for chamado explicitamente pelo código no binário, por exemplo, se o código se registrar para receber algum callback fornecido por algum serviço. Se o alwayslink não funcionar com o VS 2017 no Windows, isso é devido a um problema conhecido. Faça upgrade do VS 2017 para a versão mais recente.
conlyopts	Lista de strings. O padrão é []. Adicione essas opções ao comando de compilação em C. Sujeito à substituição de "Criar variável" e à tokenização do shell Bourne.
copts	Lista de strings. O padrão é []. Adicione essas opções ao comando de compilação C/C++. Sujeito à substituição de "Criar variável" e à tokenização do shell Bourne. Cada string nesse atributo é adicionada na ordem especificada a COPTS antes de compilar o destino binário. As flags entram em vigor apenas para a compilação dessa meta, não das dependências dela. Portanto, tenha cuidado com os arquivos de cabeçalho incluídos em outro lugar. Todos os caminhos precisam estar relacionados ao espaço de trabalho, não ao pacote atual. Esse atributo não deve ser necessário fora de third_party. Se o pacote declarar o recurso no_copts_tokenization, a tokenização do shell Bourne será aplicada apenas a strings que consistem em uma única variável "Make".
cxxopts	Lista de strings. O padrão é []. Adicione essas opções ao comando de compilação do C++. Sujeito à substituição de "Criar variável" e à tokenização do shell Bourne.
defines	Lista de strings. O padrão é []. Lista de definições a serem adicionadas à linha de compilação deste e de todos os destinos dependentes. Sujeito à substituição da variável"Make" e à tokenização do shell Bourne. Cada string, que precisa consistir em um único token do shell Bourne, é precedida por -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. As definições são adicionadas a todos os destinos que dependem desse destino. Em caso de dúvida, adicione valores de definição a local_defines.
hdrs_check	String; o padrão é "" Descontinuado, sem operação.
implementation_deps	Lista de rótulos. O padrão é []. A lista de outras bibliotecas de que o destino da biblioteca depende. Ao contrário do deps, os cabeçalhos e caminhos de inclusão dessas bibliotecas (e todas as dependências transitivas delas) são usados apenas para a compilação dessa biblioteca, e não das bibliotecas que dependem dela. As bibliotecas especificadas com implementation_deps ainda são vinculadas em destinos binários que dependem dessa biblioteca.
include_prefix	String; o padrão é "" O prefixo a ser adicionado aos caminhos dos cabeçalhos desta regra. Quando definido, os cabeçalhos no atributo hdrs dessa regra ficam acessíveis no valor desse atributo adicionado ao caminho relativo ao repositório. O prefixo no atributo strip_include_prefix é removido antes de ser adicionado. Esse atributo só é permitido em third_party.
includes	Lista de strings. O padrão é []. Lista de diretórios de inclusão a serem adicionados à linha de compilação. Sujeito à substituição "Criar variável". Cada string é precedida pelo caminho do pacote e transmitida à cadeia de ferramentas C++ para expansão usando o recurso "include_paths" do CROSSTOOL. Uma cadeia de ferramentas executada em um sistema POSIX com definições de recursos típicas produzirá -isystem path_to_package/include_entry. Isso só deve ser usado para bibliotecas de terceiros que não estão em conformidade com o estilo do Google de escrever instruções #include. Ao contrário do COPTS, essas flags são adicionadas a essa regra e a todas as regras que dependem dela. Observação: não as regras de que ele depende. Tome muito cuidado, porque isso pode ter efeitos abrangentes. Em caso de dúvida, adicione flags "-I" a COPTS. Os caminhos include adicionados vão incluir arquivos gerados e arquivos na árvore de origem.
linkopts	Lista de strings. O padrão é []. Veja cc_binary.linkopts. O atributo linkopts também é aplicado a qualquer destino que dependa, direta ou indiretamente, dessa biblioteca usando atributos deps ou outros atributos tratados de maneira semelhante: o atributo malloc de cc_binary. As opções de vinculação de dependência têm precedência sobre as opções de vinculação dependentes (ou seja, as opções de vinculação de dependência aparecem mais tarde na linha de comando). As linkopts especificadas em --linkopt têm precedência sobre as linkopts de regra. O atributo linkopts só se aplica à criação de arquivos ou executáveis .so, não de arquivos .a ou .lo. Portanto, se o atributo linkstatic=True estiver definido, o atributo linkopts não terá efeito na criação dessa biblioteca, apenas em outros destinos que dependem dela. Além disso, é importante observar que as opções "-Wl,-soname" ou "-Xlinker -soname" não são compatíveis e nunca devem ser especificadas nesse atributo. Os arquivos .so produzidos pelas regras cc_library não são vinculados às bibliotecas de que dependem. Se você estiver tentando criar uma biblioteca compartilhada para uso fora do repositório principal, por exemplo, para uso manual com dlopen() ou LD_PRELOAD, talvez seja melhor usar uma regra cc_binary com o atributo linkshared=True. Confira cc_binary.linkshared.
linkstamp	Rótulo; o padrão é None Compila e vincula simultaneamente o arquivo de origem C++ especificado ao binário final. Essa manipulação é necessária para introduzir informações de carimbo de data/hora em binários. Se compilássemos o arquivo de origem para um arquivo de objeto da maneira usual, o carimbo de data/hora estaria incorreto. Uma compilação de linkstamp não pode incluir um conjunto específico de flags do compilador e, portanto, não deve depender de um cabeçalho, opção do compilador ou outra variável de build específica. Essa opção só é necessária no pacote base.
linkstatic	Booleano; o padrão é False Para cc_binary e cc_test: vincule o binário no modo estático. Para cc_library.link_static: consulte abaixo. Por padrão, essa opção fica ativada para cc_binary e desativada para o restante. Se ativada e se for um binário ou teste, essa opção vai instruir a ferramenta de build a vincular .as em vez de .sos para bibliotecas de usuários sempre que possível. Bibliotecas do sistema, como libc (mas não as bibliotecas de tempo de execução C/C++, consulte abaixo), ainda são vinculadas dinamicamente, assim como bibliotecas para as quais não há uma biblioteca estática. Assim, o executável resultante ainda será vinculado de forma dinâmica, sendo, portanto, apenas principalmente estático. Há três maneiras diferentes de vincular um executável: STATIC com o recurso fully_static_link, em que tudo é vinculado de forma estática.Por exemplo, "gcc -static foo.o libbar.a libbaz.a -lm". . Esse modo é ativado especificando fully_static_link no atributo features. STATIC, em que todas as bibliotecas do usuário são vinculadas de forma estática (se uma versão estática estiver disponível), mas em que as bibliotecas do sistema (exceto as bibliotecas de tempo de execução C/C++) são vinculadas dinamicamente, por exemplo, "gcc foo.o libfoo.a libbaz.a -lm". Esse modo é ativado especificando linkstatic=True. DYNAMIC, em que todas as bibliotecas são vinculadas dinamicamente (se uma versão dinâmica estiver disponível), por exemplo, "gcc foo.o libfoo.so libbaz.so -lm". Esse modo é ativado especificando linkstatic=False. Se o atributo linkstatic ou fully_static_link em features for usado fora de //third_party, inclua um comentário perto da regra para explicar o motivo. O atributo linkstatic tem um significado diferente se usado em uma regra de cc_library(). Para uma biblioteca C++, linkstatic=True indica que apenas a vinculação estática é permitida, portanto, nenhum .so será produzido. linkstatic=False não impede a criação de bibliotecas estáticas. O atributo controla a criação de bibliotecas dinâmicas. É preciso haver muito pouco código criado com linkstatic=False em produção. Se linkstatic=False, a ferramenta de build vai criar symlinks para bibliotecas compartilhadas dependentes na área *.runfiles.
local_defines	Lista de strings. O padrão é []. Lista de definições a serem adicionadas à linha de compilação. Sujeito à substituição da variável"Make" e à tokenização do shell Bourne. Cada string, que precisa consistir em um único token do shell Bourne, é precedida por -D e adicionada à linha de comando de compilação para essa meta, mas não para os dependentes dela. Ao contrário de defines, as definições só são adicionadas à linha de comando de compilação para essa meta.
module_interfaces	Lista de rótulos. O padrão é []. A lista de arquivos é considerada uma interface de módulos C++20. O padrão C++ não tem restrição sobre a extensão do arquivo de interface do módulo. Clang usa cppm O GCC pode usar qualquer extensão de arquivo de origem MSVC usa ixx O uso é protegido pela flag --experimental_cpp_modules.
strip_include_prefix	String; o padrão é "" O prefixo a ser removido dos caminhos dos cabeçalhos desta regra. Quando definido, os cabeçalhos no atributo hdrs dessa regra ficam acessíveis no caminho deles com esse prefixo cortado. Se for um caminho relativo, ele será considerado relativo ao pacote. Se for absoluto, ele será entendido como um caminho relativo ao repositório. O prefixo no atributo include_prefix é adicionado depois que o prefixo é removido. Esse atributo só é permitido em third_party.
textual_hdrs	Lista de rótulos. O padrão é []. A lista de arquivos de cabeçalho publicados por esta biblioteca para serem incluídos textualmente por fontes em regras dependentes. 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 é None O arquivo DEF do Windows a ser transmitido para o vinculador. Esse atributo só deve ser usado quando o Windows é a plataforma de destino. Ele pode ser usado para exportar símbolos durante a vinculação de uma biblioteca compartilhada.

cc_shared_library

Ver origem da regra

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

Ela 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 este último uma dependência transitiva. Ele não vincula bar porque já é fornecido dinamicamente pelo dynamic_dep bar_shared.

O foo_shared usa um arquivo de script do vinculador *.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 usa apenas o que se supõe ser exportado para gerar erros durante a fase de análise se duas bibliotecas compartilhadas exportarem os mesmos destinos.

Todas as dependências diretas de cc_shared_library são consideradas exportadas. Portanto, durante a análise, o Bazel pressupõe que foo está sendo exportado por foo_shared. Não se presume que baz seja exportado por foo_shared. Todos os destinos correspondentes ao exports_filter também são considerados exportados.

Cada cc_library no exemplo precisa aparecer no máximo em um cc_shared_library. Se quisermos vincular baz também a bar_shared, precisaremos 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 teria por padrão no Linux.

Erros

Two shared libraries in dependencies export the same symbols.

Isso acontece sempre que você cria um destino com duas dependências cc_shared_library diferentes que exportam o mesmo destino. Para corrigir isso, impeça que as bibliotecas sejam exportadas em uma das dependências do 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 com 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 o vincula precisa exportar a biblioteca para que o que não 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 culpado com LINKABLE_MORE_THAN_ONCE, mas essa correção deve ser rara. Além disso, é preciso ter certeza de que o cc_library é seguro para 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 do seu deps pode ser acessada sem passar por uma das dependências cc_shared_library, mas já está vinculada a um cc_shared_library diferente em dynamic_deps e não é exportada.

A solução é exportar da dependência cc_shared_library ou extrair um terceiro cc_shared_library que a exporte.

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 precisará e não poderá 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 dela diretamente.

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

Esse erro aparece se você estiver reivindicando exportar um destino que já está sendo exportado por uma das suas dependências dinâmicas na regra atual.

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 é []. Bibliotecas de nível superior que serão vinculadas estaticamente à biblioteca compartilhada incondicionalmente depois de serem totalmente arquivadas. Qualquer dependência transitiva de biblioteca dessas dependências diretas será vinculada a essa biblioteca compartilhada, desde que ainda não tenha sido vinculada por um cc_shared_library em dynamic_deps. Durante a análise, a implementação da regra considera qualquer destino listado em deps como exportado pela biblioteca compartilhada para gerar erros quando vários cc_shared_libraries exportam os mesmos destinos. A implementação da regra não informa ao vinculador quais símbolos precisam ser exportados pelo objeto compartilhado. O usuário precisa cuidar disso usando scripts de vinculador ou declarações de visibilidade no código-fonte. A implementação também vai gerar erros sempre que a mesma biblioteca for vinculada estaticamente a mais de um cc_shared_library. Isso pode ser evitado adicionando "LINKABLE_MORE_THAN_ONCE" ao cc_library.tags ou listando a "cc_library" como uma exportação de uma das bibliotecas compartilhadas para que uma possa ser um dynamic_dep da outra.
additional_linker_inputs	Lista de rótulos. O padrão é []. Outros arquivos que você queira transmitir ao vinculador, por exemplo, scripts do vinculador. Você precisa transmitir separadamente todas as flags de vinculador necessárias para que ele reconheça esse arquivo. É possível fazer isso usando o atributo user_link_flags.
dynamic_deps	Lista de rótulos. O padrão é []. Essas são outras dependências de cc_shared_library de que o destino atual depende. A implementação cc_shared_library vai usar a lista de dynamic_deps (transitivamente, ou seja, também o dynamic_deps do dynamic_deps do destino atual) para decidir quais cc_libraries no deps transitivo não devem ser vinculados porque já são fornecidos por um cc_shared_library diferente.
exports_filter	Lista de strings. O padrão é []. Esse atributo contém uma lista de destinos que supostamente são exportados pela biblioteca compartilhada atual. Qualquer destino deps já é entendido como exportado pela biblioteca compartilhada. Esse atributo deve ser usado para listar todos os destinos exportados pela biblioteca compartilhada, mas que são dependências transitivas de deps. Observe que esse atributo não adiciona uma aresta de dependência a essas metas. Em vez disso, a aresta de dependência deve ser criada por deps. As entradas nesse atributo são apenas strings. Ao colocar um destino nesse atributo, isso é considerado uma declaração de que a biblioteca compartilhada exporta os símbolos desse destino. A lógica cc_shared_library não processa a instrução do vinculador sobre quais símbolos devem ser exportados. A seguinte sintaxe é permitida: //foo:__pkg__ para considerar qualquer destino em foo/BUILD //foo:__subpackages__ para considerar qualquer destino em foo/BUILD ou qualquer outro pacote abaixo de foo/, como foo/bar/BUILD
roots	Lista de rótulos. O padrão é [].
shared_lib_name	String; o padrão é "" Por padrão, o cc_shared_library usa um nome para o arquivo de saída da biblioteca compartilhada com base no nome do destino e na plataforma. Isso inclui uma extensão e, às vezes, um prefixo. Às vezes, você não quer o nome padrão. Por exemplo, ao carregar bibliotecas compartilhadas em C++ para Python, o prefixo padrão lib* geralmente não é desejado. Nesse caso, use esse atributo para escolher um nome personalizado.
static_deps	Lista de strings. O padrão é [].
user_link_flags	Lista de strings. O padrão é []. Outras flags que você queira transmitir ao vinculador. Por exemplo, para que o vinculador reconheça um script transmitido por additional_linker_inputs, use o seguinte: 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 é None O arquivo DEF do Windows a ser transmitido para o vinculador. Esse atributo só deve ser usado quando o Windows é a plataforma de destino. Ele pode ser usado para exportar símbolos durante a vinculação de uma biblioteca compartilhada.

cc_static_library

Ver origem da regra

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

Produz uma biblioteca estática de uma lista de destinos e 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 a objetos PIC.

Grupos de saída

linkdeps

Um arquivo de texto que contém os rótulos das dependências transitivas dos destinos listados em deps que não contribuíram com arquivos de objeto para a biblioteca estática, mas fornecem 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 que contém o linkopts fornecido pelo usuário de todas as dependências transitivas dos 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 por pacote definindo features = ["-symbol_check"] ou globalmente via --features=-symbol_check.

Suporte a cadeia de ferramentas para symbol_check

As toolchains C++ autoconfiguradas enviadas com o Bazel são compatíveis com o recurso symbol_check em todas as plataformas. As toolchains personalizadas podem adicionar suporte para isso de duas maneiras:

• Implementar a ação ACTION_NAMES.validate_static_library e ativá-la com o recurso symbol_check. O conjunto de ferramentas na ação é invocado com dois argumentos: a biblioteca estática para verificar 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 arquivamento 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 é []. A lista de destinos a serem combinados em uma biblioteca estática, incluindo todas as dependências transitivas. As dependências que não fornecem arquivos de objeto não são incluídas na biblioteca estática, mas os rótulos delas são coletados no arquivo fornecido pelo grupo de saída linkdeps.

cc_test

Ver origem da regra

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

Uma regra cc_test() compila um teste. Aqui, um teste é um wrapper binário em torno de algum código de teste.

Por padrão, os testes em C++ são vinculados dinamicamente.
Para vincular estaticamente um teste de unidade, especifique linkstatic=True. É recomendável comentar por que seu teste precisa de linkstatic, já que isso provavelmente não é óbvio.

Metas de saída implícitas

• name.stripped (criado somente se solicitado explicitamente): uma versão reduzida do binário. O strip -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.
• name.dwp (criado apenas se solicitado explicitamente): se o 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.

Consulte os argumentos cc_binary(), exceto que o argumento stamp é definido como 0 por padrão para testes e que cc_test tem atributos extras comuns a todas as regras de teste (*_test).

Argumentos

Atributos
name	Nome: obrigatório Um nome exclusivo para essa segmentação.
deps	Lista de rótulos. O padrão é []. A lista de outras bibliotecas a serem vinculadas ao destino binário. Podem ser destinos cc_library ou objc_library. Também é permitido colocar scripts do vinculador (.lds) em deps e referenciá-los em linkopts, mas considere additional_linker_inputs para esse caso de uso.
srcs	Lista de rótulos. O padrão é []. A lista de arquivos C e C++ que são processados para criar o destino da biblioteca. São arquivos de origem e de cabeçalho C/C++, não gerados (código-fonte normal) ou gerados. Todos os arquivos .cc, .c e .cpp serão compilados. Podem ser arquivos gerados: se um arquivo nomeado estiver no outs de alguma outra regra, esse cc_library dependerá automaticamente dessa outra regra. Arquivos de assembler puro (.s, .asm) não são pré-processados e geralmente são criados usando o assembler. Os arquivos de assembly pré-processados (.S) são pré-processados e geralmente criados usando o compilador C/C++. Um arquivo .h não será compilado, mas estará disponível para inclusão por fontes nessa regra. Os arquivos .cc e .h podem incluir diretamente os cabeçalhos listados nesses srcs ou no hdrs desta regra ou de qualquer regra listada no argumento deps. Todos os arquivos #included precisam ser mencionados no atributo hdrs desta ou de regras cc_library referenciadas. Caso contrário, eles precisam ser listados em srcs se forem particulares a esta biblioteca. Consulte "Verificação de inclusão de cabeçalho" para uma descrição mais detalhada. Os arquivos .so, .lo e .a são pré-compilados. Sua biblioteca pode ter esses elementos como srcs se usar código de terceiros para o qual não temos código-fonte. Se o atributo srcs incluir o rótulo de outra regra, o cc_library usará os arquivos de saída dessa regra como arquivos de origem para compilação. Isso é útil para geração única de código-fonte. Para uso mais frequente, é melhor implementar uma classe de regra do Starlark e usar a API cc_common. Tipos de arquivos srcs permitidos: Arquivos de origem C e C++: .c, .cc, .cpp, .cxx, .c++, .C Arquivos de cabeçalho C e C++: .h, .hh, .hpp, .hxx, .inc, .inl, .H Assembler com pré-processador C: .S Arquivo: .a, .pic.a Biblioteca "Sempre vincular": .lo, .pic.lo Biblioteca compartilhada, com ou sem versão: .so, .so.version Arquivo de objeto: .o, .pic.o ... e todas as regras que produzem esses arquivos (por exemplo, cc_embed_data). Diferentes extensões indicam diferentes linguagens de programação de acordo com a convenção do gcc.
data	Lista de rótulos. O padrão é []. A lista de arquivos necessários para essa biblioteca no tempo de execução. Consulte comentários gerais sobre data em Atributos típicos definidos pela maioria das regras de build. Se um data for o nome de um arquivo gerado, essa regra cc_library dependerá automaticamente da regra de geração. Se um data for um nome de regra, essa regra cc_library vai depender automaticamente dessa regra, e os outs dela serão adicionados automaticamente aos arquivos de dados de cc_library. Seu código C++ pode acessar esses arquivos de dados da seguinte maneira: const std::string path = devtools_build::GetDataDependencyFilepath( "my/test/data/file");
additional_linker_inputs	Lista de rótulos. O padrão é []. Dependências que são disponibilizadas apenas para o comando do vinculador C++. Ao contrário de deps, que é conceitualmente feito para compilação e vinculação de dependências, additional_linker_inputs é feito especificamente apenas para o último e sinaliza uma dependência necessária apenas para vinculação (por exemplo, arquivos referenciados em linkopts). Por exemplo, arquivos .res do Windows compilados podem ser fornecidos aqui para serem incorporados ao destino binário.
conlyopts	Lista de strings. O padrão é []. Adicione essas opções ao comando de compilação em C. Sujeito à substituição de "Criar variável" e à tokenização do shell Bourne.
copts	Lista de strings. O padrão é []. Adicione essas opções ao comando de compilação C/C++. Sujeito à substituição de "Criar variável" e à tokenização do shell Bourne. Cada string nesse atributo é adicionada na ordem especificada a COPTS antes de compilar o destino binário. As flags entram em vigor apenas para a compilação dessa meta, não das dependências dela. Portanto, tenha cuidado com os arquivos de cabeçalho incluídos em outro lugar. Todos os caminhos precisam estar relacionados ao espaço de trabalho, não ao pacote atual. Esse atributo não deve ser necessário fora de third_party. Se o pacote declarar o recurso no_copts_tokenization, a tokenização do shell Bourne será aplicada apenas a strings que consistem em uma única variável "Make".
cxxopts	Lista de strings. O padrão é []. Adicione essas opções ao comando de compilação do C++. Sujeito à substituição de "Criar variável" e à tokenização do shell Bourne.
defines	Lista de strings. O padrão é []. Lista de definições a serem adicionadas à linha de compilação deste e de todos os destinos dependentes. Sujeito à substituição da variável"Make" e à tokenização do shell Bourne. Cada string, que precisa consistir em um único token do shell Bourne, é precedida por -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. As definições são adicionadas a todos os destinos que dependem desse destino. Em caso de dúvida, adicione valores de definição a local_defines.
dynamic_deps	Lista de rótulos. O padrão é []. Essas são outras dependências de cc_shared_library de que o destino atual depende. A implementação cc_shared_library vai usar a lista de dynamic_deps (transitivamente, ou seja, também o dynamic_deps do dynamic_deps do destino atual) para decidir quais cc_libraries no deps transitivo não devem ser vinculados porque já são fornecidos por um cc_shared_library diferente.
hdrs_check	String; o padrão é "" Descontinuado, sem operação.
includes	Lista de strings. O padrão é []. Lista de diretórios de inclusão a serem adicionados à linha de compilação. Sujeito à substituição "Criar variável". Cada string é precedida pelo caminho do pacote e transmitida à cadeia de ferramentas C++ para expansão usando o recurso "include_paths" do CROSSTOOL. Uma cadeia de ferramentas executada em um sistema POSIX com definições de recursos típicas produzirá -isystem path_to_package/include_entry. Isso só deve ser usado para bibliotecas de terceiros que não estão em conformidade com o estilo do Google de escrever instruções #include. Ao contrário do COPTS, essas flags são adicionadas a essa regra e a todas as regras que dependem dela. Observação: não as regras de que ele depende. Tome muito cuidado, porque isso pode ter efeitos abrangentes. Em caso de dúvida, adicione flags "-I" a COPTS. Os caminhos include adicionados vão incluir arquivos gerados e arquivos na árvore de origem.
link_extra_lib	Rótulo; o padrão é "@bazel_tools//tools/cpp:link_extra_lib" Controla a vinculação de bibliotecas extras. Por padrão, os binários C++ são vinculados a //tools/cpp:link_extra_lib, que depende da flag de rótulo //tools/cpp:link_extra_libs. Sem definir a flag, essa biblioteca fica vazia por padrão. Definir a flag de rótulo permite vincular dependências opcionais, como substituições para símbolos fracos, interceptadores para funções de biblioteca compartilhada ou bibliotecas de tempo de execução especiais (para substituições de malloc, prefira malloc ou --custom_malloc). Definir esse atributo como None desativa esse comportamento.
linkopts	Lista de strings. O padrão é []. Adicione essas flags ao comando do vinculador C++. Sujeito à substituição da variável"Make", tokenização do shell Bourne e expansão de rótulos. Cada string nesse atributo é adicionada a LINKOPTS antes de vincular o destino binário. Cada elemento dessa lista que não começa com $ ou - é considerado o rótulo de um destino em deps. A lista de arquivos gerados por essa meta é anexada às opções do vinculador. Um erro é informado se o rótulo for inválido ou não for declarado em deps.
linkshared	Booleano; o padrão é False Crie uma biblioteca compartilhada. Para ativar esse atributo, inclua linkshared=True na sua regra. Por padrão, essa opção fica desativada. A presença dessa flag significa que a vinculação ocorre com a flag -shared para gcc, e a biblioteca compartilhada resultante é adequada para carregamento em, por exemplo, um programa Java. No entanto, para fins de build, ela nunca será vinculada ao binário dependente, já que se presume que as bibliotecas compartilhadas criadas com uma regra cc_binary só são carregadas manualmente por outros programas. Portanto, ela não deve ser considerada um substituto para a regra cc_library. Para fins de escalonabilidade, recomendamos evitar essa abordagem e simplesmente deixar java_library depender das regras de cc_library. Se você especificar linkopts=['-static'] e linkshared=True, vai receber uma única unidade completamente independente. Se você especificar linkstatic=True e linkshared=True, vai receber uma unidade única e quase independente.
linkstatic	Booleano; o padrão é False Para cc_binary e cc_test: vincule o binário no modo estático. Para cc_library.link_static: consulte abaixo. Por padrão, essa opção fica ativada para cc_binary e desativada para o restante. Se ativada e se for um binário ou teste, essa opção vai instruir a ferramenta de build a vincular .as em vez de .sos para bibliotecas de usuários sempre que possível. Bibliotecas do sistema, como libc (mas não as bibliotecas de tempo de execução C/C++, consulte abaixo), ainda são vinculadas dinamicamente, assim como bibliotecas para as quais não há uma biblioteca estática. Assim, o executável resultante ainda será vinculado de forma dinâmica, sendo, portanto, apenas principalmente estático. Há três maneiras diferentes de vincular um executável: STATIC com o recurso fully_static_link, em que tudo é vinculado de forma estática.Por exemplo, "gcc -static foo.o libbar.a libbaz.a -lm". . Esse modo é ativado especificando fully_static_link no atributo features. STATIC, em que todas as bibliotecas do usuário são vinculadas de forma estática (se uma versão estática estiver disponível), mas em que as bibliotecas do sistema (exceto as bibliotecas de tempo de execução C/C++) são vinculadas dinamicamente, por exemplo, "gcc foo.o libfoo.a libbaz.a -lm". Esse modo é ativado especificando linkstatic=True. DYNAMIC, em que todas as bibliotecas são vinculadas dinamicamente (se uma versão dinâmica estiver disponível), por exemplo, "gcc foo.o libfoo.so libbaz.so -lm". Esse modo é ativado especificando linkstatic=False. Se o atributo linkstatic ou fully_static_link em features for usado fora de //third_party, inclua um comentário perto da regra para explicar o motivo. O atributo linkstatic tem um significado diferente se usado em uma regra de cc_library(). Para uma biblioteca C++, linkstatic=True indica que apenas a vinculação estática é permitida, portanto, nenhum .so será produzido. linkstatic=False não impede a criação de bibliotecas estáticas. O atributo controla a criação de bibliotecas dinâmicas. É preciso haver muito pouco código criado com linkstatic=False em produção. Se linkstatic=False, a ferramenta de build vai criar symlinks para bibliotecas compartilhadas dependentes na área *.runfiles.
local_defines	Lista de strings. O padrão é []. Lista de definições a serem adicionadas à linha de compilação. Sujeito à substituição da variável"Make" e à tokenização do shell Bourne. Cada string, que precisa consistir em um único token do shell Bourne, é precedida por -D e adicionada à linha de comando de compilação para essa meta, mas não para os dependentes dela. Ao contrário de defines, as definições só são adicionadas à linha de comando de compilação para essa meta.
malloc	Rótulo; o padrão é "@bazel_tools//tools/cpp:malloc" Substitua a dependência padrão de malloc. Por padrão, os binários C++ são vinculados a //tools/cpp:malloc, uma biblioteca vazia. Assim, o binário acaba usando o malloc da libc. Esse rótulo precisa se referir a um cc_library. Se a compilação for para uma regra que não seja de C++, essa opção não terá efeito. O valor desse atributo é ignorado se linkshared=True for especificado.
module_interfaces	Lista de rótulos. O padrão é []. A lista de arquivos é considerada uma interface de módulos C++20. O padrão C++ não tem restrição sobre a extensão do arquivo de interface do módulo. Clang usa cppm O GCC pode usar qualquer extensão de arquivo de origem MSVC usa ixx O uso é protegido pela flag --experimental_cpp_modules.
nocopts	String; o padrão é "" Remova as opções correspondentes do comando de compilação em C++. Sujeito à substituição da variável "Make". O valor desse atributo é interpretado como uma expressão regular. Qualquer 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 não deve ser necessário nem usado fora de third_party. Os valores não são pré-processados de nenhuma outra forma além da substituição da variável "Make".
reexport_deps	Lista de rótulos. O padrão é [].
stamp	Número inteiro. O padrão é 0. Determina se as informações de build serão codificadas no binário. Valores possíveis: stamp = 1: sempre adicione as informações de build ao binário, mesmo em builds --nostamp. Evite essa configuração, já que ela pode encerrar o armazenamento em cache remoto para o binário e qualquer ação downstream que dependa dele. stamp = 0: sempre substitua as informações de build por valores constantes. Isso oferece um bom cache de resultados de build. stamp = -1: o embedding de informações de build é controlado pela flag --[no]stamp. Os binários carimbados não são recriados, a menos que as dependências mudem.
win_def_file	Rótulo; o padrão é None O arquivo DEF do Windows a ser transmitido para o vinculador. Esse atributo só deve ser usado quando o Windows é a plataforma de destino. Ele pode ser usado para exportar símbolos durante a vinculação de uma biblioteca compartilhada.

cc_toolchain

Ver origem da regra

cc_toolchain(name, all_files, ar_files, as_files, compatible_with, compiler_files, compiler_files_without_includes, coverage_files, deprecation, dwp_files, dynamic_runtime_lib, exec_compatible_with, exec_group_compatible_with, exec_properties, exec_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, output_licenses, package_metadata, 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 um conjunto de ferramentas C++.

Essa regra é responsável por:

• Coletando todos os artefatos necessários para a execução de ações em C++. Isso é feito por atributos como all_files, compiler_files, linker_files ou outros atributos que terminam com _files. Geralmente, esses são filegroups que agrupam todos os arquivos necessários.
• Gerar linhas de comando corretas para ações em C++. Isso é feito usando o provedor CcToolchainConfigInfo (detalhes abaixo).

Use o atributo toolchain_config para configurar a cadeia de ferramentas do C++. Consulte também esta página para ver a documentação detalhada sobre configuração e seleção do conjunto de ferramentas C++.

Use tags = ["manual"] para evitar que as toolchains sejam criadas e configuradas sem necessidade ao invocar bazel build //....

Argumentos

Atributos
name	Nome: obrigatório Um nome exclusivo para essa segmentação.
all_files	Rótulo; obrigatório Coleção de todos os artefatos 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 pressupõe que all_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 de link, então usa all_files. É isso que cc_toolchain.files contém, e é usado por todas as regras do Starlark que usam a cadeia de ferramentas C++.
ar_files	Rótulo; o padrão é None Coleção de todos os artefatos cc_toolchain necessários para ações de arquivamento.
as_files	Rótulo; o padrão é None Coleção de todos os artefatos cc_toolchain necessários para ações de assembly.
compiler_files	Rótulo; obrigatório Coleção de todos os artefatos cc_toolchain necessários para ações de compilação.
compiler_files_without_includes	Rótulo; o padrão é None Coleção de todos os artefatos cc_toolchain necessários para ações de compilação quando a descoberta de entrada é compatível (atualmente apenas no Google).
coverage_files	Rótulo; o padrão é None Coleção de todos os artefatos cc_toolchain necessários para ações de cobertura. Se não for especificado, "all_files" será usado.
dwp_files	Rótulo; obrigatório Coleção de todos os artefatos cc_toolchain necessários para ações de dwp.
dynamic_runtime_lib	Rótulo; o padrão é None Artefato de biblioteca dinâmica para a biblioteca de tempo de execução do C++ (por exemplo, libstdc++.so). Isso será usado quando o recurso "static_link_cpp_runtimes" estiver ativado e estivermos vinculando dependências dinamicamente.
exec_transition_for_inputs	Booleano; o padrão é False Obsoleto. Sem operação.
libc_top	Rótulo; o padrão é None Uma coleção de artefatos para libc transmitidos como entradas para ações de compilação/vinculação.
linker_files	Rótulo; obrigatório Coleção de todos os artefatos cc_toolchain necessários para ações de vinculação.
module_map	Rótulo; o padrão é None Artefato de mapa de módulo a ser usado para builds modulares.
objcopy_files	Rótulo; obrigatório Coleção de todos os artefatos cc_toolchain necessários para ações objcopy.
output_licenses	Lista de strings. O padrão é [].
static_runtime_lib	Rótulo; o padrão é None Artefato de biblioteca estática para a biblioteca de tempo de execução do C++ (por exemplo, libstdc++.a). Isso será usado quando o recurso "static_link_cpp_runtimes" estiver ativado e estivermos vinculando dependências de forma estática.
strip_files	Rótulo; obrigatório Coleção de todos os artefatos cc_toolchain necessários para ações de remoção.
supports_header_parsing	Booleano; o padrão é False Definido como "True" quando cc_toolchain aceita ações de análise de cabeçalho.
supports_param_files	Booleano; o padrão é True Definido como "True" quando cc_toolchain aceita o uso de arquivos de parâmetros para ações de vinculação.
toolchain_config	Rótulo; obrigatório O rótulo da regra que fornece cc_toolchain_config_info.
toolchain_identifier	String; o padrão é "" O identificador usado para corresponder este cc_toolchain ao crosstool_config.toolchain correspondente. Até que o problema #5380 seja corrigido, esta é a maneira recomendada de associar cc_toolchain a CROSSTOOL.toolchain. Ele será substituído pelo atributo toolchain_config (#5380).

cc_toolchain_suite

Ver origem da regra

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

Descontinuada: a regra é uma operação nula e será removida.

Argumentos

Atributos
name	Nome: obrigatório Um nome exclusivo para essa segmentação.

fdo_prefetch_hints

Ver origem da regra

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

Representa um perfil de dicas de pré-busca do FDO que está no espaço de trabalho. Exemplos:

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

Argumentos

Atributos
name	Nome: obrigatório Um nome exclusivo para essa segmentação.
profile	Rótulo; obrigatório Rótulo do perfil de dicas. O arquivo de dicas tem a extensão .afdo. O rótulo também pode apontar para uma regra fdo_absolute_path_profile.

fdo_profile

Ver origem da regra

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

Representa um perfil do FDO que está no espaço de trabalho. Exemplo:

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

Argumentos

Atributos
name	Nome: obrigatório Um nome exclusivo para essa segmentação.
memprof_profile	Rótulo; o padrão é None Rótulo do perfil do MemProf. O perfil precisa ter uma extensão .profdata (para um perfil memprof indexado/simbolizado) ou .zip (para um arquivo zip que contém um arquivo memprof.profdata).
profile	Rótulo; obrigatório Rótulo do perfil de FDO ou uma regra que o gera. O arquivo FDO pode ter uma das seguintes extensões: .profraw para perfil LLVM não indexado, .profdata para perfil LLVM indexado, .zip que contém um perfil LLVM profraw, .afdo para perfil AutoFDO, .xfdo para perfil XBinary. O rótulo também pode apontar para uma regra fdo_absolute_path_profile.
proto_profile	Rótulo; o padrão é None Rótulo do perfil protobuf.

memprof_profile

Ver origem da regra

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

Representa um perfil MEMPROF no espaço de trabalho. Exemplo:

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

Argumentos

Atributos
name	Nome: obrigatório Um nome exclusivo para essa segmentação.
profile	Rótulo; obrigatório Rótulo do perfil MEMPROF. O perfil precisa ter uma extensão .profdata (para um perfil memprof indexado/simbolizado) ou .zip (para um arquivo zip que contém um arquivo memprof.profdata). O rótulo também pode apontar para uma regra fdo_absolute_path_profile.

propeller_optimize

Ver origem da regra

propeller_optimize(name, cc_profile, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, ld_profile, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, 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"
)

Argumentos

Atributos
name	Nome: obrigatório Um nome exclusivo para essa segmentação.
cc_profile	Rótulo; obrigatório Rótulo do perfil transmitido para as várias ações de compilação. Esse arquivo tem a extensão .txt.
ld_profile	Rótulo; obrigatório Rótulo do perfil transmitido para a ação de link. Esse arquivo tem a extensão .txt.