Esta página foi traduzida pela API Cloud Translation.

Regras C / C++

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

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 do binário. 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 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++ processados para criar o destino. Estes são arquivos de origem e cabeçalho 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, essa regra vai depender automaticamente dela. Um arquivo `.h` não será compilado, mas vai estar disponível para inclusão pelas fontes nesta regra. Os arquivos `.cc` e `.h` podem incluir diretamente os cabeçalhos listados nesses `srcs` ou no `hdrs` de qualquer regra listada no argumento `deps`. Todos os arquivos `#include`d precisam ser mencionados no atributo `srcs` dessa regra ou no atributo `hdrs` das `cc_library()`s referenciadas. O estilo recomendado é que os cabeçalhos associados a uma biblioteca sejam listados no atributo `hdrs` dessa biblioteca e 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 em `srcs`, a regra dependerá automaticamente dele. Se os `outs` da regra nomeada forem 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 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` 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 distintas 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 no destino binário.
`copts`	Lista de strings. O padrão é `[]`. Adicione essas opções ao comando de compilação do C++. Sujeito à substituição de "Make variables" e à tokenização de shell Bourne. Cada string nesse atributo é adicionada à `COPTS` na ordem especificada antes de compilar o destino binário. As sinalizações entram em vigor apenas para compilar esse destino, e não as dependências dele. Portanto, tenha cuidado com arquivos de cabeçalho incluídos em outros lugares. Todos os caminhos precisam ser relativos ao espaço de trabalho, não ao pacote atual. Se o pacote declarar o recurso `no_copts_tokenization`, a tokenização de shell Bourne se aplicará apenas a strings que consistam 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 de 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, bem como a todas as regras que dependem dele. Tenha muito cuidado, já que isso pode ter efeitos muito maiores. 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 sinalizações 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, já que isso pode ter efeitos mais amplos. Em caso de dúvida, adicione sinalizações "-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 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 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 de Malloc, prefira `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 à substituição da variável"Make", à tokenização do shell Bourne e à expansão de rótulos. Cada string nesse atributo é adicionada a `LINKOPTS` antes de vincular o destino binário. Cada elemento dessa lista que não começa com `$` ou `-` é considerado o rótulo de um destino em `deps`. A lista de arquivos gerados por 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; não configurável; 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 flag significa que a vinculação ocorre com a flag `-shared` para `gcc` e que a biblioteca compartilhada resultante é adequada para ser carregada em um programa Java, por exemplo. No entanto, para fins de criação, ela nunca será vinculada ao binário dependente, já que se presume que as bibliotecas compartilhadas criadas com uma regra cc_binary são carregadas apenas manualmente por outros programas. Por isso, ela não deve ser considerada um substituto para a regra cc_library. Por uma questão de escalonabilidade, recomendamos evitar essa abordagem e simplesmente deixar `java_library` depender de regras `cc_library`. Se você especificar `linkopts=['-static']` e `linkshared=True`, receberá uma única unidade completamente independente. Se você especificar `linkstatic=True` e `linkshared=True`, receberá uma única unidade, em sua maioria, independente.
`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 `cc_binary` e desativada para o restante. Se ativada e for um binário ou teste, essa opção instrui a ferramenta de compilação a vincular em `.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 aquelas que não têm uma biblioteca estática. O executável resultante ainda será vinculado de maneira dinâmica, ou seja, será apenas quase estático. Existem três maneiras diferentes de vincular um executável: STATIC com recurso full_static_link, em que tudo é vinculado estaticamente, por exemplo, "`gcc -static foo.o libbar.a libbaz.a -lm`". Para ativar esse modo, especifique `fully_static_link` no atributo `features`. STATIC, em que todas as bibliotecas do usuário são vinculadas estaticamente (se uma versão estática estiver disponível), mas em que 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`". 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`". 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 somente 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 a criação de bibliotecas dinâmicas. Se for `linkstatic=False`, a ferramenta de criação 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 de 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 aos dependentes.
`malloc`	Rótulo; o padrão é `"@bazel_tools//tools/cpp:malloc"` Substitui a dependência padrão em Malloc. Por padrão, os binários C++ são vinculados a `//tools/cpp:malloc`, que é uma biblioteca vazia. Portanto, 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 não C++, essa opção não terá efeito. O valor desse atributo será ignorado se `linkshared=True` for 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 valores especificados explicitamente no atributo copts da regra) será removido de `COPTS` para fins de compilação da regra. Esse atributo raramente será necessário.
`stamp`	Número inteiro. O padrão é `-1`. Define se as informações da versão serão codificadas no binário. Valores possíveis: `stamp = 1`: sempre inclui as informações do build no binário, mesmo em builds `--nostamp`. Evite essa configuração, já que ela possivelmente elimina o armazenamento em cache remoto do binário e qualquer ação downstream que dependa dele. `stamp = 0`: sempre substitui as informações do build por valores constantes. Isso fornece um bom armazenamento em cache dos resultados da compilação. `stamp = -1`: a incorporação de informações do 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. Ela pode ser usada para exportar símbolos durante a vinculação de uma biblioteca compartilhada.

cc_import

Exibir 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. Como vincular uma biblioteca compartilhada (Unix)

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

3. Como vincular uma biblioteca compartilhada à biblioteca de interfaces (Windows)

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

4. Como vincular uma biblioteca compartilhada a 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 é compatível com um atributo "include". Por exemplo:

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

Argumentos

Atributos
`name`	Nome, obrigatório Um nome exclusivo para o destino.
`deps`	Lista de rótulos. O padrão é `[]`. A lista de outras bibliotecas das quais o destino depende. Consulte os 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 esta biblioteca pré-compilada a ser incluído diretamente pelas fontes em regras dependentes.
`alwayslink`	Booleano. O padrão é `False`. Se for 1, qualquer binário que dependa (direta ou indiretamente) dessa biblioteca C++ pré-compilada vinculará todos os arquivos de objeto arquivados na biblioteca estática, mesmo que alguns não contenham símbolos referenciados pelo binário. Isso é útil se o código não for chamado explicitamente por código no binário, por exemplo, se seu código for registrado para receber algum callback fornecido por algum serviço. Se o Alwayslink não funcionar com o VS 2017 no Windows, há 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 arquivo 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 ela esteja disponível para o binário que depende dele durante o tempo de execução. Tipos de arquivo permitidos: `.so`, `.dll` ou `.dylib`
`static_library`	Rótulo; o padrão é `None` Uma única biblioteca estática pré-compilada. Tipos de arquivo permitidos: `.a`, `.pic.a` ou `.lib`
`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

Exibir 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 da inclusão de cabeçalho

Todos os arquivos principais usados no build precisam ser declarados na hdrs ou srcs das regras de cc_*. Isso é obrigatório.

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

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

Para ilustrar essas regras, 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 tem permissão para 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, tem permissão para incluir baz-impl.h. Tecnicamente, a compilação de um arquivo .cc pode incluir de forma transitiva qualquer arquivo principal na hdrs ou srcs em qualquer cc_library no fechamento deps transitivo. 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 ao conjunto de ferramentas para aplicar as regras de verificação de inclusão. O recurso layering_check precisa ser compatível com o conjunto de ferramentas e solicitado explicitamente, por exemplo, por meio 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ão compatíveis apenas 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++ processados para criar o destino. Estes são arquivos de origem e cabeçalho 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, essa regra vai depender automaticamente dela. Um arquivo `.h` não será compilado, mas vai estar disponível para inclusão pelas fontes nesta regra. Os arquivos `.cc` e `.h` podem incluir diretamente os cabeçalhos listados nesses `srcs` ou no `hdrs` de qualquer regra listada no argumento `deps`. Todos os arquivos `#include`d precisam ser mencionados no atributo `srcs` dessa regra ou no atributo `hdrs` das `cc_library()`s referenciadas. O estilo recomendado é que os cabeçalhos associados a uma biblioteca sejam listados no atributo `hdrs` dessa biblioteca e 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 em `srcs`, a regra dependerá automaticamente dele. Se os `outs` da regra nomeada forem 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 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` 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 distintas de acordo com a convenção gcc.
`hdrs`	Lista de rótulos. O padrão é `[]`. É a lista de arquivos principais publicados por essa biblioteca para serem incluídos diretamente pelas fontes em regras dependentes. Esse é o local ideal para declarar arquivos principais 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 serão incluídos por um cliente dessa biblioteca precisarão ser listados no atributo `srcs`, mesmo que estejam incluídos por um cabeçalho publicado. Consulte Verificação de inclusão de cabeçalho para uma descrição mais detalhada.
`additional_compiler_inputs`	Lista de rótulos. O padrão é `[]`. Outros arquivos que você queira transmitir para a linha de comando do compilador, como listas de ignorados de limpadores, 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 do Windows compilados 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++ 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 for chamado explicitamente por código no binário, por exemplo, se seu código for registrado para receber algum callback fornecido por algum serviço. Se o Alwayslink não funcionar com o VS 2017 no Windows, há 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 variables" e à tokenização de shell Bourne. Cada string nesse atributo é adicionada à `COPTS` na ordem especificada antes de compilar o destino binário. As sinalizações entram em vigor apenas para compilar esse destino, e não as dependências dele. Portanto, tenha cuidado com arquivos de cabeçalho incluídos em outros lugares. Todos os caminhos precisam ser relativos ao espaço de trabalho, não ao pacote atual. Se o pacote declarar o recurso `no_copts_tokenization`, a tokenização de shell Bourne se aplicará apenas a strings que consistam 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 de 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, bem como a todas as regras que dependem dele. Tenha muito cuidado, já que isso pode ter efeitos muito maiores. 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 o destino da biblioteca depende. Ao contrário de `deps`, os cabeçalhos e os caminhos de inclusão dessas bibliotecas (e todas as dependências transitivas) são usados apenas para compilação dessa biblioteca, e não para bibliotecas que dependem dela. As bibliotecas especificadas com `implementation_deps` ainda são vinculadas em destinos binários que dependem dessa biblioteca. Por enquanto, o uso é limitado a cc_libraries e protegido pela sinalização `--experimental_cc_implementation_deps`.
`include_prefix`	String. O padrão é `""`. O prefixo a ser adicionado aos caminhos dos cabeçalhos desta regra. Quando definido, os cabeçalhos no atributo `hdrs` dessa regra podem ser acessados em que o valor desse atributo seja anexado ao caminho relativo ao repositório. O prefixo no atributo `strip_include_prefix` é removido antes que esse prefixo seja 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 sinalizações 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, já que isso pode ter efeitos mais amplos. Em caso de dúvida, adicione sinalizações "-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 no modo sandbox (o padrão).
`linkopts`	Lista de strings. O padrão é `[]`. Adicione estas sinalizações ao comando do vinculador C++. Sujeito à substituição da variável"Make", à tokenização do shell Bourne e à expansão de rótulos. Cada string nesse atributo é adicionada a `LINKOPTS` antes de vincular o destino binário. Cada elemento dessa lista que não começa com `$` ou `-` é considerado o rótulo de um destino em `deps`. A lista de arquivos gerados por 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 compilamos o arquivo de origem em um arquivo de objeto da maneira normal, o carimbo de data/hora ficaria incorreto. Uma compilação de linkstamp pode não incluir nenhum conjunto específico de flags de compilador e, portanto, não pode depender de nenhum cabeçalho, opção do compilador ou outra variável de build específica. Essa opção só pode ser 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 o restante. Se ativada e for um binário ou teste, essa opção instrui a ferramenta de compilação a vincular em `.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 aquelas que não têm uma biblioteca estática. O executável resultante ainda será vinculado de maneira dinâmica, ou seja, será apenas quase estático. Existem três maneiras diferentes de vincular um executável: STATIC com recurso full_static_link, em que tudo é vinculado estaticamente, por exemplo, "`gcc -static foo.o libbar.a libbaz.a -lm`". Para ativar esse modo, especifique `fully_static_link` no atributo `features`. STATIC, em que todas as bibliotecas do usuário são vinculadas estaticamente (se uma versão estática estiver disponível), mas em que 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`". 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`". 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 somente 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 a criação de bibliotecas dinâmicas. Se for `linkstatic=False`, a ferramenta de criação 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 de 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 aos dependentes.
`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 valores especificados explicitamente no atributo copts da regra) será removido de `COPTS` para fins de compilação da regra. Esse atributo raramente será necessário.
`strip_include_prefix`	String. O padrão é `""`. O prefixo a ser removido dos caminhos dos cabeçalhos desta regra. Quando definido, os cabeçalhos no atributo `hdrs` dessa regra ficam acessíveis no caminho 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 é removido.
`textual_hdrs`	Lista de rótulos. O padrão é `[]`. A lista de arquivos principais publicados por essa biblioteca a ser incluído textualmente por fontes em regras dependentes. Esse é o local para declarar arquivos de cabeçalho que não podem ser compilados por conta própria. Ou seja, eles sempre precisam ser incluídos textualmente por outros arquivos de origem para criar um código válido.
`win_def_file`	Rótulo; o padrão é `None` O arquivo DEF do Windows a ser passado para o vinculador. Esse atributo só deve ser usado quando o Windows for a plataforma de destino. Ela pode ser usada para exportar símbolos durante a vinculação de uma biblioteca compartilhada.

cc_proto_library

Exibir 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 é [].

A lista de regras proto_library para gerar código C++.

cc_shared_library

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

O foo_shared usa um arquivo *.lds de script do vinculador para controlar quais símbolos precisam ser exportados. A lógica de regra cc_shared_library não controla quais símbolos são exportados, ela usa apenas o que é considerado exportado para apresentar 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 presume, durante a análise, que foo está sendo exportado por foo_shared. Não é esperado que baz seja exportado por foo_shared. Todos os destinos correspondentes a exports_filter também serão exportados.

Cada cc_library no exemplo precisa aparecer no máximo em uma cc_shared_library. Para 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 ele teria por padrão no Linux.

Erros

`Two shared libraries in dependencies export the same symbols.`

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

`Two shared libraries in dependencies link the same library statically`

Isso vai acontecer sempre que você criar um novo cc_shared_library com duas dependências cc_shared_library diferentes que vincularem o mesmo destino estaticamente. Semelhante ao erro das exportações.

Uma maneira de corrigir isso é parar de vincular a biblioteca a uma das dependências cc_shared_library. Ao mesmo tempo, a que ainda faz a vinculação precisa exportar a biblioteca para que aquela que não está fazendo a vinculação mantenha a visibilidade para os símbolos. Outra maneira é extrair uma terceira biblioteca que exporte o destino. Uma terceira maneira é marcar o culpado cc_library com LINKABLE_MORE_THAN_ONCE, mas essa correção é rara. Verifique se é mesmo seguro vincular o cc_library mais de uma vez.

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

Isso significa que uma biblioteca no fechamento transitivo da deps 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 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 precisa ser vinculada estaticamente e não pode ser vinculada estaticamente ao destino cc_shared_library atual que você está criando no momento. Portanto, ele não pertence a deps de cc_shared_library. Se essa biblioteca dinâmica pré-compilada for uma dependência de um dos seus cc_libraries, o cc_library precisará depender diretamente dela.

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

Você verá esse erro se, na regra atual, alegar exportar um destino que já está sendo exportado por uma das dependências dinâmicas.

Para corrigir isso, remova o destino de deps e confie nele da dependência dinâmica ou verifique se 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 depois de serem arquivadas por completo. Qualquer dependência de biblioteca transitiva dessas dependências diretas será vinculada a essa biblioteca compartilhada, desde que ainda não tenha sido vinculada por um `cc_shared_library` em `dynamic_deps`. Durante a análise, a implementação da regra vai considerar qualquer destino listado em `deps` como exportado pela biblioteca compartilhada para mostrar erros quando vários `cc_shared_libraries` exportarem os mesmos destinos. A implementação da regra não informa ao vinculador quais símbolos precisam ser exportados pelo objeto compartilhado. O usuário deve cuidar disso usando scripts do vinculador ou declarações de visibilidade no código-fonte. A implementação também acionará erros sempre que a mesma biblioteca for vinculada estaticamente a mais de um `cc_shared_library`. Para evitar isso, adicione `"LINKABLE_MORE_THAN_ONCE"` ao `cc_library.tags` ou liste "cc_library" como uma exportação de uma das bibliotecas compartilhadas para que uma possa se tornar `dynamic_dep` da outra.
`additional_linker_inputs`	Lista de rótulos. O padrão é `[]`. Arquivos adicionais que você queira transmitir ao vinculador, por exemplo, scripts do vinculador. Você precisa transmitir separadamente as sinalizações necessárias para o vinculador estar ciente desse arquivo. Para fazer isso, use o atributo `user_link_flags`.
`dynamic_deps`	Lista de rótulos. O padrão é `[]`. Essas são outras dependências de `cc_shared_library` de que o destino atual depende. A implementação de `cc_shared_library` vai usar a lista de `dynamic_deps` (de forma transitiva, ou seja, também o `dynamic_deps` do `dynamic_deps` do destino atual) para decidir qual `cc_libraries` na `deps` transitiva não deve ser vinculada porque elas já são fornecidas por uma `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 pela biblioteca compartilhada atual. Qualquer destino `deps` já está definido como exportado pela biblioteca compartilhada. Esse atributo precisa ser usado para listar todos os destinos que são exportados pela biblioteca compartilhada, mas são dependências transitivas de `deps`. Observe que esse atributo não está realmente adicionando uma borda de dependência a esses destinos. Ela 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 informa ao vinculador quais símbolos precisam ser exportados. A seguinte sintaxe é permitida: `//foo:__package__` para contabilizar 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, cc_shared_library 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, é possível usar 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 que o vinculador reconheça um script do vinculador transmitido por meio de 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. Ela pode ser usada para exportar símbolos durante a vinculação de uma biblioteca compartilhada.

fdo_prefetch_hints

Exibir 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 especificado. Por exemplo:

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

Rótulo do perfil de dicas. O arquivo de dicas tem a extensão .afdo. O rótulo também pode apontar para uma regra fdo_absolute_path_profile.

fdo_profile

Exibir 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. Por exemplo:

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 só pode ter a extensão .afdo.
`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 perfis LLVM não indexados, .profdata para perfis indexados do LLVM, .zip que tenha um perfil LLVM profraw, .afdo para perfis AutoFDO, .xfdo para perfis XBinary. O rótulo também pode apontar para uma regra fdo_absolute_path_profile.
`proto_profile`	Rótulo; o padrão é `None` Rótulo do perfil protobuf.

memprof_profile

Exibir 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. Por exemplo:

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 MEMPROF. O arquivo pode ter apenas 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. O perfil precisa ter uma extensão .profdata (para um perfil memprof indexado/simbolizado) ou uma extensão .zip para um arquivo ZIP que contém um arquivo memprof.profdata. O rótulo também pode apontar para uma regra fdo_absolute_path_profile.

propeller_optimize

Exibir 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

Exibir 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++ processados para criar o destino. Estes são arquivos de origem e cabeçalho 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, essa regra vai depender automaticamente dela. Um arquivo `.h` não será compilado, mas vai estar disponível para inclusão pelas fontes nesta regra. Os arquivos `.cc` e `.h` podem incluir diretamente os cabeçalhos listados nesses `srcs` ou no `hdrs` de qualquer regra listada no argumento `deps`. Todos os arquivos `#include`d precisam ser mencionados no atributo `srcs` dessa regra ou no atributo `hdrs` das `cc_library()`s referenciadas. O estilo recomendado é que os cabeçalhos associados a uma biblioteca sejam listados no atributo `hdrs` dessa biblioteca e 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 em `srcs`, a regra dependerá automaticamente dele. Se os `outs` da regra nomeada forem 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 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` 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 distintas 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 no destino binário.
`copts`	Lista de strings. O padrão é `[]`. Adicione essas opções ao comando de compilação do C++. Sujeito à substituição de "Make variables" e à tokenização de shell Bourne. Cada string nesse atributo é adicionada à `COPTS` na ordem especificada antes de compilar o destino binário. As sinalizações entram em vigor apenas para compilar esse destino, e não as dependências dele. Portanto, tenha cuidado com arquivos de cabeçalho incluídos em outros lugares. Todos os caminhos precisam ser relativos ao espaço de trabalho, não ao pacote atual. Se o pacote declarar o recurso `no_copts_tokenization`, a tokenização de shell Bourne se aplicará apenas a strings que consistam 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 de 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, bem como a todas as regras que dependem dele. Tenha muito cuidado, já que isso pode ter efeitos muito maiores. 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 sinalizações 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, já que isso pode ter efeitos mais amplos. Em caso de dúvida, adicione sinalizações "-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 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 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 de Malloc, prefira `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 à substituição da variável"Make", à tokenização do shell Bourne e à expansão de rótulos. Cada string nesse atributo é adicionada a `LINKOPTS` antes de vincular o destino binário. Cada elemento dessa lista que não começa com `$` ou `-` é considerado o rótulo de um destino em `deps`. A lista de arquivos gerados por 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 `cc_binary` e desativada para o restante. Se ativada e for um binário ou teste, essa opção instrui a ferramenta de compilação a vincular em `.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 aquelas que não têm uma biblioteca estática. O executável resultante ainda será vinculado de maneira dinâmica, ou seja, será apenas quase estático. Existem três maneiras diferentes de vincular um executável: STATIC com recurso full_static_link, em que tudo é vinculado estaticamente, por exemplo, "`gcc -static foo.o libbar.a libbaz.a -lm`". Para ativar esse modo, especifique `fully_static_link` no atributo `features`. STATIC, em que todas as bibliotecas do usuário são vinculadas estaticamente (se uma versão estática estiver disponível), mas em que 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`". 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`". 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 somente 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 a criação de bibliotecas dinâmicas. Se for `linkstatic=False`, a ferramenta de criação 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 de 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 aos dependentes.
`malloc`	Rótulo; o padrão é `"@bazel_tools//tools/cpp:malloc"` Substitui a dependência padrão em Malloc. Por padrão, os binários C++ são vinculados a `//tools/cpp:malloc`, que é uma biblioteca vazia. Portanto, 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 não C++, essa opção não terá efeito. O valor desse atributo será ignorado se `linkshared=True` for 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 valores especificados explicitamente no atributo copts da regra) será removido de `COPTS` para fins de compilação da regra. Esse atributo raramente será necessário.
`stamp`	Número inteiro. O padrão é `0`. Define se as informações da versão serão codificadas no binário. Valores possíveis: `stamp = 1`: sempre inclui as informações do build no binário, mesmo em builds `--nostamp`. Evite essa configuração, já que ela possivelmente elimina o armazenamento em cache remoto do binário e qualquer ação downstream que dependa dele. `stamp = 0`: sempre substitui as informações do build por valores constantes. Isso fornece um bom armazenamento em cache dos resultados da compilação. `stamp = -1`: a incorporação de informações do 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. Ela pode ser usada para exportar símbolos durante a vinculação de uma biblioteca compartilhada.

cc_toolchain

Exibir 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 que as ações C++ sejam executadas. Isso é feito por atributos como all_files, compiler_files, linker_files ou outros atributos que terminam com _files. Geralmente, eles são grupos de arquivos que contêm todos os arquivos necessários.
Geração de linhas de comando corretas para ações C++. Isso é feito usando o provedor CcToolchainConfigInfo (detalhes abaixo).

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

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`	Label, obrigatório Coleção de todos os artefatos cc_Dataset. Esses artefatos serão adicionados como entradas para todas as ações relacionadas a regras_cc (exceto as ações que usam conjuntos mais precisos de artefatos dos atributos abaixo). O Bazel supõe que `all_files` é um superconjunto de todos os outros atributos que fornecem artefatos. Por exemplo, a compilação de linkstamp precisa de arquivos de compilação e vinculação, por isso ela 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_Dataset necessários para ações de arquivamento.
`as_files`	Rótulo; o padrão é `None` Coleção de todos os artefatos cc_Dataset necessários para ações de montagem.
`compiler_files`	Label, 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 caso haja suporte para a descoberta de entrada (atualmente apenas 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`	Label, obrigatório Coleção de todos os artefatos cc_Dataset necessários para ações dwp.
`dynamic_runtime_lib`	Rótulo; o padrão é `None` Artefato de biblioteca dinâmica para a biblioteca de ambiente de execução C++ (por exemplo, libstdc++.so). Ele será usado quando o recurso "static_link_cpp_runtimes" estiver ativado e estivermos vinculando dependências dinamicamente.
`exec_transition_for_inputs`	Booleano. O padrão é `True`. Defina como "True" para criar todas as entradas de arquivo para cc_Dataset para a plataforma exec, em vez de ter nenhuma transição (ou seja, plataforma de destino por 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`	Label, obrigatório Coleção de todos os artefatos cc_Dataset necessários para ações de vinculação.
`module_map`	Rótulo; o padrão é `None` Artefato de mapa de módulo a ser usado para builds modulares.
`objcopy_files`	Label, obrigatório Coleção de todos os artefatos cc_Dataset necessários para ações 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). Isso será usado quando o recurso "static_link_cpp_runtimes" estiver ativado e estivermos vinculando dependências estaticamente.
`strip_files`	Label, 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" for compatível com ações de análise de cabeçalho.
`supports_param_files`	Booleano. O padrão é `True`. Defina como "True" quando "cc_dataset" for compatível com o uso de arquivos de parâmetros para ações de vinculação.
`toolchain_config`	Label, obrigatório A etiqueta da regra que fornece `cc_toolchain_config_info`.
`toolchain_identifier`	String; não configurável; o padrão é `""` O identificador usado para corresponder este cc_Dataset com o crosstool_config.Dataset correspondente. Até que o problema No 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

Exibir 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 conjuntos de ferramentas C++.

Essa regra é responsável por:

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

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

Argumentos

Atributos

name

Nome, obrigatório

Um nome exclusivo para o destino.

toolchains

Dicionário mapeando strings para rótulos; não configuráveis; obrigatório

Um mapa das strings "<cpu>" ou "<cpu>|<compiler>" para um rótulo cc_toolchain. "<cpu>" será usada quando apenas --cpu for transmitido para o Bazel, e "<cpu>|<compiler>" será usado quando --cpu e --compiler forem 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",
            },
          )