Regras C / C++

Informar um problema Mostrar fonte Por noite · 7,3 · 7,2 · 7,1 · 7,0 · 6,5

Regras

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

cc_binary

Conferir origem da regra

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

Ela produz um binário executável.

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

Destinos de saída implícitos

• name.stripped (criado apenas se solicitado explicitamente): uma versão removida. versão do binário. strip -g é executado no binário para remover a depuração. símbolos. Outras opções de remoção podem ser fornecidas na linha de comando usando --stripopt=-foo:
• name.dwp (criado apenas se solicitado explicitamente): se A fissão está ativada: uma depuração. arquivo de pacote de informações adequado para depurar binários implantados remotamente. Caso contrário: um arquivo vazio.

Argumentos

Atributos
name	Nome; obrigatório Um nome exclusivo para o destino.
deps	Lista de rótulos o padrão é [] A lista de outras bibliotecas a serem vinculadas ao destino binário. Eles podem ser cc_library ou objc_library. de destino. Também é permitido colocar scripts de vinculador (.lds) em dependências e referenciá-los em linkopts.
srcs	Lista de rótulos o padrão é [] A lista de arquivos C e C++ processados para criar o destino da biblioteca. Estes são arquivos de origem e de cabeçalho em C/C++, não gerados (origem normal ou gerados. Todos os arquivos .cc, .c e .cpp serão ser compilado. Podem ser arquivos gerados: se um arquivo nomeado estiver no o outs de alguma outra regra, este cc_library dependerão automaticamente da outra regra. Os arquivos assembler puro (.s, .asm) não são pré-processados e normalmente são criados usando o assembler. Arquivos assembly pré-processados (.S) são pré-processados e normalmente criados usando o compilador C/C++. Um arquivo .h não será compilado, mas estará disponível para inclusão por origens nesta regra. Tanto .cc quanto Os arquivos .h podem incluir diretamente os cabeçalhos listados em srcs ou no hdrs desta regra ou em listada no argumento deps. Todos os arquivos #included precisam ser mencionados no Atributo hdrs disso ou cc_library referenciado regras ou elas vão ser listadas em srcs se forem privadas a esta biblioteca. Consulte "Verificação de inclusão de cabeçalho" para uma descrição mais detalhada. Os arquivos .so, .lo e .a estão arquivos pré-compilados. Sua biblioteca pode ter essas srcs se ela usar código de terceiros para o qual não têm código-fonte. Se o atributo srcs incluir o rótulo de outra regra, O cc_library vai usar os arquivos de saída dessa regra como arquivos de origem para compilar. Isso é útil para a geração única de código-fonte (para casos de uso usar, é melhor implementar uma classe de regra do Starlark e usar o cc_common API) Tipos de arquivo srcs permitidos: Arquivos de origem C e C++: .c, .cc, .cpp. .cxx, .c++ e .C Arquivos de cabeçalho C e C++: .h, .hh, .hpp, .hxx, .inc, .inl, .H Montador com pré-processador C: .S Arquivo: .a, .pic.a "Sempre vincular" biblioteca: .lo, .pic.lo Biblioteca compartilhada, com ou sem controle de versão: .so, .so.version Arquivo de objeto: .o, .pic.o ... e todas as regras que produzem esses arquivos (por exemplo, cc_embed_data). Extensões diferentes indicam linguagens de programação diferentes de acordo com a convenção de GCC.
data	Lista de rótulos o padrão é [] A lista de arquivos necessários para esta biblioteca no tempo de execução. Leia os comentários gerais sobre data em Atributos típicos definidos pelo a maioria das regras de build. Se data for o nome de um arquivo gerado, esse cc_library regra depende automaticamente da regra de firewall. Se um data for o nome de uma regra, esse cc_library regra depende automaticamente dessa regra, e os outs dessa regra são adicionados automaticamente nos arquivos de dados deste cc_library. Seu código C++ pode acessar esses arquivos de dados da seguinte forma: const std::string path = devtools_build::GetDataDependencyFilepath( "my/test/data/file");
additional_linker_inputs	Lista de rótulos o padrão é [] Transmita esses arquivos para o comando do vinculador do C++. Por exemplo, arquivos .res compilados do Windows podem ser fornecidos aqui para serem incorporados em o destino binário.
copts	Lista de strings o padrão é [] Adicione essas opções ao comando de compilação do C++. Sujeito à substituição "Make variables" e Tokenização de Bourne Shell. Cada string nesse atributo é adicionada a COPTS na ordem determinada antes de e compilar o destino binário. As sinalizações entram em vigor somente para compilar esse destino, não suas dependências, portanto, tenha cuidado com arquivos de cabeçalho incluídos em outros lugares. Todos os caminhos precisam ser relativos ao espaço de trabalho, não ao pacote atual. Esse atributo não pode ser necessário fora de third_party. Se o pacote declarar o objeto feature no_copts_tokenization: a tokenização de shell Bourne se aplica apenas a strings que consistem em uma única "marca" variável.
defines	Lista de strings o padrão é [] Lista de definições a serem adicionadas à linha de compilação. Sujeito a "Marca" variável e Tokenização de Bourne Shell. Cada string, que deve consistir em um único token de shell Bourne, tem -D como prefixo e foi adicionado à linha de comando de compilação desse destino. e todas as regras que dependem dele. Tenha muito cuidado, pois isso pode ter efeitos mais amplos. Em caso de dúvida, adicione valores definidos ao 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 de cc_shared_library vai usar a lista de dynamic_deps (de forma transitiva, ou seja, também o dynamic_deps do dynamic_deps da meta atual) para decidir quais cc_libraries o deps transitivo não precisa ser vinculado porque já foi fornecido por um cc_shared_library diferente.
hdrs_check	String; o padrão é "" Obsoleto, ambiente autônomo.
includes	Lista de strings o padrão é [] Lista de diretórios de inclusão a serem adicionados à linha de compilação. Sujeito à substituição "Make variables". Cada string é precedida pelo caminho do pacote e passada ao conjunto de ferramentas C++ para com o comando "include_paths" CROSSTOOL. Um conjunto de ferramentas em execução em um sistema POSIX com definições típicas de atributos, -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 de escrita do Google para instruções #include. Ao contrário de COPTS, essas sinalizações são adicionadas para esta regra e todas as regras que dependem dele. Observação: não são as regras das quais ele depende. Tenha tenha muito cuidado, já que isso pode ter efeitos mais amplos. Em caso de dúvida, adicione "-Eu" para COPTS. Os caminhos include adicionados incluirão os arquivos gerados, bem como na árvore de origem.
link_extra_lib	Rótulo o padrão é "@bazel_tools//tools/cpp:link_extra_lib" Controle a vinculação de outras bibliotecas. Por padrão, os binários C++ são vinculados a //tools/cpp:link_extra_lib, que, por padrão, depende da flag de rótulo //tools/cpp:link_extra_libs. Sem definir a flag, essa biblioteca fica vazia por padrão. Como definir a sinalização do rótulo permite vincular dependências opcionais, como substituições de símbolos fracos, interceptadores para funções de bibliotecas compartilhadas ou bibliotecas de tempo de execução especiais (para substituições de shoppings, preferem malloc ou --custom_malloc). Definir esse atributo como None desativa esse comportamento.
linkopts	Lista de strings o padrão é [] Adicione estas sinalizações ao comando do vinculador C++. Sujeito a "Marca" variável, tokenização de shell Bourne e expansão de rótulos. Cada string nesse atributo é adicionada a LINKOPTS antes ao vincular o destino binário. Cada elemento dessa lista que não começa com $ ou - é foi considerado o rótulo de um destino em deps. O uma lista de arquivos gerados por esse destino é anexada ao vinculador; . Um erro será informado se o rótulo for inválido ou for não declarado em deps.
linkshared	Booleano; o padrão é False Criar uma biblioteca compartilhada. Para ativar esse atributo, inclua linkshared=True na sua regra. Por padrão essa opção está desativada. A presença dessa flag significa que a vinculação ocorre com a flag -shared. como gcc, e a biblioteca compartilhada resultante pode ser carregada para um programa Java. No entanto, para fins de criação, ele nunca será vinculado ao dependente, já que se presume que as bibliotecas compartilhadas criadas com um cc_binary são carregados manualmente apenas por outros programas, então ela não deve ser considerada um substituto para cc_library regra de firewall. Por uma questão de escalonabilidade, recomendamos evitar essa abordagem e simplesmente deixar java_library depender de regras cc_library. como alternativa. Se você especificar linkopts=['-static'] e linkshared=True, você recebe uma unidade completamente independente. Se você especificar ambos linkstatic=True e linkshared=True, você recebe uma única, principalmente uma unidade independente.
linkstatic	Booleano; o padrão é True Para cc_binary e cc_test: vincular o binário na estática modo Para cc_library.link_static: confira abaixo. Por padrão, essa opção fica ativada para cc_binary e desativada para o restante. Se ativada e for um binário ou teste, essa opção manda a ferramenta de build vincular Sempre que possível, .as em vez de .so para bibliotecas do usuário. Bibliotecas do sistema, como libc (mas não bibliotecas de ambiente de execução C/C++, conforme mostrado abaixo) ainda estão vinculadas dinamicamente, assim como as bibliotecas para as quais não há uma biblioteca estática. O executável resultante ainda vai ser dinamicamente vinculados, portanto, são apenas quase estáticos. Existem três maneiras diferentes de vincular um executável: STATIC com recurso full_static_link, em que tudo é vinculado estaticamente. Por exemplo: "gcc -static foo.o libbar.a libbaz.a -lm". Para ativar esse modo, especifique fully_static_link no features. STATIC, no qual todas as bibliotecas do usuário são vinculadas estaticamente (se uma está disponível), mas quando as bibliotecas do sistema (exceto bibliotecas de ambiente de execução C/C++) são vinculadas dinamicamente, por exemplo, "gcc foo.o libfoo.a libbaz.a -lm". Para ativar esse modo, especifique linkstatic=True. DYNAMIC, no qual todas as bibliotecas são vinculadas dinamicamente (se uma versão dinâmica é disponíveis), por exemplo, "gcc foo.o libfoo.so libbaz.so -lm". Para ativar esse modo, especifique linkstatic=False. Se o atributo linkstatic ou fully_static_link no features é 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 cc_library(). Para uma biblioteca C++, linkstatic=True indica que apenas a vinculação estática é permitida, portanto, nenhum .so será produzido. linkstatic=False faz não impede a criação de bibliotecas estáticas. O atributo serve para controlar criação de bibliotecas dinâmicas. O código criado com linkstatic=False na produção será muito pequeno. Se for linkstatic=False, a ferramenta de build criará links simbólicos para dependem das bibliotecas compartilhadas na área de *.runfiles.
local_defines	Lista de strings o padrão é [] Lista de definições a serem adicionadas à linha de compilação. Sujeito a "Marca" variável e Tokenização de Bourne Shell. Cada string, que deve consistir em um único token de shell Bourne, tem -D como prefixo e foi adicionado à linha de comando de compilação desse destino. mas não aos dependentes.
malloc	Rótulo o padrão é "@bazel_tools//tools/cpp:malloc" Substitui a dependência padrão em Malloc. Por padrão, os binários C++ são vinculados a //tools/cpp:malloc, que é uma biblioteca vazia, de modo que o binário acaba usando a libc Malloc. Esse rótulo precisa se referir a um cc_library. Se a compilação for para uma versão que não seja C++ regra, essa opção não terá efeito. O valor desse atributo é ignorado se linkshared=True é especificado.
module_interfaces	Lista de rótulos o padrão é [] A lista de arquivos é considerada a interface de módulos C++20. O C++ Standard não tem restrições 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 Uso de MSVC ixx O uso é protegido pela bandeira --experimental_cpp_modules:
nocopts	String; o padrão é "" As opções de correspondência foram removidas do comando de compilação em C++. Sujeito a "Marca" variável. O valor desse atributo é interpretado como uma expressão regular. Qualquer COPTS preexistente que corresponda a essa expressão regular (incluindo valores explicitamente especificados no atributo copts da regra) será removido de COPTS para fins de compilação desta regra. Esse atributo não pode ser necessário nem usado fora de third_party. Os valores não são pré-processados de forma diferente da "Marca" substituição de variáveis.
reexport_deps	Lista de rótulos o padrão é []
stamp	Número inteiro o padrão é -1 Define se as informações da versão serão codificadas no binário. Valores possíveis: stamp = 1: sempre inclua as informações do build no binário, mesmo em --nostamp builds. Este deve ser evitada, já que ela pode eliminar o armazenamento em cache remoto dos binário e qualquer ação downstream que dependa dele. stamp = 0: sempre substitui as informações do build por valores constantes. Isso oferece um bom armazenamento em cache dos resultados da compilação. stamp = -1: a incorporação de informações do build é controlada pelo sinalização --[no]stamp. Os binários carimbos não são recriados, a menos que as dependências deles mudem.
win_def_file	Rótulo o padrão é None O arquivo DEF do Windows a ser passado para o vinculador. 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_import

Conferir origem da regra

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

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

Confira a seguir os casos de uso mais comuns:
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 = 1,
)

2: Como vincular uma biblioteca compartilhada (Unix)

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

3: Vincular uma biblioteca compartilhada à 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) Vincular uma biblioteca compartilhada a 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 = 1,
)

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

5) Vincular 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 é o mesmo em Unix e Windows:

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

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

cc_import oferece suporte a um atributo "include". 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 é [] A lista de outras bibliotecas das quais o destino depende. Leia os comentários gerais sobre deps em Atributos típicos definidos pelo a maioria das regras de build.
hdrs	Lista de rótulos o padrão é [] A lista de arquivos principais publicados por que essa biblioteca pré-compilada seja incluída diretamente pelas fontes em regras dependentes.
alwayslink	Booleano; o padrão é False Se for 1, qualquer binário que dependa (direta ou indiretamente) desse código C++ pré-compilada 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 por código em o binário, por exemplo, caso seu código seja registrado para receber algum callback por algum serviço. Se o Alwayslink não funcionar com o VS 2017 no Windows, é devido a problema conhecido, faça upgrade do seu 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 "Make variables". Cada string é precedida pelo caminho do pacote e passada ao conjunto de ferramentas C++ para com o comando "include_paths" CROSSTOOL. Um conjunto de ferramentas em execução em um sistema POSIX com definições típicas de atributos, -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 de escrita do Google para instruções #include. Ao contrário de COPTS, essas sinalizações são adicionadas para esta regra e todas as regras que dependem dele. Observação: não são as regras das quais ele depende. Tenha tenha muito cuidado, já que isso pode ter efeitos mais amplos. Em caso de dúvida, adicione "-Eu" para COPTS. O caminho include padrão não inclui arquivos . Se você precisar usar #include em um cabeçalho gerado liste-o no arquivo 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 estas sinalizações ao comando do vinculador C++. Sujeito a "Marca" variável, tokenização de shell Bourne e expansão de rótulos. Cada string nesse atributo é adicionada a LINKOPTS antes ao vincular o destino binário. Cada elemento dessa lista que não começa com $ ou - é foi considerado o rótulo de um destino em deps. O uma lista de arquivos gerados por esse destino é anexada ao vinculador; . Um erro será informado se o rótulo for inválido ou for não 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 eles estejam disponíveis que depende dele durante o tempo de execução. Tipos de arquivos permitidos: .so, .dll ou .dylib
static_library	Rótulo o padrão é None Uma única biblioteca estática pré-compilada. Tipos de arquivos permitidos: .a, .pic.a ou .lib
system_provided	Booleano; o padrão é False Se for 1, isso indica que a biblioteca compartilhada necessária no momento da execução foi fornecida pelo sistema. Em neste caso, interface_library deve ser especificado shared_library deve estar vazio.

cc_library

Conferir origem da regra

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

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

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

O nome real do arquivo de saída é libfoo.so para a biblioteca compartilhada, em que foo é o nome da regra. O outros tipos de biblioteca 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 para o nome desejado.

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

Todos os arquivos de cabeçalho usados no build devem ser declarados em a hdrs ou srcs de regras cc_*. Isso é obrigatório.

Para as regras cc_library, os cabeçalhos em hdrs compreendem interface pública da biblioteca e podem ser incluídos diretamente dos arquivos em hdrs e srcs da biblioteca e dos 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. Quando decidir se coloca um cabeçalho em hdrs ou srcs, você deve perguntar se quer que os consumidores dessa biblioteca possam incluí-lo diretamente. Essa é aproximadamente a mesma decisão que entre a visibilidade public e private nas linguagens de programação.

As regras cc_binary e cc_test não têm um para que elas também não tenham um atributo hdrs. Todos os cabeçalhos que pertencem diretamente ao binário ou ao teste devem ser listados o srcs.

Para ilustrar essas regras, veja 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, o foo.cc tem permissão para incluem 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
barra-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 eventos diretos inclusões. No exemplo acima, foo.cc pode incluem bar.h, que pode incluir baz.h, que em sua vez pode incluir baz-impl.h. Tecnicamente, os a compilação de um arquivo .cc pode incluir transitivamente qualquer cabeçalho no arquivo hdrs ou srcs na qualquer cc_library na interdição transitiva de deps. Em Nesse caso, o compilador pode ler baz.h e baz-impl.h. ao compilar foo.cc, mas foo.cc não pode contêm #include "baz.h". Para que isso seja permitido, adicione baz a 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 ser compatível com o conjunto de ferramentas. e solicitado explicitamente, por exemplo, por meio do a sinalização de linha de comando --features=layering_check parâmetro features do package. Os conjuntos de ferramentas fornecidos pelo Bazel só são compatíveis com esse recurso com Clang no Unix e no macOS.

Exemplos

Usamos a sinalização alwayslink para forçar o vinculador a vincular esse código, embora 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 = 1,
)

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). especifica a opção de vinculação -ldl para vincular a 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 os arquivos .so pré-criados no depósito. Os arquivos principais 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. Códigos de terceiros geralmente precisam 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 o destino.
deps	Lista de rótulos o padrão é [] A lista de outras bibliotecas de que o destino da biblioteca depende. Podem ser cc_library ou objc_library destinos. Leia os comentários gerais sobre deps em Atributos típicos definidos pelo a maioria das regras de build. Esses são os nomes das regras da biblioteca C++. Ao criar um binário que vincule a biblioteca dessa regra, você também vai vincular as bibliotecas em deps. Apesar das "dependências" , nem todos os clientes da biblioteca pertence aqui. As dependências de dados do ambiente 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 a o srcs. Para depender de algo sem vinculá-lo a esta biblioteca, adicione seu nome ao data.
srcs	Lista de rótulos o padrão é [] A lista de arquivos C e C++ processados para criar o destino da biblioteca. Estes são arquivos de origem e de cabeçalho em C/C++, não gerados (origem normal ou gerados. Todos os arquivos .cc, .c e .cpp serão ser compilado. Podem ser arquivos gerados: se um arquivo nomeado estiver no o outs de alguma outra regra, este cc_library dependerão automaticamente da outra regra. Os arquivos assembler puro (.s, .asm) não são pré-processados e normalmente são criados usando o assembler. Arquivos assembly pré-processados (.S) são pré-processados e normalmente criados usando o compilador C/C++. Um arquivo .h não será compilado, mas estará disponível para inclusão por origens nesta regra. Tanto .cc quanto Os arquivos .h podem incluir diretamente os cabeçalhos listados em srcs ou no hdrs desta regra ou em listada no argumento deps. Todos os arquivos #included precisam ser mencionados no Atributo hdrs disso ou cc_library referenciado regras ou elas vão ser listadas em srcs se forem privadas a esta biblioteca. Consulte "Verificação de inclusão de cabeçalho" para uma descrição mais detalhada. Os arquivos .so, .lo e .a estão arquivos pré-compilados. Sua biblioteca pode ter essas srcs se ela usar código de terceiros para o qual não têm código-fonte. Se o atributo srcs incluir o rótulo de outra regra, O cc_library vai usar os arquivos de saída dessa regra como arquivos de origem para compilar. Isso é útil para a geração única de código-fonte (para casos de uso usar, é melhor implementar uma classe de regra do Starlark e usar o cc_common API) Tipos de arquivo srcs permitidos: Arquivos de origem C e C++: .c, .cc, .cpp. .cxx, .c++ e .C Arquivos de cabeçalho C e C++: .h, .hh, .hpp, .hxx, .inc, .inl, .H Montador com pré-processador C: .S Arquivo: .a, .pic.a "Sempre vincular" biblioteca: .lo, .pic.lo Biblioteca compartilhada, com ou sem controle de versão: .so, .so.version Arquivo de objeto: .o, .pic.o ... e todas as regras que produzem esses arquivos (por exemplo, cc_embed_data). Extensões diferentes indicam linguagens de programação diferentes de acordo com a convenção de GCC.
data	Lista de rótulos o padrão é [] A lista de arquivos necessários para esta biblioteca no tempo de execução. Leia os comentários gerais sobre data em Atributos típicos definidos pelo a maioria das regras de build. Se data for o nome de um arquivo gerado, esse cc_library regra depende automaticamente da regra de firewall. Se um data for o nome de uma regra, esse cc_library regra depende automaticamente dessa regra, e os outs dessa regra são adicionados automaticamente nos arquivos de dados deste cc_library. Seu código C++ pode acessar esses arquivos de dados da seguinte forma: const std::string path = devtools_build::GetDataDependencyFilepath( "my/test/data/file");
hdrs	Lista de rótulos o padrão é [] A lista de arquivos principais publicados por a biblioteca seja incluída diretamente pelas fontes em regras dependentes. Esse é o local mais recomendado para declarar arquivos de cabeçalho que e descrever a interface da biblioteca. Esses cabeçalhos serão feitos disponíveis para inclusão pelas origens nesta regra ou em regras dependentes. Os cabeçalhos que não devem ser incluídos por um cliente desta biblioteca devem ser no atributo srcs, mesmo que estejam incluídos por um cabeçalho publicado. Consulte "Inclusão de cabeçalho verificação" para uma descrição mais detalhada. Tipos de arquivo headers permitidos: .h, .hh, .hpp, .hxx.
additional_compiler_inputs	Lista de rótulos o padrão é [] Outros arquivos que você queira passar para a linha de comando do compilador, como sanitizer listas de ignorados, por exemplo. Os arquivos especificados aqui podem ser usados em copts com o função $(location).
additional_linker_inputs	Lista de rótulos o padrão é [] Transmita esses arquivos para o comando do vinculador do C++. Por exemplo, arquivos .res compilados do Windows podem ser fornecidos aqui para serem incorporados em o destino binário.
alwayslink	Booleano; o padrão é False Se for 1, qualquer binário que dependa (direta ou indiretamente) desse código C++ do Google Cloud vinculará todos os arquivos de objeto para os 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 por código em o binário, por exemplo, caso seu código seja registrado para receber algum callback por algum serviço. Se o Alwayslink não funcionar com o VS 2017 no Windows, é devido a problema conhecido, faça upgrade do seu VS 2017 para a versão mais recente.
copts	Lista de strings o padrão é [] Adicione essas opções ao comando de compilação do C++. Sujeito à substituição "Make variables" e Tokenização de Bourne Shell. Cada string nesse atributo é adicionada a COPTS na ordem determinada antes de e compilar o destino binário. As sinalizações entram em vigor somente para compilar esse destino, não suas dependências, portanto, tenha cuidado com arquivos de cabeçalho incluídos em outros lugares. Todos os caminhos precisam ser relativos ao espaço de trabalho, não ao pacote atual. Esse atributo não pode ser necessário fora de third_party. Se o pacote declarar o objeto feature no_copts_tokenization: a tokenização de shell Bourne se aplica apenas a strings que consistem em uma única "marca" variável.
defines	Lista de strings o padrão é [] Lista de definições a serem adicionadas à linha de compilação. Sujeito a "Marca" variável e Tokenização de Bourne Shell. Cada string, que deve consistir em um único token de shell Bourne, tem -D como prefixo e foi adicionado à linha de comando de compilação desse destino. e todas as regras que dependem dele. Tenha muito cuidado, pois isso pode ter efeitos mais amplos. Em caso de dúvida, adicione valores definidos ao local_defines.
hdrs_check	String; o padrão é "" Obsoleto, ambiente autônomo.
implementation_deps	Lista de rótulos o padrão é [] A lista de outras bibliotecas de que o destino da biblioteca depende. Remover de deps, os cabeçalhos e os caminhos de inclusão dessas bibliotecas (e de todas transitives) são usadas apenas para compilação dessa biblioteca, e não para bibliotecas que dependerem disso. As bibliotecas especificadas com implementation_deps ainda estão vinculadas na binários que dependem dessa biblioteca. Por enquanto, o uso é limitado a cc_libraries e protegido pela sinalização. --experimental_cc_implementation_deps:
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 podem ser acessados "at" é o valor desse atributo anexado ao caminho relativo ao repositório. O prefixo no atributo strip_include_prefix é removido antes deste é adicionado. Esse atributo só é legal de acordo com 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 "Make variables". Cada string é precedida pelo caminho do pacote e passada ao conjunto de ferramentas C++ para com o comando "include_paths" CROSSTOOL. Um conjunto de ferramentas em execução em um sistema POSIX com definições típicas de atributos, -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 de escrita do Google para instruções #include. Ao contrário de COPTS, essas sinalizações são adicionadas para esta regra e todas as regras que dependem dele. Observação: não são as regras das quais ele depende. Tenha tenha muito cuidado, já que isso pode ter efeitos mais amplos. Em caso de dúvida, adicione "-Eu" para COPTS. Os caminhos include adicionados incluirão os arquivos gerados, bem como 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 depende, direta ou indiretamente, dessa biblioteca usando deps. (ou por meio de outros atributos que são tratados de forma semelhante: malloc atributo de cc_binary). Dependência linkopts têm precedência sobre linkopts dependentes (por exemplo, linkopts de dependência aparecem mais tarde na linha de comando). Linkopts especificados em --linkopt têm precedência sobre os linksopts de regra. O atributo linkopts só se aplica ao criar arquivos .so ou executáveis, não ao criar arquivos .a ou .lo. Portanto, se o atributo linkstatic=True for definido, O atributo linkopts não afeta a criação de essa biblioteca, apenas em outros destinos que dependem dela. Além disso, é importante observar que "-Wl,-soname" ou "-Xlinker -sonome" não são suportadas e nunca devem ser especificadas nesse atributo. Os arquivos .so produzidos por cc_library regras não são vinculadas às bibliotecas das quais dependem Se você está tentando criar uma biblioteca compartilhada para uso fora do repositório principal, por exemplo, para uso manual com dlopen() ou LD_PRELOAD, pode ser 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 arquivo binário. Esse truque é necessário para introduzir o carimbo de data/hora informações em binários, se compilamos o arquivo de origem para um arquivo de objeto da maneira normal, o carimbo de data/hora estaria incorreto. Uma compilação de linkstamp pode não incluir nenhum conjunto específico de do compilador e, portanto, não podem depender de nenhuma cabeçalho, opção do compilador ou outra variável de build. Essa opção só é necessária pacote base.
linkstatic	Booleano; o padrão é False Para cc_binary e cc_test: vincular o binário na estática modo Para cc_library.link_static: confira abaixo. Por padrão, essa opção fica ativada para cc_binary e desativada para o restante. Se ativada e for um binário ou teste, essa opção manda a ferramenta de build vincular Sempre que possível, .as em vez de .so para bibliotecas do usuário. Bibliotecas do sistema, como libc (mas não bibliotecas de ambiente de execução C/C++, conforme mostrado abaixo) ainda estão vinculadas dinamicamente, assim como as bibliotecas para as quais não há uma biblioteca estática. O executável resultante ainda vai ser dinamicamente vinculados, portanto, são apenas quase estáticos. Existem três maneiras diferentes de vincular um executável: STATIC com recurso full_static_link, em que tudo é vinculado estaticamente. Por exemplo: "gcc -static foo.o libbar.a libbaz.a -lm". Para ativar esse modo, especifique fully_static_link no features. STATIC, no qual todas as bibliotecas do usuário são vinculadas estaticamente (se uma está disponível), mas quando as bibliotecas do sistema (exceto bibliotecas de ambiente de execução C/C++) são vinculadas dinamicamente, por exemplo, "gcc foo.o libfoo.a libbaz.a -lm". Para ativar esse modo, especifique linkstatic=True. DYNAMIC, no qual todas as bibliotecas são vinculadas dinamicamente (se uma versão dinâmica é disponíveis), por exemplo, "gcc foo.o libfoo.so libbaz.so -lm". Para ativar esse modo, especifique linkstatic=False. Se o atributo linkstatic ou fully_static_link no features é 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 cc_library(). Para uma biblioteca C++, linkstatic=True indica que apenas a vinculação estática é permitida, portanto, nenhum .so será produzido. linkstatic=False faz não impede a criação de bibliotecas estáticas. O atributo serve para controlar criação de bibliotecas dinâmicas. O código criado com linkstatic=False na produção será muito pequeno. Se for linkstatic=False, a ferramenta de build criará links simbólicos para dependem das bibliotecas compartilhadas na área de *.runfiles.
local_defines	Lista de strings o padrão é [] Lista de definições a serem adicionadas à linha de compilação. Sujeito a "Marca" variável e Tokenização de Bourne Shell. Cada string, que deve consistir em um único token de shell Bourne, tem -D como prefixo e foi adicionado à linha de comando de compilação desse destino. mas não aos dependentes.
module_interfaces	Lista de rótulos o padrão é [] A lista de arquivos é considerada a interface de módulos C++20. O C++ Standard não tem restrições 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 Uso de MSVC ixx O uso é protegido pela bandeira --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 podem ser acessados no caminho com esse prefixo cortado. Se for um caminho relativo, ele será considerado como relativo ao pacote. Se for absoluta, ela é entendida como um caminho relativo ao repositório. O prefixo no atributo include_prefix é adicionado depois que esse prefixo é descascada. Esse atributo só é legal de acordo com third_party.
textual_hdrs	Lista de rótulos o padrão é [] A lista de arquivos principais publicados por a biblioteca seja incluída textualmente pelas fontes em regras dependentes. Esse é o local para declarar os arquivos de cabeçalho que não podem ser compilados sozinhos. ou seja, eles sempre precisam ser incluídos textualmente por outros arquivos-fonte para criar versões válidas o código-fonte.
win_def_file	Rótulo o padrão é None O arquivo DEF do Windows a ser passado para o vinculador. 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

Conferir origem da regra

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

cc_proto_library 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 é [] Lista de proto_library para gerar código C++.

cc_shared_library

Conferir origem da regra

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

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, esta última sendo uma dependência transitiva. Ela não vincular bar porque ele já é fornecido dinamicamente pelo dynamic_dep: bar_shared.

O foo_shared usa um arquivo script de vinculador *.lds para controlar quais símbolos deve ser exportado. A lógica de regra cc_shared_library não controla quais símbolos são exportados, ele usa apenas o que é considerado exportados para apresentar erros durante a fase de análise se duas bibliotecas compartilhadas exportarem o as mesmas metas.

Toda dependência direta de cc_shared_library é considerada como exportados. Portanto, o Bazel presume, durante a análise, que foo está sendo exportado por foo_shared. Não é esperado que o baz seja exportado por foo_shared. Todos os destinos correspondentes a exports_filter também será considerado exportado.

Cada cc_library no exemplo precisa aparecer no máximo em uma cc_shared_library. Se quiséssemos vincular baz também a bar_shared, precisaríamos adicionar tags = ["LINKABLE_MORE_THAN_ONCE"] para baz.

Devido ao atributo shared_lib_name, o arquivo produzido pelo bar_shared terá o nome bar.so em vez ao nome libbar.so que ele teria por padrão no Linux.

Erros

Two shared libraries in dependencies export the same symbols.

Isso acontecerá sempre que você criar um destino com duas métricas diferentes cc_shared_library dependências que exportam o mesmo destino. Para corrigir isso será necessário interromper a exportação das bibliotecas em um dos 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 dois dependências cc_shared_library diferentes que vinculam o mesmo destino estaticamente. Semelhante ao erro das exportações.

Uma forma de corrigir isso é parar de vincular a biblioteca a um dos cc_shared_library. Ao mesmo tempo, aquela que ainda o vincula precisa exportar a biblioteca para que aquela que não está vinculada mantenha a visibilidade os símbolos. Outra maneira é extrair uma terceira biblioteca que exporte o destino. Uma terceira maneira é marcar o culpado cc_library com LINKABLE_MORE_THAN_ONCE. mas essa correção deve ser rara, e você deve se certificar de que os É realmente seguro vincular cc_library 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 está acessível sem passar por uma das dependências cc_shared_library, mas já está vinculado a outro cc_shared_library no dynamic_deps e não exportados.

A solução é exportá-lo da dependência cc_shared_library ou extraí-lo um terceiro 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, isso não é necessário e não pode ser vinculado estaticamente ao destino cc_shared_library atual que você está sendo criados no momento. Portanto, ele não pertence a deps do cc_shared_library. Se essa biblioteca dinâmica pré-compilada for uma dependência de um do seu cc_libraries, o cc_library precisa depender dele; diretamente.

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

Você verá esse erro se, na regra atual, você estiver alegando exportar um que já esteja sendo exportado por uma das suas dependências dinâmicas.

Para corrigir isso, remova o destino de deps e dependa dele para o fluxo dinâmico. ou garantir que o exports_filter não capture esse destino.

Argumentos

Atributos
name	Nome; obrigatório Um nome exclusivo para o destino.
deps	Lista de rótulos o padrão é [] Bibliotecas de nível superior que serão vinculadas estaticamente à biblioteca compartilhada de forma incondicional depois de serem totalmente arquivados. As dependências de biblioteca transitiva dessas dependências diretas serão vinculadas a esse arquivo biblioteca, desde que não tenham sido vinculadas por um cc_shared_library em dynamic_deps. Durante a análise, a implementação da regra vai considerar qualquer destino listado em deps como exportado pela biblioteca compartilhada para informar erros ao vários cc_shared_libraries exportam os mesmos destinos. A implementação da regra não informa ao vinculador quais símbolos devem ser exportados pelo objeto compartilhado. O usuário deve tomar conta disso por meio de scripts do vinculador ou visibilidade no código-fonte. A implementação também vai acionar erros sempre que a mesma biblioteca for vinculada estaticamente. em mais de um cc_shared_library. Isso pode ser evitado adicionando "LINKABLE_MORE_THAN_ONCE" ao cc_library.tags ou por ficha a `cc_library` como uma exportação de uma das bibliotecas compartilhadas para que se possa transformar dynamic_dep do outro.
additional_linker_inputs	Lista de rótulos o padrão é [] Arquivos adicionais que você queira transmitir ao vinculador, por exemplo, scripts do vinculador. Você precisa passar separadamente todas as sinalizações de que o vinculador precisar para estar ciente deste arquivo. Para fazer isso, use 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 de cc_shared_library vai usar a lista de dynamic_deps (de forma transitiva, ou seja, também o dynamic_deps do dynamic_deps da meta atual) para decidir quais cc_libraries o deps transitivo não precisa ser vinculado porque já foi fornecido por um cc_shared_library diferente.
experimental_disable_topo_sort_do_not_use_remove_before_7_0	Booleano; o padrão é False
exports_filter	Lista de strings o padrão é [] Esse atributo contém uma lista de destinos que supostamente serão exportados pelo serviço biblioteca compartilhada. Qualquer destino deps já está definido como exportado pela biblioteca compartilhada. Esse atributo precisa ser usado para listar todos os destinos exportados pela biblioteca compartilhada. mas são dependências transitivas de deps. Observe que esse atributo não está realmente adicionando uma borda de dependência a esses destinos, o borda de dependência deve ser criada por deps.As entradas neste são apenas strings. Lembre-se de que, ao colocar uma meta 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 informa ao vinculador qual símbolos deve ser exportado. A seguinte sintaxe é permitida: //foo:__package__ para contabilizar qualquer destino em foo/BUILD //foo:__subpackages__ para contabilizar 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, cc_shared_library usará um nome para o arquivo de saída da biblioteca compartilhada com base no o nome do alvo e a plataforma. Isso inclui uma extensão e, às vezes, um prefixo. Às vezes, você pode não querer o nome padrão, por exemplo, ao carregar bibliotecas compartilhadas C++. Para Python, o prefixo padrão lib* geralmente não é desejado. Nesse caso, use este para escolher um nome personalizado.
static_deps	Lista de strings o padrão é []
user_link_flags	Lista de strings o padrão é [] Sinalizações adicionais que você queira transmitir ao vinculador. Por exemplo, para tornar vinculador ciente de um script do vinculador transmitido por additional_linker_inputs, poderá usar o seguintes: 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 passado para o vinculador. 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_static_library

Conferir origem da regra

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

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 para objetos PIC.

Grupos de saída

linkdeps

Um arquivo de texto contendo os rótulos dessas dependências transitivas dos destinos listados em deps que não contribuíram com arquivos de objeto para a biblioteca estática, mas forneça 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 todos os valores dependências dos destinos listados em deps.

Símbolos duplicados

Por padrão, a regra cc_static_library verifica se o resultado estático a biblioteca não contém símbolos duplicados. Se isso acontecer, o build falhará com um 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 ao features = ["-symbol_check"] ou globalmente via --features=-symbol_check.

Suporte a conjuntos de ferramentas para symbol_check

Os conjuntos de ferramentas em C++ configurados automaticamente e enviados com o Bazel são compatíveis com o symbol_check em todas as plataformas. Os conjuntos de ferramentas personalizados podem adicionar suporte 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 a existência de símbolos duplicados e o caminho de um arquivo que precisa ser criado se a verificação for aprovada.
• Usar o recurso symbol_check para adicionar sinalizações do arquivador que fazem com que o criar a biblioteca estática para falhar em símbolos duplicados.

Argumentos

Atributos
name	Nome; obrigatório Um nome exclusivo para o destino.
deps	Lista de rótulos o padrão é [] Lista de destinos a serem combinados em uma biblioteca estática, incluindo todos os respectivos dependências. As dependências que não fornecem nenhum arquivo de objeto não são incluídas no arquivo mas seus rótulos são reunidos no arquivo fornecido pela Grupo de saída linkdeps.

cc_test

Conferir origem da regra

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

Uma regra cc_test() compila um teste. Aqui, um teste é um wrapper binário em torno de um 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. Seria bom comentar por que seu teste precisa linkstatic isso provavelmente não é óbvio.

Destinos de saída implícitos

• name.stripped (criado apenas se solicitado explicitamente): uma versão removida. versão do binário. strip -g é executado no binário para remover a depuração. símbolos. Outras opções de remoção podem ser fornecidas na linha de comando usando --stripopt=-foo:
• name.dwp (criado apenas se solicitado explicitamente): se A fissão está ativada: uma depuração. arquivo de pacote de informações 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 extras atributos comuns a todas as regras de teste (*_test).

Argumentos

Atributos
name	Nome; obrigatório Um nome exclusivo para o destino.
deps	Lista de rótulos o padrão é [] A lista de outras bibliotecas a serem vinculadas ao destino binário. Eles podem ser cc_library ou objc_library. de destino. Também é permitido colocar scripts de vinculador (.lds) em dependências e referenciá-los em linkopts.
srcs	Lista de rótulos o padrão é [] A lista de arquivos C e C++ processados para criar o destino da biblioteca. Estes são arquivos de origem e de cabeçalho em C/C++, não gerados (origem normal ou gerados. Todos os arquivos .cc, .c e .cpp serão ser compilado. Podem ser arquivos gerados: se um arquivo nomeado estiver no o outs de alguma outra regra, este cc_library dependerão automaticamente da outra regra. Os arquivos assembler puro (.s, .asm) não são pré-processados e normalmente são criados usando o assembler. Arquivos assembly pré-processados (.S) são pré-processados e normalmente criados usando o compilador C/C++. Um arquivo .h não será compilado, mas estará disponível para inclusão por origens nesta regra. Tanto .cc quanto Os arquivos .h podem incluir diretamente os cabeçalhos listados em srcs ou no hdrs desta regra ou em listada no argumento deps. Todos os arquivos #included precisam ser mencionados no Atributo hdrs disso ou cc_library referenciado regras ou elas vão ser listadas em srcs se forem privadas a esta biblioteca. Consulte "Verificação de inclusão de cabeçalho" para uma descrição mais detalhada. Os arquivos .so, .lo e .a estão arquivos pré-compilados. Sua biblioteca pode ter essas srcs se ela usar código de terceiros para o qual não têm código-fonte. Se o atributo srcs incluir o rótulo de outra regra, O cc_library vai usar os arquivos de saída dessa regra como arquivos de origem para compilar. Isso é útil para a geração única de código-fonte (para casos de uso usar, é melhor implementar uma classe de regra do Starlark e usar o cc_common API) Tipos de arquivo srcs permitidos: Arquivos de origem C e C++: .c, .cc, .cpp. .cxx, .c++ e .C Arquivos de cabeçalho C e C++: .h, .hh, .hpp, .hxx, .inc, .inl, .H Montador com pré-processador C: .S Arquivo: .a, .pic.a "Sempre vincular" biblioteca: .lo, .pic.lo Biblioteca compartilhada, com ou sem controle de versão: .so, .so.version Arquivo de objeto: .o, .pic.o ... e todas as regras que produzem esses arquivos (por exemplo, cc_embed_data). Extensões diferentes indicam linguagens de programação diferentes de acordo com a convenção de GCC.
data	Lista de rótulos o padrão é [] A lista de arquivos necessários para esta biblioteca no tempo de execução. Leia os comentários gerais sobre data em Atributos típicos definidos pelo a maioria das regras de build. Se data for o nome de um arquivo gerado, esse cc_library regra depende automaticamente da regra de firewall. Se um data for o nome de uma regra, esse cc_library regra depende automaticamente dessa regra, e os outs dessa regra são adicionados automaticamente nos arquivos de dados deste cc_library. Seu código C++ pode acessar esses arquivos de dados da seguinte forma: const std::string path = devtools_build::GetDataDependencyFilepath( "my/test/data/file");
additional_linker_inputs	Lista de rótulos o padrão é [] Transmita esses arquivos para o comando do vinculador do C++. Por exemplo, arquivos .res compilados do Windows podem ser fornecidos aqui para serem incorporados em o destino binário.
copts	Lista de strings o padrão é [] Adicione essas opções ao comando de compilação do C++. Sujeito à substituição "Make variables" e Tokenização de Bourne Shell. Cada string nesse atributo é adicionada a COPTS na ordem determinada antes de e compilar o destino binário. As sinalizações entram em vigor somente para compilar esse destino, não suas dependências, portanto, tenha cuidado com arquivos de cabeçalho incluídos em outros lugares. Todos os caminhos precisam ser relativos ao espaço de trabalho, não ao pacote atual. Esse atributo não pode ser necessário fora de third_party. Se o pacote declarar o objeto feature no_copts_tokenization: a tokenização de shell Bourne se aplica apenas a strings que consistem em uma única "marca" variável.
defines	Lista de strings o padrão é [] Lista de definições a serem adicionadas à linha de compilação. Sujeito a "Marca" variável e Tokenização de Bourne Shell. Cada string, que deve consistir em um único token de shell Bourne, tem -D como prefixo e foi adicionado à linha de comando de compilação desse destino. e todas as regras que dependem dele. Tenha muito cuidado, pois isso pode ter efeitos mais amplos. Em caso de dúvida, adicione valores definidos ao 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 de cc_shared_library vai usar a lista de dynamic_deps (de forma transitiva, ou seja, também o dynamic_deps do dynamic_deps da meta atual) para decidir quais cc_libraries o deps transitivo não precisa ser vinculado porque já foi fornecido por um cc_shared_library diferente.
hdrs_check	String; o padrão é "" Obsoleto, ambiente autônomo.
includes	Lista de strings o padrão é [] Lista de diretórios de inclusão a serem adicionados à linha de compilação. Sujeito à substituição "Make variables". Cada string é precedida pelo caminho do pacote e passada ao conjunto de ferramentas C++ para com o comando "include_paths" CROSSTOOL. Um conjunto de ferramentas em execução em um sistema POSIX com definições típicas de atributos, -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 de escrita do Google para instruções #include. Ao contrário de COPTS, essas sinalizações são adicionadas para esta regra e todas as regras que dependem dele. Observação: não são as regras das quais ele depende. Tenha tenha muito cuidado, já que isso pode ter efeitos mais amplos. Em caso de dúvida, adicione "-Eu" para COPTS. Os caminhos include adicionados incluirão os arquivos gerados, bem como na árvore de origem.
link_extra_lib	Rótulo o padrão é "@bazel_tools//tools/cpp:link_extra_lib" Controle a vinculação de outras bibliotecas. Por padrão, os binários C++ são vinculados a //tools/cpp:link_extra_lib, que, por padrão, depende da flag de rótulo //tools/cpp:link_extra_libs. Sem definir a flag, essa biblioteca fica vazia por padrão. Como definir a sinalização do rótulo permite vincular dependências opcionais, como substituições de símbolos fracos, interceptadores para funções de bibliotecas compartilhadas ou bibliotecas de tempo de execução especiais (para substituições de shoppings, preferem malloc ou --custom_malloc). Definir esse atributo como None desativa esse comportamento.
linkopts	Lista de strings o padrão é [] Adicione estas sinalizações ao comando do vinculador C++. Sujeito a "Marca" variável, tokenização de shell Bourne e expansão de rótulos. Cada string nesse atributo é adicionada a LINKOPTS antes ao vincular o destino binário. Cada elemento dessa lista que não começa com $ ou - é foi considerado o rótulo de um destino em deps. O uma lista de arquivos gerados por esse destino é anexada ao vinculador; . Um erro será informado se o rótulo for inválido ou for não declarado em deps.
linkshared	Booleano; o padrão é False Criar uma biblioteca compartilhada. Para ativar esse atributo, inclua linkshared=True na sua regra. Por padrão essa opção está desativada. A presença dessa flag significa que a vinculação ocorre com a flag -shared. como gcc, e a biblioteca compartilhada resultante pode ser carregada para um programa Java. No entanto, para fins de criação, ele nunca será vinculado ao dependente, já que se presume que as bibliotecas compartilhadas criadas com um cc_binary são carregados manualmente apenas por outros programas, então ela não deve ser considerada um substituto para cc_library regra de firewall. Por uma questão de escalonabilidade, recomendamos evitar essa abordagem e simplesmente deixar java_library depender de regras cc_library. como alternativa. Se você especificar linkopts=['-static'] e linkshared=True, você recebe uma unidade completamente independente. Se você especificar ambos linkstatic=True e linkshared=True, você recebe uma única, principalmente uma unidade independente.
linkstatic	Booleano; o padrão é False Para cc_binary e cc_test: vincular o binário na estática modo Para cc_library.link_static: confira abaixo. Por padrão, essa opção fica ativada para cc_binary e desativada para o restante. Se ativada e for um binário ou teste, essa opção manda a ferramenta de build vincular Sempre que possível, .as em vez de .so para bibliotecas do usuário. Bibliotecas do sistema, como libc (mas não bibliotecas de ambiente de execução C/C++, conforme mostrado abaixo) ainda estão vinculadas dinamicamente, assim como as bibliotecas para as quais não há uma biblioteca estática. O executável resultante ainda vai ser dinamicamente vinculados, portanto, são apenas quase estáticos. Existem três maneiras diferentes de vincular um executável: STATIC com recurso full_static_link, em que tudo é vinculado estaticamente. Por exemplo: "gcc -static foo.o libbar.a libbaz.a -lm". Para ativar esse modo, especifique fully_static_link no features. STATIC, no qual todas as bibliotecas do usuário são vinculadas estaticamente (se uma está disponível), mas quando as bibliotecas do sistema (exceto bibliotecas de ambiente de execução C/C++) são vinculadas dinamicamente, por exemplo, "gcc foo.o libfoo.a libbaz.a -lm". Para ativar esse modo, especifique linkstatic=True. DYNAMIC, no qual todas as bibliotecas são vinculadas dinamicamente (se uma versão dinâmica é disponíveis), por exemplo, "gcc foo.o libfoo.so libbaz.so -lm". Para ativar esse modo, especifique linkstatic=False. Se o atributo linkstatic ou fully_static_link no features é 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 cc_library(). Para uma biblioteca C++, linkstatic=True indica que apenas a vinculação estática é permitida, portanto, nenhum .so será produzido. linkstatic=False faz não impede a criação de bibliotecas estáticas. O atributo serve para controlar criação de bibliotecas dinâmicas. O código criado com linkstatic=False na produção será muito pequeno. Se for linkstatic=False, a ferramenta de build criará links simbólicos para dependem das bibliotecas compartilhadas na área de *.runfiles.
local_defines	Lista de strings o padrão é [] Lista de definições a serem adicionadas à linha de compilação. Sujeito a "Marca" variável e Tokenização de Bourne Shell. Cada string, que deve consistir em um único token de shell Bourne, tem -D como prefixo e foi adicionado à linha de comando de compilação desse destino. mas não aos dependentes.
malloc	Rótulo o padrão é "@bazel_tools//tools/cpp:malloc" Substitui a dependência padrão em Malloc. Por padrão, os binários C++ são vinculados a //tools/cpp:malloc, que é uma biblioteca vazia, de modo que o binário acaba usando a libc Malloc. Esse rótulo precisa se referir a um cc_library. Se a compilação for para uma versão que não seja C++ regra, essa opção não terá efeito. O valor desse atributo é ignorado se linkshared=True é especificado.
module_interfaces	Lista de rótulos o padrão é [] A lista de arquivos é considerada a interface de módulos C++20. O C++ Standard não tem restrições 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 Uso de MSVC ixx O uso é protegido pela bandeira --experimental_cpp_modules:
nocopts	String; o padrão é "" As opções de correspondência foram removidas do comando de compilação em C++. Sujeito a "Marca" variável. O valor desse atributo é interpretado como uma expressão regular. Qualquer COPTS preexistente que corresponda a essa expressão regular (incluindo valores explicitamente especificados no atributo copts da regra) será removido de COPTS para fins de compilação desta regra. Esse atributo não pode ser necessário nem usado fora de third_party. Os valores não são pré-processados de forma diferente da "Marca" substituição de variáveis.
reexport_deps	Lista de rótulos o padrão é []
stamp	Número inteiro o padrão é 0 Define se as informações da versão serão codificadas no binário. Valores possíveis: stamp = 1: sempre inclua as informações do build no binário, mesmo em --nostamp builds. Este deve ser evitada, já que ela pode eliminar o armazenamento em cache remoto dos binário e qualquer ação downstream que dependa dele. stamp = 0: sempre substitui as informações do build por valores constantes. Isso oferece um bom armazenamento em cache dos resultados da compilação. stamp = -1: a incorporação de informações do build é controlada pelo sinalização --[no]stamp. Os binários carimbos não são recriados, a menos que as dependências deles mudem.
win_def_file	Rótulo o padrão é None O arquivo DEF do Windows a ser passado para o vinculador. 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

Conferir origem da regra

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

Representa um conjunto de ferramentas C++.

Essa regra é responsável por:

• Coletar todos os artefatos necessários para que as ações C++ sejam executadas. Isso é feito pela atributos como all_files, compiler_files, linker_files ou outros atributos terminados em _files). São geralmente são grupos de arquivos que contêm todos os arquivos necessários.
• Geração de linhas de comando corretas para ações C++. Para isso, usamos CcToolchainConfigInfo provedor (detalhes abaixo).

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

Usar tags = ["manual"] para impedir que os conjuntos de ferramentas sejam criados e configurados desnecessariamente ao invocar bazel build //...

Argumentos

Atributos
name	Nome; obrigatório Um nome exclusivo para o destino.
all_files	Rótulo obrigatório Coleção de todos os artefatos cc_Dataset. Esses artefatos serão adicionados como entradas regras_cc (exceto as ações que usam conjuntos mais precisos de artefatos dos atributos abaixo). Bazel supõe que all_files é um superconjunto de todos os outros atributos que fornecem artefatos (por exemplo, a compilação do linktamp precisa ser compilada e arquivos de link, o que leva all_files). Isso é o que cc_toolchain.files contém, e é usado por todos os Starlark regras usando o conjunto de ferramentas C++.
ar_files	Rótulo o padrão é None Coleção de todos os artefatos cc_Dataset necessários para ações de arquivamento.
as_files	Rótulo o padrão é None Coleção de todos os artefatos cc_Dataset necessários para ações de montagem.
compiler_files	Rótulo obrigatório Coleção de todos os artefatos cc_Dataset 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_Dataset necessários para ações de compilação nos casos em que há suporte para a descoberta de entrada (no momento somente do Google).
coverage_files	Rótulo o padrão é None Coleção de todos os artefatos cc_Dataset necessários para ações de cobertura. Se não for especificado, all_files são usados.
dwp_files	Rótulo obrigatório Coleção de todos os artefatos cc_dataset necessários para ações dwp.
dynamic_runtime_lib	Rótulo o padrão é None Artefato de biblioteca dinâmica para a biblioteca de ambiente de execução C++ (por exemplo, libstdc++.so). Vai ser usado quando "static_link_cpp_runtimes" está ativado e estamos vinculando dependências de maneira dinâmica.
exec_transition_for_inputs	Booleano; o padrão é False Obsoleto. Ambiente autônomo.
libc_top	Rótulo o padrão é None Uma coleção de artefatos para a 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_Dataset 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_Dataset 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 ambiente de execução C++ (por exemplo, libstdc++.a). Vai ser usado quando "static_link_cpp_runtimes" está ativado e estamos vinculando dependências estaticamente.
strip_files	Rótulo obrigatório Coleção de todos os artefatos cc_Dataset necessários para ações de remoção.
supports_header_parsing	Booleano; o padrão é False Defina como verdadeiro quando cc_Dataset for compatível com ações de análise de cabeçalho.
supports_param_files	Booleano; o padrão é True Defina como "True" quando "cc_dataset" for compatível com o uso de arquivos de parâmetros para ações de vinculação.
toolchain_config	Rótulo obrigatório A etiqueta da regra que fornece cc_toolchain_config_info.
toolchain_identifier	String; o padrão é "" O identificador usado para corresponder esse cc_Dataset com o crosstool_config.toolchain. Até que o problema 5380 seja corrigido essa é a forma recomendada de associar cc_toolchain CROSSTOOL.toolchain. Ela vai ser substituída por toolchain_config. atributo (#5380).

cc_toolchain_suite

Conferir origem da regra

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

Obsoleto: a regra é autônoma e será removida.

Argumentos

Atributos
name	Nome; obrigatório Um nome exclusivo para o destino.

fdo_prefetch_hints

Conferir origem da regra

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

Representa 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 o destino.
profile	Rótulo obrigatório Identificador 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

Conferir origem da regra

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

Representa um perfil 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 o destino.
memprof_profile	Rótulo o padrão é None Rótulo do perfil do MemProf. Espera-se que o perfil tenha extensão .profdata (para um memprof indexado/simbolizado) ou uma extensão .zip para um arquivo ZIP contendo um arquivo memprof.profdata .
profile	Rótulo obrigatório Rótulo do perfil do FDO ou uma regra que o gera. O arquivo FDO pode ter um dos seguintes extensões: .profraw para perfis de LLVM não indexados, .profdata para LLVM indexados perfil, .zip que contenha um perfil de perfil LLVM, .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 Marcador do perfil protobuf.

memprof_profile

Conferir origem da regra

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

Representa um perfil MEMPROF que está 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 o destino.
profile	Rótulo obrigatório Rótulo do perfil MEMPROF. Espera-se que o perfil tenha extensão .profdata (para um memprof indexado/simbolizado) ou uma extensão .zip para um arquivo ZIP contendo um arquivo memprof.profdata . O rótulo também pode apontar para uma regra fdo_absolute_path_profile.

propeller_optimize

Conferir origem da regra

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

Representa um perfil de otimização de hélice 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 o destino.
cc_profile	Rótulo obrigatório Rótulo do perfil transmitido para as várias ações de compilação. Este arquivo tem a extensão .txt.
ld_profile	Rótulo obrigatório Rótulo do perfil transmitido para a ação de vinculação. Este arquivo tem a extensão .txt.