Regras C / C++

Informar um problema Ver origem

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

Confira a 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 reduzida do binário. O strip -g é executado no binário para remover os símbolos de depuração. Use --stripopt=-foo para fornecer outras opções de faixa na linha de comando. Essa saída só será criada se explicitamente solicitada.
• name.dwp (criado apenas se solicitado explicitamente): se a fissão estiver ativada: um arquivo de pacote de informações de depuração adequado para depurar binários implantados remotamente. Caso contrário: um arquivo vazio.

Argumentos

Atributos
name	Nome (obrigatório) Um nome exclusivo para 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 destinos cc_library ou objc_library.
srcs	Lista de rótulos. O padrão é [] A lista de arquivos C e C++ que são processados para criar o destino. São arquivos de origem e principais C/C++, não gerados (código-fonte normal) ou gerados. Todos os arquivos .cc, .c e .cpp serão compilados. Eles podem ser arquivos gerados. Se um arquivo nomeado estiver no outs de alguma outra regra, esta regra dependerá automaticamente dela. Um arquivo .h não será compilado, mas vai estar disponível para inclusão por fontes nesta regra. Os arquivos .cc e .h podem incluir diretamente os cabeçalhos listados nestas 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 todos os cabeçalhos restantes associados às fontes 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, a regra vai depender automaticamente dela. Se os outs da regra nomeada forem arquivos de origem C ou C++, eles serão compilados nesta regra. Se forem arquivos de biblioteca, eles serão vinculados. Tipos de arquivos srcs permitidos: Arquivos de origem C e C++: .c, .cc, .cpp, .cxx, .c++, .C Arquivos de cabeçalho C e C++: .h, .hh, .hpp, .hxx, .inc, .inl, .H Assembler com pré-processador C: .S Arquivo: .a, .pic.a Biblioteca "Sempre vincular": .lo, .pic.lo Biblioteca compartilhada, com ou sem controle de 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 distintas de acordo com a convenção da gcc.
additional_linker_inputs	Lista de rótulos. O padrão é [] Transmita esses arquivos para o comando do vinculador C++. Por exemplo, arquivos .res compilados do Windows podem ser fornecidos aqui para serem incorporados no destino binário.
copts	Lista de strings. O padrão é [] Adicione essas opções ao comando de compilação em C++. Sujeito à substituição "Make variables" e tokenização do shell Bourne. Cada string nesse atributo é adicionada na ordem indicada a COPTS antes de compilar o destino binário. As flags só entram em vigor para compilar esse destino, não para as 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, e não ao pacote atual. Se o pacote declarar o recurso no_copts_tokenization, a tokenização de Bourne Shell será aplicada somente a strings que consistem em uma única variável "Make".
defines	Lista de strings. O padrão é [] Lista de definições para adicionar à linha de compilação. Sujeito à substituição de variável"Make" e tokenização do shell Bourne. Cada string, que precisa consistir em um único token do shell Bourne, é precedida por -D e adicionada à linha de comando de compilação para esse destino, bem como a todas as regras que dependem dele. Tenha muito cuidado, já que isso pode ter efeitos muito 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 "Criar variável". Cada string é precedida por -isystem e adicionada a COPTS. Ao contrário de COTS, essas sinalizações são adicionadas para essa regra e todas as regras que dependem dela. Observação: não são as regras das quais ela 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 as regras dependentes quando a compilação estiver no sandbox (padrão).
link_extra_lib	Rótulo; o padrão é "@bazel_tools//tools/cpp:link_extra_lib" Controlar 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 sinalização de rótulo //tools/cpp:link_extra_libs. Sem definir a flag, essa biblioteca fica vazia por padrão. Definir a flag de rótulo permite vincular dependências opcionais, como substituições de símbolos fracos, interceptadores para funções de biblioteca compartilhada ou bibliotecas de ambiente de execução especiais (para substituições machos, prefira malloc ou --custom_malloc). Definir esse atributo como None desativa esse comportamento.
linkopts	Lista de strings. O padrão é [] Adicione essas sinalizações ao comando do vinculador C++. Sujeito à substituição de variável"Make", tokenização de Bourne Shell e expansão de rótulos. Cada string nesse atributo é adicionada a LINKOPTS antes da vinculação do destino binário. Cada elemento dessa lista que não começa com $ ou - é considerado o rótulo de um destino em deps. A lista de arquivos gerados por esse destino é anexada às opções do vinculador. Um erro será informado se o rótulo for inválido ou não for declarado em deps.
linkshared	Booleano, nonconfigurable; o padrão é False Criar uma biblioteca compartilhada Para ativar esse atributo, inclua linkshared=True na sua regra. Por padrão, essa opção fica desativada. A presença dessa sinalização significa que a vinculação ocorre com a sinalização -shared para gcc, e a biblioteca compartilhada resultante é adequada para carregamento, por exemplo, em um programa Java. No entanto, para fins de criação, ele nunca é vinculado ao binário dependente, já que supõe-se que as bibliotecas compartilhadas criadas com a regra cc_binary são carregadas manualmente por outros programas e, portanto, não substituem a regra cc_library. Por uma questão de escalonabilidade, recomendamos evitar essa abordagem e simplesmente deixar java_library depender das regras 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, terá uma única unidade, principalmente autossuficiente.
linkstatic	Booleano; o padrão é True 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 o cc_binary e desativada para o restante. Se ativada e for um binário ou um teste, essa opção instrui a ferramenta de build a vincular as .as em vez de .so para bibliotecas do usuário sempre que possível. Algumas bibliotecas do sistema ainda podem ser vinculadas dinamicamente, assim como as bibliotecas em que não há uma biblioteca estática. Portanto, o executável resultante ainda será vinculado dinamicamente, ou seja, apenas principalmente estático. Há realmente três maneiras diferentes de vincular um executável: STATIC com o recurso full_static_link, em que tudo é vinculado estaticamente, por exemplo, "gcc -static foo.o libbar.a libbaz.a -lm". Esse modo é ativado especificando fully_static_link no atributo features. ESTÁTICO, em que todas as bibliotecas do usuário são vinculadas estaticamente (se uma versão estática estiver disponível), mas onde as bibliotecas do sistema (exceto as de ambiente de execução C/C++) são vinculadas dinamicamente, por exemplo, "gcc foo.o libfoo.a libbaz.a -lm". Esse modo é ativado especificando linkstatic=True. DINÂMICA, 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 somente vinculação estática é permitida, portanto, nenhuma .so será produzida. linkstatic=False não impede a criação de bibliotecas estáticas. O atributo destina-se a controlar a criação de bibliotecas dinâmicas. Se for linkstatic=False, a ferramenta de build criará links simbólicos para bibliotecas compartilhadas dependentes na área *.runfiles.
local_defines	Lista de strings. O padrão é [] Lista de definições para adicionar à linha de compilação. Sujeito à substituição de variável"Make" e tokenização do shell Bourne. Cada string, que precisa consistir em um único token do shell Bourne, é precedida por -D e adicionada à linha de comando de compilação 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 taxoc. Por padrão, os binários C++ são vinculados a //tools/cpp:malloc, que é uma biblioteca vazia, de modo que o binário termina usando libc markoc. 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 será ignorado se linkshared=True for especificado.
nocopts	String. O padrão é "" Remover opções de correspondência do comando de compilação em C++. Sujeito à substituição de 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 da regra. Esse atributo raramente é necessário.
stamp	Número inteiro. O padrão é -1 Define se as informações de compilação serão codificadas no binário. Valores possíveis: stamp = 1: sempre inclua as informações do build no binário, mesmo em builds --nostamp. Essa configuração precisa ser evitada, porque ela pode eliminar o armazenamento remoto do armazenamento em cache do binário e de quaisquer ações downstream que dependam dele. stamp = 0: sempre substitua as informações do build por valores constantes. Isso fornece um bom armazenamento em cache de resultados do 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 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

Confira 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.

Veja a seguir os casos de uso típicos:
1. Vincular uma biblioteca estática

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  static_library = "libmylib.a",
  # If alwayslink is turned on,
  # libmylib.a will be forcely linked into any binary that depends on it.
  # alwayslink = 1,
)

2. Vincular uma biblioteca compartilhada (Unix)

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

3. Vincular uma biblioteca compartilhada à 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 ao 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 a uma 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 aceita 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. Consulte comentários gerais sobre deps em Atributos típicos definidos pela maioria das regras de build.
hdrs	Lista de rótulos. O padrão é [] A lista de arquivos principais publicados por essa biblioteca pré-compilada a serem incluídos diretamente pelas fontes nas regras dependentes.
alwayslink	Booleano; o padrão é False Se for 1, qualquer binário que dependa (direta ou indiretamente) dessa biblioteca pré-compilada C++ será vinculado a 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 é chamado explicitamente pelo código no binário, por exemplo, se ele é registrado para receber algum callback fornecido 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.
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 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, indica que a biblioteca compartilhada necessária no momento da execução é fornecida pelo sistema. Nesse caso, interface_library precisa ser especificado e shared_library precisa estar vazio.

cc_library

Confira a 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 principais usados no build precisam ser declarados em hdrs ou srcs das regras cc_*. Isso é obrigatório.

Para regras cc_library, os cabeçalhos em hdrs compõem a interface pública da biblioteca e podem ser incluídos diretamente dos arquivos em hdrs e srcs da própria biblioteca, bem como de arquivos em hdrs e srcs de regras cc_* que listam a biblioteca no deps. Os cabeçalhos em srcs só podem ser incluídos diretamente dos arquivos em hdrs e srcs da própria biblioteca. Ao decidir se colocar um cabeçalho em hdrs ou srcs, pergunte se você quer que os consumidores dessa biblioteca possam incluí-lo diretamente. Essa é aproximadamente a mesma decisão entre a visibilidade de public e private em linguagens de programação.

As regras cc_binary e cc_test não têm uma interface exportada, então elas também não têm um atributo hdrs. Todos os cabeçalhos que pertencem ao binário ou ao teste diretamente precisam ser listados no srcs.

Para entender 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, 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
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 se aplicam somente a inclusões diretas. No exemplo acima, foo.cc pode incluir bar.h, que pode incluir baz.h, que, por sua vez, pode incluir baz-impl.h. Tecnicamente, a compilação de um arquivo .cc pode incluir transitivamente qualquer arquivo principal no hdrs ou srcs em qualquer cc_library na interdição transitiva deps. Nesse caso, o compilador pode ler baz.h e baz-impl.h ao compilar foo.cc, mas foo.cc não pode conter #include "baz.h". Para que isso seja permitido, baz precisa ser adicionado ao deps de foo.

O Bazel depende do suporte do conjunto de ferramentas para aplicar as regras de verificação de inclusão. O recurso layering_check precisa ser compatível com o conjunto de ferramentas e solicitado explicitamente, por exemplo, por meio da sinalização de linha de comando --features=layering_check ou do parâmetro features da função 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 destinos cc_library ou objc_library.
srcs	Lista de rótulos. O padrão é [] A lista de arquivos C e C++ que são processados para criar o destino. São arquivos de origem e principais C/C++, não gerados (código-fonte normal) ou gerados. Todos os arquivos .cc, .c e .cpp serão compilados. Eles podem ser arquivos gerados. Se um arquivo nomeado estiver no outs de alguma outra regra, esta regra dependerá automaticamente dela. Um arquivo .h não será compilado, mas vai estar disponível para inclusão por fontes nesta regra. Os arquivos .cc e .h podem incluir diretamente os cabeçalhos listados nestas 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 todos os cabeçalhos restantes associados às fontes 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, a regra vai depender automaticamente dela. Se os outs da regra nomeada forem arquivos de origem C ou C++, eles serão compilados nesta regra. Se forem arquivos de biblioteca, eles serão vinculados. Tipos de arquivos srcs permitidos: Arquivos de origem C e C++: .c, .cc, .cpp, .cxx, .c++, .C Arquivos de cabeçalho C e C++: .h, .hh, .hpp, .hxx, .inc, .inl, .H Assembler com pré-processador C: .S Arquivo: .a, .pic.a Biblioteca "Sempre vincular": .lo, .pic.lo Biblioteca compartilhada, com ou sem controle de 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 distintas de acordo com a convenção da gcc.
hdrs	Lista de rótulos. O padrão é [] A lista de arquivos principais publicados por essa biblioteca a serem incluídos diretamente pelas fontes nas regras dependentes. Esse é o local recomendado para declarar arquivos de cabeçalho que descrevem a interface da biblioteca. Esses cabeçalhos serão disponibilizados para inclusão pelas fontes nesta regra ou em regras dependentes. Os cabeçalhos que não podem ser incluídos por um cliente dessa biblioteca precisam ser listados no atributo srcs, mesmo que sejam incluídos por um cabeçalho publicado. Consulte Verificação de inclusão de cabeçalho para ver uma descrição mais detalhada.
additional_compiler_inputs	Lista de rótulos. O padrão é [] Quaisquer outros arquivos que você queira passar para a linha de comando do compilador, como listas de ignorados de limpeza, 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 C++. Por exemplo, arquivos .res compilados do Windows podem ser fornecidos aqui para serem incorporados no destino binário.
alwayslink	Booleano; o padrão é False Se for 1, qualquer binário que dependa (direta ou indiretamente) dessa biblioteca C++ vai ser vinculado a todos os arquivos de objeto dos arquivos listados em srcs, mesmo que alguns não contenham símbolos referenciados pelo binário. Isso é útil se o código não é chamado explicitamente pelo código no binário, por exemplo, se ele é registrado para receber algum callback fornecido 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 em C++. Sujeito à substituição "Make variables" e tokenização do shell Bourne. Cada string nesse atributo é adicionada na ordem indicada a COPTS antes de compilar o destino binário. As flags só entram em vigor para compilar esse destino, não para as 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, e não ao pacote atual. Se o pacote declarar o recurso no_copts_tokenization, a tokenização de Bourne Shell será aplicada somente a strings que consistem em uma única variável "Make".
defines	Lista de strings. O padrão é [] Lista de definições para adicionar à linha de compilação. Sujeito à substituição de variável"Make" e tokenização do shell Bourne. Cada string, que precisa consistir em um único token do shell Bourne, é precedida por -D e adicionada à linha de comando de compilação para esse destino, bem como a todas as regras que dependem dele. Tenha muito cuidado, já que isso pode ter efeitos muito amplos. Em caso de dúvida, adicione valores definidos a local_defines.
implementation_deps	Lista de rótulos. O padrão é [] A lista de outras bibliotecas de que a biblioteca de destino depende. Ao contrário de deps, os cabeçalhos e os caminhos dessas bibliotecas (e todas as dependências transitivas) são usados apenas para a compilação dessa biblioteca, e não das bibliotecas que dependem dela. As bibliotecas especificadas com implementation_deps ainda estão vinculadas em destinos binários que dependem dessa biblioteca. Por enquanto, o uso é limitado a cc_library 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 definidos, os cabeçalhos no atributo hdrs dessa regra podem ser acessados pelo valor desse atributo anexado ao caminho relativo ao repositório. O prefixo no atributo strip_include_prefix é removido antes da adição desse prefixo.
includes	Lista de strings. O padrão é [] Lista de diretórios de inclusão a serem adicionados à linha de compilação. Sujeito à substituição "Criar variável". Cada string é precedida por -isystem e adicionada a COPTS. Ao contrário de COTS, essas sinalizações são adicionadas para essa regra e todas as regras que dependem dela. Observação: não são as regras das quais ela 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 as regras dependentes quando a compilação estiver no sandbox (padrão).
linkopts	Lista de strings. O padrão é [] Adicione essas sinalizações ao comando do vinculador C++. Sujeito à substituição de variável"Make", tokenização de Bourne Shell e expansão de rótulos. Cada string nesse atributo é adicionada a LINKOPTS antes da vinculação do destino binário. Cada elemento dessa lista que não começa com $ ou - é considerado o rótulo de um destino em deps. A lista de arquivos gerados por esse destino é anexada às opções do vinculador. Um erro será informado se o rótulo for inválido ou não for declarado em deps.
linkstamp	Rótulo; o padrão é None Compila e vincula simultaneamente o arquivo de origem C++ especificado ao binário final. Esse truque é necessário para introduzir informações de carimbo de data/hora em binários. Se compilarmos o arquivo de origem em um arquivo de objeto da maneira habitual, o carimbo de data/hora ficará incorreto. Uma compilação de linkstamp pode não incluir nenhum conjunto específico de flags do compilador e, portanto, não pode depender de nenhum cabeçalho, opção de 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 o cc_binary e desativada para o restante. Se ativada e for um binário ou um teste, essa opção instrui a ferramenta de build a vincular as .as em vez de .so para bibliotecas do usuário sempre que possível. Algumas bibliotecas do sistema ainda podem ser vinculadas dinamicamente, assim como as bibliotecas em que não há uma biblioteca estática. Portanto, o executável resultante ainda será vinculado dinamicamente, ou seja, apenas principalmente estático. Há realmente três maneiras diferentes de vincular um executável: STATIC com o recurso full_static_link, em que tudo é vinculado estaticamente, por exemplo, "gcc -static foo.o libbar.a libbaz.a -lm". Esse modo é ativado especificando fully_static_link no atributo features. ESTÁTICO, em que todas as bibliotecas do usuário são vinculadas estaticamente (se uma versão estática estiver disponível), mas onde as bibliotecas do sistema (exceto as de ambiente de execução C/C++) são vinculadas dinamicamente, por exemplo, "gcc foo.o libfoo.a libbaz.a -lm". Esse modo é ativado especificando linkstatic=True. DINÂMICA, 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 somente vinculação estática é permitida, portanto, nenhuma .so será produzida. linkstatic=False não impede a criação de bibliotecas estáticas. O atributo destina-se a controlar a criação de bibliotecas dinâmicas. Se for linkstatic=False, a ferramenta de build criará links simbólicos para bibliotecas compartilhadas dependentes na área *.runfiles.
local_defines	Lista de strings. O padrão é [] Lista de definições para adicionar à linha de compilação. Sujeito à substituição de variável"Make" e tokenização do shell Bourne. Cada string, que precisa consistir em um único token do shell Bourne, é precedida por -D e adicionada à linha de comando de compilação desse destino, mas não aos dependentes.
nocopts	String. O padrão é "" Remover opções de correspondência do comando de compilação em C++. Sujeito à substituição de 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 da regra. Esse atributo raramente é 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 podem ser acessados no caminho deles com esse prefixo cortado. Se for um caminho relativo, será usado 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 ele é removido.
textual_hdrs	Lista de rótulos. O padrão é [] A lista de arquivos principais publicados por essa biblioteca a serem incluídos 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

Confira 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 .

Exemplos

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 é [] A lista de regras proto_library para as quais gerar o código C++.

cc_shared_library

Confira a 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)

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 foo e baz estaticamente, sendo que o último é uma dependência transitiva. Ele não vincula bar porque já é fornecido dinamicamente pelo dynamic_dep bar_shared.

foo_shared usa um arquivo *.lds de script do vinculador para controlar quais símbolos precisam ser exportados. A lógica da regra cc_shared_library não controla quais símbolos são exportados. Ela usa apenas o que é considerado exportado para causar erros durante a fase de análise se duas bibliotecas compartilhadas exportarem os mesmos destinos.

Todas as dependências diretas de cc_shared_library são consideradas exportadas. Portanto, o Bazel supõe durante a análise que foo está sendo exportado por foo_shared. baz não é considerado exportado por foo_shared. Todos os destinos que correspondem a exports_filter também são exportados.

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"] a baz.

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

Erros

Two shared libraries in dependencies export the same symbols.

Isso vai acontecer sempre que você estiver criando um destino com duas dependências cc_shared_library diferentes que exportam o mesmo destino. Para corrigir isso, é necessário interromper a exportação das bibliotecas em uma das dependências cc_shared_library.

Two shared libraries in dependencies link the same library statically

Isso acontecerá sempre que você estiver criando um novo cc_shared_library com duas dependências cc_shared_library diferentes que vinculam o mesmo destino estaticamente. Semelhante ao erro com exportações.

Uma maneira de corrigir isso é parar de vincular a biblioteca a uma das dependências cc_shared_library. Ao mesmo tempo, aquele que ainda está vinculado precisa exportar a biblioteca para que aquele que não está vinculado mantenha a visibilidade dos símbolos. Outra maneira é extrair uma terceira biblioteca que exporte o destino. Uma terceira maneira é marcar o cc_library culpado com LINKABLE_MORE_THAN_ONCE, mas essa correção é rara, e você precisa garantir que o cc_library seja realmente seguro para vincular mais de uma vez.

'//foo:foo' is already linked statically in '//bar:bar' but not exported`

Isso significa que uma biblioteca no fechamento transitivo da deps pode ser acessada sem passar por uma das dependências cc_shared_library, mas já está vinculada a um cc_shared_library diferente em dynamic_deps e não é exportada.

A solução é exportá-lo da dependência cc_shared_library ou extrair 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, ela não vai precisar e não poderá ser vinculada estaticamente ao destino cc_shared_library atual que você está criando. Portanto, ele não pertence ao deps do cc_shared_library. Se essa biblioteca dinâmica pré-compilada for uma dependência de uma das suas cc_libraries, a cc_library precisará depender diretamente dela.

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

Esse erro será exibido se, na regra atual, você estiver alegando exportar um destino que já está sendo exportado por uma das dependências dinâmicas.

Para corrigir isso, remova o destino de deps e dependa apenas dele da 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 o destino.
deps	Lista de rótulos. O padrão é [] Bibliotecas de nível superior que serão vinculadas estaticamente à biblioteca compartilhada após serem totalmente arquivadas. Qualquer dependência de biblioteca transitiva dessas dependências diretas será vinculada a essa biblioteca compartilhada, desde que não tenha sido vinculada por um 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. Isso vai causar erros quando várias cc_shared_libraries exportarem 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 fazer isso com scripts do vinculador ou declarações de visibilidade no código-fonte. A implementação também acionará erros sempre que a mesma biblioteca estiver vinculada estaticamente a mais de um cc_shared_library. Para evitar isso, adicione "LINKABLE_MORE_THAN_ONCE" à cc_library.tags ou liste "cc_library" como uma exportação de uma das bibliotecas compartilhadas para que uma possa ser transformada em dynamic_dep da outra.
additional_linker_inputs	Lista de rótulos. O padrão é [] Todos os arquivos adicionais que você queira transmitir para o vinculador, por exemplo, scripts do vinculador. Você precisa transmitir separadamente todas as sinalizações do vinculador que o vinculador precisa para reconhecer esse arquivo. Faça isso usando o atributo user_link_flags.
dynamic_deps	Lista de rótulos. O padrão é [] Essas são outras dependências de cc_shared_library de que o destino atual depende. A implementação de cc_shared_library usará a lista de dynamic_deps (de forma transitiva, ou seja, também o dynamic_deps do dynamic_deps do destino atual) para decidir qual cc_libraries no deps transitivo não será vinculado, porque eles já são fornecidos por um cc_shared_library diferente.
exports_filter	Lista de strings. O padrão é [] Esse atributo contém uma lista de destinos que são declarados como exportados pela biblioteca compartilhada atual. Qualquer deps de destino já é considerado 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. Observe que esse atributo não está adicionando uma borda de dependência a esses destinos. Em vez disso, 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 instrução do vinculador sobre quais símbolos precisam ser exportados. A seguinte sintaxe é permitida: //foo:__package__ para considerar qualquer destino em foo/BUILD //foo:__subpackages__ para considerar qualquer destino em foo/BUILD ou qualquer outro pacote abaixo de foo/, como foo/bar/BUILD
shared_lib_name	String. O padrão é "" Por padrão, a 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 não costuma ser desejado. Nesse caso, é possível usar esse atributo para escolher um nome personalizado.
user_link_flags	Lista de strings. O padrão é [] Outras sinalizações que você queira passar para o vinculador. Por exemplo, para que o vinculador reconheça um script do vinculador transmitido por additional_linker_inputs, você pode usar 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

Confira 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 de FDO que está no espaço de trabalho ou em um caminho absoluto especificado. Exemplos:

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

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

Argumentos

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

Confira 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 do 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 o destino.
absolute_path_profile	String. O padrão é "" Caminho absoluto para o perfil do FDO. O arquivo FDO pode ter uma destas extensões: .profraw para perfil LLVM não indexado, .profdata para perfil LLVM indexado, .zip que contém um perfil LLVM profraw ou .afdo para perfil AutoFDO.
profile	Rótulo; o padrão é None Etiqueta do perfil do FDO ou da regra que o gera. O arquivo FDO pode ter uma das seguintes extensões: .profraw para perfil LLVM não indexado, .profdata para perfil LLVM indexado, .zip que contém um perfil LLVM profraw, .afdo para perfil AutoFDO, .xfdo para perfil XBinary. O rótulo também pode apontar para uma regra fdo_absolute_path_profile.
proto_profile	Rótulo; o padrão é None Identificador do perfil protobuf.

memprof_profile

Confira a 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 de MEMPROF que está no espaço de trabalho ou em um caminho absoluto especificado. Exemplos:

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

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

Argumentos

Atributos
name	Nome (obrigatório) Um nome exclusivo para o destino.
absolute_path_profile	String. O padrão é "" Caminho absoluto para o perfil de MEMPROF. O arquivo só pode ter uma extensão .profdata ou .zip (em que o ZIP precisa conter um arquivo memprof.profdata).
profile	Rótulo; o padrão é None Marcador do perfil do MEMPROF. O perfil precisa ter uma extensão .profdata (para um perfil 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

Confira a 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. Exemplos

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 passado para a ação de vinculação. Este arquivo tem a extensão .txt.

cc_test

Confira 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 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 destinos cc_library ou objc_library.
srcs	Lista de rótulos. O padrão é [] A lista de arquivos C e C++ que são processados para criar o destino. São arquivos de origem e principais C/C++, não gerados (código-fonte normal) ou gerados. Todos os arquivos .cc, .c e .cpp serão compilados. Eles podem ser arquivos gerados. Se um arquivo nomeado estiver no outs de alguma outra regra, esta regra dependerá automaticamente dela. Um arquivo .h não será compilado, mas vai estar disponível para inclusão por fontes nesta regra. Os arquivos .cc e .h podem incluir diretamente os cabeçalhos listados nestas 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 todos os cabeçalhos restantes associados às fontes 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, a regra vai depender automaticamente dela. Se os outs da regra nomeada forem arquivos de origem C ou C++, eles serão compilados nesta regra. Se forem arquivos de biblioteca, eles serão vinculados. Tipos de arquivos srcs permitidos: Arquivos de origem C e C++: .c, .cc, .cpp, .cxx, .c++, .C Arquivos de cabeçalho C e C++: .h, .hh, .hpp, .hxx, .inc, .inl, .H Assembler com pré-processador C: .S Arquivo: .a, .pic.a Biblioteca "Sempre vincular": .lo, .pic.lo Biblioteca compartilhada, com ou sem controle de 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 distintas de acordo com a convenção da gcc.
additional_linker_inputs	Lista de rótulos. O padrão é [] Transmita esses arquivos para o comando do vinculador C++. Por exemplo, arquivos .res compilados do Windows podem ser fornecidos aqui para serem incorporados no destino binário.
copts	Lista de strings. O padrão é [] Adicione essas opções ao comando de compilação em C++. Sujeito à substituição "Make variables" e tokenização do shell Bourne. Cada string nesse atributo é adicionada na ordem indicada a COPTS antes de compilar o destino binário. As flags só entram em vigor para compilar esse destino, não para as 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, e não ao pacote atual. Se o pacote declarar o recurso no_copts_tokenization, a tokenização de Bourne Shell será aplicada somente a strings que consistem em uma única variável "Make".
defines	Lista de strings. O padrão é [] Lista de definições para adicionar à linha de compilação. Sujeito à substituição de variável"Make" e tokenização do shell Bourne. Cada string, que precisa consistir em um único token do shell Bourne, é precedida por -D e adicionada à linha de comando de compilação para esse destino, bem como a todas as regras que dependem dele. Tenha muito cuidado, já que isso pode ter efeitos muito 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 "Criar variável". Cada string é precedida por -isystem e adicionada a COPTS. Ao contrário de COTS, essas sinalizações são adicionadas para essa regra e todas as regras que dependem dela. Observação: não são as regras das quais ela 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 as regras dependentes quando a compilação estiver no sandbox (padrão).
link_extra_lib	Rótulo; o padrão é "@bazel_tools//tools/cpp:link_extra_lib" Controlar 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 sinalização de rótulo //tools/cpp:link_extra_libs. Sem definir a flag, essa biblioteca fica vazia por padrão. Definir a flag de rótulo permite vincular dependências opcionais, como substituições de símbolos fracos, interceptadores para funções de biblioteca compartilhada ou bibliotecas de ambiente de execução especiais (para substituições machos, prefira malloc ou --custom_malloc). Definir esse atributo como None desativa esse comportamento.
linkopts	Lista de strings. O padrão é [] Adicione essas sinalizações ao comando do vinculador C++. Sujeito à substituição de variável"Make", tokenização de Bourne Shell e expansão de rótulos. Cada string nesse atributo é adicionada a LINKOPTS antes da vinculação do destino binário. Cada elemento dessa lista que não começa com $ ou - é considerado o rótulo de um destino em deps. A lista de arquivos gerados por esse destino é anexada às opções do vinculador. Um erro será 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: vincule o binário no modo estático. Para cc_library.linkstatic: confira abaixo. Por padrão, essa opção fica ativada para o cc_binary e desativada para o restante. Se ativada e for um binário ou um teste, essa opção instrui a ferramenta de build a vincular as .as em vez de .so para bibliotecas do usuário sempre que possível. Algumas bibliotecas do sistema ainda podem ser vinculadas dinamicamente, assim como as bibliotecas em que não há uma biblioteca estática. Portanto, o executável resultante ainda será vinculado dinamicamente, ou seja, apenas principalmente estático. Há realmente três maneiras diferentes de vincular um executável: STATIC com o recurso full_static_link, em que tudo é vinculado estaticamente, por exemplo, "gcc -static foo.o libbar.a libbaz.a -lm". Esse modo é ativado especificando fully_static_link no atributo features. ESTÁTICO, em que todas as bibliotecas do usuário são vinculadas estaticamente (se uma versão estática estiver disponível), mas onde as bibliotecas do sistema (exceto as de ambiente de execução C/C++) são vinculadas dinamicamente, por exemplo, "gcc foo.o libfoo.a libbaz.a -lm". Esse modo é ativado especificando linkstatic=True. DINÂMICA, 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 somente vinculação estática é permitida, portanto, nenhuma .so será produzida. linkstatic=False não impede a criação de bibliotecas estáticas. O atributo destina-se a controlar a criação de bibliotecas dinâmicas. Se for linkstatic=False, a ferramenta de build criará links simbólicos para bibliotecas compartilhadas dependentes na área *.runfiles.
local_defines	Lista de strings. O padrão é [] Lista de definições para adicionar à linha de compilação. Sujeito à substituição de variável"Make" e tokenização do shell Bourne. Cada string, que precisa consistir em um único token do shell Bourne, é precedida por -D e adicionada à linha de comando de compilação 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 taxoc. Por padrão, os binários C++ são vinculados a //tools/cpp:malloc, que é uma biblioteca vazia, de modo que o binário termina usando libc markoc. 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 será ignorado se linkshared=True for especificado.
nocopts	String. O padrão é "" Remover opções de correspondência do comando de compilação em C++. Sujeito à substituição de 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 da regra. Esse atributo raramente é necessário.
stamp	Número inteiro. O padrão é 0 Define se as informações de compilação serão codificadas no binário. Valores possíveis: stamp = 1: sempre inclua as informações do build no binário, mesmo em builds --nostamp. Essa configuração precisa ser evitada, porque ela pode eliminar o armazenamento remoto do armazenamento em cache do binário e de quaisquer ações downstream que dependam dele. stamp = 0: sempre substitua as informações do build por valores constantes. Isso fornece um bom armazenamento em cache de resultados do 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 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

Confira a 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:

• Coletar todos os artefatos necessários para a execução das ações do C++. Isso é feito por atributos como all_files, compiler_files, linker_files ou outros atributos que terminam com _files. Eles geralmente são grupos de arquivos que abrangem todos os arquivos necessários.
• Gerar linhas de comando corretas para ações C++. Isso é feito usando o provedor CcToolchainConfigInfo (detalhes abaixo).

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

Use tags = ["manual"] para evitar que 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 para todas as ações relacionadas a rules_cc, exceto aquelas que usam conjuntos mais precisos de artefatos dos atributos abaixo. O Bazel supõe que all_files é um superconjunto de todos os outros atributos de fornecimento de artefatos. Por exemplo, a compilação de linkstamp precisa de arquivos de compilação e link, então usa all_files. Isso é o que cc_toolchain.files contém, e isso é usado por todas as regras do Starlark que usam o conjunto de ferramentas C++.
ar_files	Rótulo; o padrão é None Coleção de todos os artefatos cc_toolkit 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 de cc_toolkit necessários para ações de compilação no caso de suporte para a descoberta de entrada (atualmente 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 será usado.
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 da biblioteca dinâmica para a biblioteca de ambiente de execução C++ (por exemplo, libstdc++.so). Ela será usada quando o recurso "static_link_cpp_runtimes" estiver ativado e estivermos vinculando dependências dinamicamente.
exec_transition_for_inputs	Booleano; o padrão é True Defina como "True" para criar todas as entradas de arquivo em cc_toolkit para a plataforma exec, em vez de ter nenhuma transição (ou seja, a plataforma de destino por padrão).
libc_top	Rótulo; o padrão é None Uma coleção de artefatos para a libc passados 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 do módulo a ser usado para builds modulares.
objcopy_files	Rótulo (obrigatório) Coleção de todos os artefatos cc_toolkit necessários para ações de objcopy.
static_runtime_lib	Rótulo; o padrão é None Artefato da biblioteca estática para a biblioteca de ambiente de execução C++ (por exemplo, libstdc++.a). Ela será usada quando o recurso "static_link_cpp_runtimes" estiver ativado e estivermos 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_toolkit for compatível com ações de análise de cabeçalho.
supports_param_files	Booleano; o padrão é True Defina como "True" quando o cc_toolkit for compatível com o uso de arquivos de parâmetros para ações de vinculação.
toolchain_config	Rótulo (obrigatório) O rótulo da regra que fornece cc_toolchain_config_info.
toolchain_identifier	String, nonconfigurable; o padrão é "" O identificador usado para corresponder esse cc_toolkit ao crosstool_config.toolkit correspondente. Até que o problema #5380 seja corrigido, essa é a maneira recomendada de associar cc_toolchain a CROSSTOOL.toolchain. Ele será substituído pelo atributo toolchain_config (#5380).

cc_toolchain_suite

Confira a 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ções de conjuntos de ferramentas C++.

Essa regra é responsável por:

• Coletar todos os conjuntos de ferramentas C++ relevantes.
• Seleção de um conjunto de ferramentas dependendo das opções --cpu e --compiler transmitidas para o Bazel.

Consulte também esta página para conferir a configuração elaborada do conjunto de ferramentas de C++ e a documentação sobre a seleção do conjunto de ferramentas.

Argumentos

Atributos
name	Nome (obrigatório) Um nome exclusivo para o destino.
toolchains	Strings de mapeamento de dicionário para labels; nonconfigurable; obrigatório Um mapa das strings "<cpu>" ou "<cpu>|<compiler>" para um rótulo cc_toolchain. "<cpu>" será usado quando apenas --cpu for transmitido para o Bazel, e "<cpu>|<compiler>" será usado quando --cpu e --compiler forem transmitidos para o Bazel. Exemplos cc_toolchain_suite( name = "toolchain", toolchains = { "piii|gcc": ":my_cc_toolchain_for_piii_using_gcc", "piii": ":my_cc_toolchain_for_piii_using_default_compiler", }, )