Regras C / C++

Informar um problema Ver código-fonte Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Regras

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

cc_binary

Conferir origem da regra

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

Destinos de saída implícitos

• name.stripped (criado apenas se solicitado explicitamente): uma versão removida. versão 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: Essa saída só é criada se for explicitamente solicitada.
• name.dwp (criado apenas se solicitado explicitamente): se A Fission 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 essa segmentação.
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.
srcs	Lista de rótulos o padrão é [] A lista de arquivos C e C++ processados para criar o destino. Esses são arquivos de origem e de cabeçalho C/C++, não gerados (código de 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, esta regra dependerão automaticamente da outra regra. Um arquivo .h não será compilado, mas estará disponível para inclusão por fontes nesta regra. Os arquivos .cc e .h podem incluir diretamente cabeçalhos listados em srcs ou no hdrs de qualquer regra listada no argumento deps. Todos os arquivos #included precisam ser mencionados no atributo srcs desta regra ou no atributo hdrs dos cc_library()s referenciados. O estilo recomendado é que os cabeçalhos associados a uma biblioteca sejam listados no atributo hdrs dessa biblioteca e os valores cabeçalhos associados às origens desta regra a serem listados em srcs. Consulte Verificação da inclusão de cabeçalho. para uma descrição mais detalhada. Se o nome de uma regra estiver no srcs, ela vai depender automaticamente dessa regra. Se os outs da regra nomeada forem C ou C++ arquivos de origem, eles são compilados nessa regra. Se forem arquivos de biblioteca, eles serão vinculados. Tipos de arquivo srcs permitidos: Arquivos-fonte C e C++: .c, .cc, .cpp, .cxx, .c++, .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 Biblioteca "Sempre vincular": .lo, .pic.lo Biblioteca compartilhada, com ou sem versão: .so, .so.version Arquivo de objeto: .o, .pic.o e as regras que produzem esses arquivos. Extensões diferentes denotam linguagens de programação diferentes de acordo com a convenção gcc.
additional_linker_inputs	Lista de rótulos; o padrão é [] Transmita esses arquivos para o comando do vinculador do C++. Por exemplo, arquivos .res do Windows compilados 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 em C++. Sujeita à substituição "Make variables" e Tokenização de Bourne Shell. Cada string neste atributo é adicionada na ordem especificada a COPTS antes de compilar o destino binário. As flags só têm efeito para a compilação desse destino, não para as dependências dele. 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. Se o pacote declarar o feature no_copts_tokenization, a tokenização do shell Bourne será aplicada apenas a strings que consistem em uma única variável "Make".
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 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 a local_defines.
includes	Lista de strings. O padrão é []. Lista de diretórios de inclusão a serem adicionados à linha de compilação. Sujeito à substituição de "Make variable". Cada string é precedida por -isystem e adicionada a COPTS. 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 flags "-I" a COPTS. Os cabeçalhos precisam ser adicionados a srcs ou hdrs; caso contrário, eles não estarão disponíveis para os quando a compilação está no modo sandbox (o padrão).
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 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 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 é informado se o rótulo for inválido ou não for declarado em deps.
linkshared	Booleano; não configurável; o padrão é False Criar uma biblioteca compartilhada. Para ativar esse atributo, inclua linkshared=True na regra. Por padrão, essa opção fica desativada. A presença dessa flag significa que a vinculação ocorre com a flag -shared para gcc, e a biblioteca compartilhada resultante é adequada para carregar em, por exemplo, 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. Para fins de escalonabilidade, recomendamos evitar essa abordagem e permitir que java_library dependa das regras de cc_library. Se você especificar linkopts=['-static'] e linkshared=True, você terá uma única unidade completamente independente. Se você especificar linkstatic=True e linkshared=True, vai receber uma unidade única e independente.
linkstatic	Booleano; o padrão é True Para cc_binary e cc_test: vincular o binário na estática modo Para cc_library.linkstatic: consulte abaixo. Por padrão, essa opção fica ativada para cc_binary e desativada para os demais. Se ativada e se for um binário ou teste, essa opção instrui a ferramenta de build a vincular .a em vez de .so para bibliotecas de usuário sempre que possível. Algumas bibliotecas do sistema ainda podem ser 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 o recurso fully_static_link, em que tudo é vinculado de forma estática. E.g. "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 execução C/C++) são vinculadas de forma dinâmica, 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. 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 tem como objetivo controlar a criação de bibliotecas dinâmicas. Se for linkstatic=False, a ferramenta de build vai criar links simbólicos 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 de shell Bourne, é precedida por -D e adicionada à linha de comando de compilação para esse destino, mas não às dependências.
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 regra que não seja C++, essa opção não terá efeito. O valor desse atributo é ignorado se linkshared=True é especificado.
nocopts	String; o padrão é "" As opções de correspondência foram removidas 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 os valores explicitamente especificados no atributo copts da regra) serão removidos dos COPTS para compilar esta regra. Esse atributo raramente será necessário.
stamp	Integer; 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. Evite essa configuração, já que ela pode acabar com o armazenamento em cache remoto do binário e de qualquer ação downstream que dependa dele. stamp = 0: sempre substitua as informações de build por valores constantes. Isso gera um bom cache de resultados de build. stamp = -1: a incorporação de informações de build é controlada pela flag --[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 transmitido 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

Acessar a origem da regra

cc_import(name, deps, data, hdrs, alwayslink, compatible_with, deprecation, distribs, features, interface_library, licenses, restricted_to, shared_library, static_library, system_provided, tags, target_compatible_with, testonly, visibility)

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

Confira a seguir os casos de uso 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 com a biblioteca de interface (Windows)

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

4. Vincular uma biblioteca compartilhada com system_provided=True (Windows)

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

5. Vinculação à biblioteca estática ou compartilhada
No Unix:

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

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

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

No Windows:

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

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

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

cc_import oferece suporte a um atributo de inclusão. Por exemplo:

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

Argumentos

Atributos
name	Nome; obrigatório Um nome exclusivo para o destino.
deps	Lista de rótulos; o padrão é [] A lista de outras bibliotecas de que o destino depende. Confira 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 principais publicados por essa biblioteca pré-compilada para ser incluída diretamente pelas origens em regras dependentes.
alwayslink	Booleano; o padrão é False Se 1, qualquer binário que dependa (diretamente 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 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.
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
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 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. Nesse caso, interface_library precisa ser especificado e shared_library precisa 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, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, nocopts, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)

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

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

Para regras cc_library, os cabeçalhos em hdrs compreendem a interface pública do biblioteca e pode ser incluído diretamente dos arquivos em hdrs e srcs da própria biblioteca, bem como dos arquivos em hdrs e srcs de cc_* regras 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 colocar um cabeçalho hdrs ou srcs, pergunte se você quer os consumidores da biblioteca para poder incluí-lo diretamente. Essa é praticamente a mesma decisão Visibilidade de public e private nas linguagens de programação.

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

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.
srcs	Lista de rótulos o padrão é [] A lista de arquivos C e C++ processados para criar o destino. 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, esta regra dependerão automaticamente da outra regra. Um arquivo .h não será compilado, mas estará disponível para inclusão por fontes nesta regra. Os arquivos .cc e .h podem incluir diretamente cabeçalhos listados em srcs ou no hdrs de qualquer regra listada no argumento deps. Todos os arquivos #included precisam ser mencionados no srcs desta regra ou da Atributo hdrs dos cc_library()s referenciados. O estilo recomendado é que os cabeçalhos associados a uma biblioteca sejam listados no atributo hdrs dessa biblioteca e que os cabeçalhos restantes associados às origens dessa regra sejam listados em srcs. Consulte "Verificação de inclusão de cabeçalho" para uma descrição mais detalhada. Se o nome de uma regra estiver no srcs, ela vai depender automaticamente dessa regra. Se o outs da regra nomeada for arquivos de origem C ou C++, eles serão compilados nessa regra. Se forem arquivos de biblioteca, eles serão vinculados. Tipos de arquivo srcs permitidos: Arquivos-fonte C e C++: .c, .cc, .cpp, .cxx, .c++, .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 Biblioteca "Sempre vincular": .lo, .pic.lo Biblioteca compartilhada, com ou sem versão: .so, .so.version Arquivo de objeto: .o, .pic.o e as regras que produzem esses arquivos. Extensões diferentes indicam linguagens de programação diferentes de acordo com a convenção de GCC.
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 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 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.
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 a 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 1, qualquer binário que dependa (diretamente 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 seu 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, isso se deve a um problema conhecido. Faça upgrade do 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 de "Make variable" e tokenização de shell Bourne. 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 devem ser relativo ao espaço de trabalho, não ao pacote atual. 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 à substituição da variável "Make" e tokenização do shell Bourne. 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, porque isso pode ter efeitos de longo alcance. Em caso de dúvida, adicione valores definidos ao local_defines.
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 flag --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 desta regra são acessíveis em é o valor desse atributo precedido pelo caminho relativo ao repositório. O prefixo no atributo strip_include_prefix é removido antes de ser adicionado.
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 é prefixada com -isystem e adicionada a COPTS. Ao contrário de COPTS, essas flags são adicionadas a essa regra e a todas as regras que dependem dela. Observação: não são as regras das quais ele depende. Tenha muito cuidado, porque isso pode ter efeitos de longo alcance. Em caso de dúvida, adicione flags "-I" a COPTS. Os cabeçalhos precisam ser adicionados a srcs ou hdrs. Caso contrário, eles não estarão disponíveis para regras dependentes quando a compilação estiver em sandbox (padrão).
linkopts	Lista de strings. O padrão é []. Adicione essas flags 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.
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 carimbo de link não pode incluir um conjunto específico de sinalizadores do compilador e, portanto, não pode 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.linkstatic: confira abaixo. Por padrão, essa opção fica ativada para cc_binary e desativada para os demais. Se ativada e se for um binário ou teste, essa opção instrui a ferramenta de build a vincular .a em vez de .so para bibliotecas de usuário sempre que possível. Algumas bibliotecas do sistema ainda podem ser 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. Na verdade, 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. E.g. "gcc -static foo.o libbar.a libbaz.a -lm". Esse modo é ativado especificando fully_static_link no atributo features. STATIC, no qual todas as bibliotecas do usuário são vinculadas estaticamente (se um 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, 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. 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 não impede a criação de bibliotecas estáticas. O atributo serve para controlar criação de bibliotecas dinâmicas. Se for linkstatic=False, a ferramenta de build vai criar links simbólicos 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 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.
nocopts	String; o padrão é "" Remova as opções correspondentes do comando de compilação do 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 raramente será necessário.
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 desta regra são acessíveis no caminho com esse prefixo cortado. Se for um caminho relativo, ele será considerado como relativo ao pacote. Se for absoluto, ele será entendido como um caminho relativo ao repositório. O prefixo no atributo include_prefix é adicionado depois que esse prefixo é descascada.
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 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 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

Acessar a origem da regra

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

cc_proto_library gera código C++ de arquivos .proto.

deps precisa apontar para regras proto_library .

Exemplo:

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

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

proto_library(
    name = "foo_proto",
)

Argumentos

Atributos
name	Nome: obrigatório Um nome exclusivo para o destino.
deps	Lista de rótulos; o padrão é [] Lista de proto_library para gerar código C++.

cc_shared_library

Conferir origem da regra

cc_shared_library(name, deps, additional_linker_inputs, dynamic_deps, exports_filter, shared_lib_name, tags, user_link_flags, win_def_file)

Ele produz uma biblioteca compartilhada.

Exemplo

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

No exemplo, foo_shared vincula estaticamente foo. e baz, esta última sendo 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 de vinculação *.lds para controlar quais símbolos devem ser exportados. A lógica da regra cc_shared_library não controla quais símbolos são exportados, ela só usa o que é presumido ser exportado para gerar erros durante a fase de análise se duas bibliotecas compartilhadas exportarem as mesmas metas.

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

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

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

Erros

Two shared libraries in dependencies export the same symbols.

Isso vai acontecer sempre que você criar um destino com duas dependências cc_shared_library diferentes que exportam o mesmo destino. Para corrigir isso, impeça que as bibliotecas sejam exportadas em uma das dependências cc_shared_library.

Two shared libraries in dependencies link the same library statically

Isso vai acontecer sempre que você criar um novo cc_shared_library com dois diferentes dependências cc_shared_library 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, o que ainda vincula precisa exportar a biblioteca para que o que não vincula mantenha a visibilidade dos símbolos. Outra maneira é extrair uma terceira biblioteca que 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 do deps pode ser acessada sem passar por uma das dependências cc_shared_library, mas já está vinculada a uma cc_shared_library diferente em dynamic_deps e não é exportada.

A solução é exportá-lo da dependência cc_shared_library ou extrair uma terceira cc_shared_library que o exporta.

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

Se você tiver uma biblioteca dinâmica pré-compilada, ela não precisa e não pode ser vinculada estaticamente ao destino cc_shared_library atual que você está criando. Portanto, ele não pertence a deps do cc_shared_library. Se essa biblioteca dinâmica pré-compilada for uma dependência de um do seu cc_libraries, o cc_library vai precisar 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 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 de forma estática à biblioteca compartilhada depois de serem arquivadas. 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 precisa cuidar disso usando scripts de vinculação ou declarações de 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 é [] Qualquer arquivo adicional que você queira transmitir ao vinculador, por exemplo, scripts de vinculador. É necessário transmitir separadamente todas as flags de vinculação necessárias para que o vinculador saiba sobre esse 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 das quais 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 do objetivo atual) para decidir quais cc_libraries o deps transitivo não precisa ser vinculado porque já foi fornecido por um cc_shared_library diferente.
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á compreendido para ser exportado pela biblioteca compartilhada. Esse atributo precisa ser usado para listar todos os destinos exportados pela biblioteca compartilhada, mas que são dependências transitivas de deps. Esse atributo não está adicionando uma borda de dependência a essas metas. A borda de dependência precisa ser criada por deps. As entradas nesse atributo são apenas strings. Lembre-se de que, 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 indicação ao vinculador de quais símbolos devem ser exportados. A sintaxe a seguir é permitida: //foo:__package__ para considerar 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
shared_lib_name	String; o padrão é "" Por padrão, cc_shared_library vai usar 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ê pode não querer o nome padrão. Por exemplo, ao carregar bibliotecas compartilhadas C++ para Python, o prefixo lib* padrão geralmente não é desejado. Nesse caso, use esse atributo para escolher um nome personalizado.
user_link_flags	Lista de strings o padrão é [] Sinalizações adicionais que você queira transmitir ao vinculador. Por exemplo, para informar ao vinculador um script de vinculador 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 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.

fdo_prefetch_hints

Acessar a origem da regra

fdo_prefetch_hints(name, compatible_with, deprecation, distribs, features, licenses, profile, restricted_to, tags, target_compatible_with, testonly, visibility)

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

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

fdo_profile(
  name = "hints_abs",
  absolute_path_profile = "/absolute/path/profile.afdo",
)

Argumentos

Atributos
name	Nome; obrigatório Um nome exclusivo para o destino.
profile	Rótulo o padrão é None 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

Acessar a origem da regra

fdo_profile(name, absolute_path_profile, compatible_with, deprecation, distribs, features, licenses, profile, proto_profile, restricted_to, tags, target_compatible_with, testonly, visibility)

Representa um perfil de FDO que está no espaço de trabalho ou em um caminho absoluto especificado. Exemplos:

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

fdo_profile(
  name = "fdo_abs",
  absolute_path_profile = "/absolute/path/profile.zip",
)

Argumentos

Atributos
name	Nome: obrigatório Um nome exclusivo para essa segmentação.
absolute_path_profile	String; o padrão é "" Caminho absoluto para o perfil do FDO. 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 profraw LLVM ou .afdo para perfil AutoFDO.
profile	Rótulo: o padrão é None. Rótulo do perfil do 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 profraw LLVM, .afdo para perfil AutoFDO e .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 do protobuf.

memprof_profile

Conferir origem da regra

memprof_profile(name, absolute_path_profile, compatible_with, deprecation, distribs, features, licenses, profile, restricted_to, tags, target_compatible_with, testonly, visibility)

Representa um perfil MEMPROF que está no espaço de trabalho ou em um caminho absoluto especificado. Exemplos:

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

memprof_profile(
  name = "memprof_abs",
  absolute_path_profile = "/absolute/path/profile.afdo",
)

Argumentos

Atributos
name	Nome: obrigatório Um nome exclusivo para essa segmentação.
absolute_path_profile	String; o padrão é "" Caminho absoluto para o perfil MEMPROF. O arquivo só pode ter uma extensão .profdata ou .zip (onde o arquivo zip precisa conter um arquivo memprof.profdata).
profile	Rótulo o padrão é None 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, compatible_with, deprecation, distribs, features, ld_profile, licenses, restricted_to, tags, target_compatible_with, testonly, 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"
)

propeller_optimize(
    name = "layout_absolute",
    absolute_cc_profile = "/absolute/cc_profile.txt",
    absolute_ld_profile = "/absolute/ld_profile.txt"
)

Argumentos

Atributos
name	Nome: obrigatório Um nome exclusivo para o destino.
ld_profile	Rótulo o padrão é None Rótulo do perfil transmitido para a ação de vinculação. Esse arquivo tem a extensão .txt.

cc_test

Acessar a origem da regra

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

Argumentos

Atributos
name	Nome: obrigatório Um nome exclusivo para essa segmentação.
deps	Lista de rótulos; o padrão é [] A lista de outras bibliotecas a serem vinculadas ao destino binário. Eles podem ser cc_library ou objc_library. de destino.
srcs	Lista de rótulos; o padrão é [] A lista de arquivos C e C++ processados para criar o destino. Esses são arquivos de origem e principais C/C++, não gerados (código de 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, esta regra dependerão automaticamente da outra regra. Um arquivo .h não será compilado, mas estará disponível para inclusão por fontes nesta regra. Os arquivos .cc e .h podem incluir diretamente cabeçalhos listados em srcs ou no hdrs de qualquer regra listada no argumento deps. Todos os arquivos #included precisam ser mencionados no srcs desta regra ou da Atributo hdrs dos cc_library()s referenciados. O estilo recomendado é que os cabeçalhos associados a uma biblioteca sejam listados no atributo hdrs dessa biblioteca e que os cabeçalhos restantes associados às origens dessa regra sejam listados em srcs. Consulte "Verificação de inclusão de cabeçalho" para uma descrição mais detalhada. Se o nome de uma regra estiver em srcs, ela depende dela automaticamente. Se os outs da regra nomeada forem C ou C++ arquivos de origem, eles são compilados nessa regra. Se forem arquivos de biblioteca, eles serão vinculados. Tipos de arquivo srcs permitidos: Arquivos-fonte C e C++: .c, .cc, .cpp, .cxx, .c++, .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 Biblioteca "Sempre vincular": .lo, .pic.lo Biblioteca compartilhada, com ou sem versão: .so, .so.version Arquivo de objeto: .o, .pic.o e as regras que produzem esses arquivos. Extensões diferentes denotam linguagens de programação diferentes de acordo com a convenção gcc.
additional_linker_inputs	Lista de rótulos o padrão é [] Transmita esses arquivos para o comando do vinculador C++. Por exemplo, arquivos .res do Windows compilados 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++. Sujeita à 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 devem ser relativo ao espaço de trabalho, não ao pacote atual. 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".
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 precisa consistir em um único token de 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, pois isso pode ter efeitos mais amplos. Em caso de dúvida, adicione valores definidos a local_defines.
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 é prefixada com -isystem e adicionada a COPTS. Ao contrário de 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 depende. Tenha muito cuidado, porque isso pode ter efeitos de longo alcance. Em caso de dúvida, adicione "-Eu" para COPTS. Os cabeçalhos precisam ser adicionados a srcs ou hdrs; caso contrário, eles não estarão disponíveis para os quando a compilação está no modo sandbox (o padrão).
link_extra_lib	Rótulo: o padrão é "@bazel_tools//tools/cpp:link_extra_lib". Controle a vinculação de bibliotecas extras. 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 é informado se o rótulo for inválido ou não for declarado em deps.
linkstatic	Booleano; o padrão é False Para cc_binary e cc_test: vincular o binário na estática modo Para cc_library.linkstatic: confira abaixo. Por padrão, essa opção fica ativada para cc_binary e desativada para os demais. Se ativada e se for um binário ou teste, essa opção instrui a ferramenta de build a vincular .a em vez de .so para bibliotecas de usuário sempre que possível. Algumas bibliotecas do sistema ainda podem ser 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. Na verdade, 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. E.g. "gcc -static foo.o libbar.a libbaz.a -lm". Esse modo é ativado especificando fully_static_link no atributo features. STATIC, no qual todas as bibliotecas do usuário são vinculadas estaticamente (se um 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. 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 tem como objetivo controlar a criação de bibliotecas dinâmicas. Se for linkstatic=False, a ferramenta de build vai criar links simbólicos 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 a "Marca" variável e Tokenização de Bourne Shell. Cada string, que precisa consistir em um único token de shell Bourne, é precedida por -D e adicionada à linha de comando de compilação para esse destino, mas não aos seus 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 regra que não seja C++, essa opção não terá efeito. O valor desse atributo é ignorado se linkshared=True é especificado.
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 os valores explicitamente especificados no atributo copts da regra) serão removidos dos COPTS para compilar esta regra. Esse atributo raramente é necessário.
stamp	Integer; 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 de build é controlada pela flag --[no]stamp. Os binários carimbados não são reconstruídos, a menos que as dependências mudem.
win_def_file	Rótulo o padrão é None O arquivo DEF do Windows a ser transmitido 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_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, restricted_to, static_runtime_lib, strip_files, supports_header_parsing, supports_param_files, tags, target_compatible_with, testonly, toolchain_config, toolchain_identifier, visibility)

Representa um conjunto de ferramentas C++.

Essa regra é responsável por:

• Coleta de todos os artefatos necessários para a execução de ações em C++. Isso é feito pela atributos como all_files, compiler_files, linker_files ou outros atributos que terminam com _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 esta página para conferir a documentação de seleção e configuração de conjuntos de ferramentas C++.

Use tags = ["manual"] para impedir que as cadeias de ferramentas sejam criadas e configuradas desnecessariamente ao invocar bazel build //...

Argumentos

Atributos
name	Nome; obrigatório Um nome exclusivo para essa segmentação.
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). É o que cc_toolchain.files contém e é usado por todas as regras do Starlark que usam o conjunto de ferramentas C++.
ar_files	Rótulo: o padrão é None. Coleta de todos os artefatos cc_toolchain necessários para arquivar ações.
as_files	Rótulo o padrão é None Coleta de todos os artefatos do cc_toolchain 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 Coleta 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âmico para a biblioteca de tempo 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 é True Definido como "True" para criar todas as entradas de arquivo em cc_toolchain para a plataforma de execução, em vez de não ter transição (ou seja, a plataforma de destino padrão).
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 Coleta de todos os artefatos cc_toolchain necessários para vincular ações.
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 Coleta de todos os artefatos cc_toolchain necessários para ações de objcopy.
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 "True" quando "cc_DATASET" oferecer suporte a ações de análise de cabeçalho.
supports_param_files	Booleano; o padrão é True Definido como "True" quando o cc_toolchain oferece suporte ao uso de arquivos de parâmetro 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; nonconfigurable; o padrão é "" O identificador usado para corresponder esse cc_Dataset com o crosstool_config.toolchain. Até que o problema #5380 seja corrigido, esta é a maneira recomendada de associar cc_toolchain a 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)

Representa uma coleção de cadeias de ferramentas C++.

Essa regra é responsável por:

• coletar todos os conjuntos de ferramentas de C++ relevantes;
• Como selecionar um conjunto de ferramentas dependendo das opções --cpu e --compiler passados para o Bazel.

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.

Argumentos

Atributos
name	Nome: obrigatório Um nome exclusivo para o destino.
toolchains	Dicionário mapeando strings para rótulos nonconfigurable; obrigatório Um mapa de "<cpu>" ou "<cpu>|<compiler>" strings para um rótulo cc_toolchain. "<CPU>" será usado quando apenas --cpu é passado para o Bazel e "<cpu>|<compiler>" será usado quando --cpu e --compiler são transmitidos para o Bazel. Exemplo: cc_toolchain_suite( name = "toolchain", toolchains = { "piii|gcc": ":my_cc_toolchain_for_piii_using_gcc", "piii": ":my_cc_toolchain_for_piii_using_default_compiler", }, )