Para conferir a documentação da versão estável, use o menu suspenso "Documentos com controle de versão". A visualização padrão reflete a versão mais recente em HEAD.

Esta página foi traduzida pela API Cloud Translation.

Regras C / C++

Informar um problema Ver código

Regras

cc_binary
cc_import (em inglês)
cc_library
cc_proto_library (em inglês)
cc_shared_library (em inglês)
fdo_prefetch_hints .
fdo_profile
propeller_optimize
cc_test
cc_toolchain
cc_toolchain_suite

cc_binário

Ver 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, 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ícita

name.stripped (criado apenas se solicitado explicitamente): uma versão removida do binário. strip -g é executado no binário para remover os símbolos de depuração. Outras opções de faixa 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 Fission 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`	`Name; required` Um nome exclusivo para este destino.
`deps`	`List of labels; optional` A lista de outras bibliotecas a serem vinculadas à segmentação binária. Podem ser destinos `cc_library` ou `objc_library`.
`srcs`	`List of labels; optional` A lista de arquivos C e C++ processados para criar o destino. 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 gerados: se um arquivo nomeado estiver no `outs` de alguma outra regra, essa regra dependerá automaticamente dessa outra regra. Um arquivo `.h` não será compilado, mas estará disponível para inclusão por fontes nesta regra. Os arquivos `.cc` e `.h` podem incluir diretamente os cabeçalhos listados nessas `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` dos `cc_library()`s referenciados. O estilo recomendado é que os cabeçalhos associados a uma biblioteca sejam listados no atributo `hdrs` dessa biblioteca e os cabeçalhos restantes associados às origens desta regra a serem 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`, essa regra dependerá dela. 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. `srcs` tipos de arquivo 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 controle de versão ou sem controle de versão: `.so`, `.so.version` Arquivo de objeto: `.o`, `.pic.o` ...e qualquer regra que produza esses arquivos. Diferentes extensões indicam diferentes linguagens de programação de acordo com a convenção do GCC.
`additional_linker_inputs`	`List of labels; optional` Transmita esses arquivos para o comando do vinculador C++. Por exemplo, arquivos compilados do Windows .res podem ser fornecidos aqui para serem incorporados ao destino binário.
`copts`	`List of strings; optional` Adicione essas opções ao comando de compilação C++. Sujeito à substituição da "variável variável" e à tokenização do shell do Bourne. Cada string nesse atributo é adicionada à ordem especificada em `COPTS` antes da compilação do destino binário. As sinalizações só entram em vigor para compilar esse destino, não as dependências dele. Por isso, tenha cuidado com os arquivos principais incluídos em outros lugares. Todos os caminhos precisam estar relacionados ao espaço de trabalho, e não ao pacote atual. Se o pacote declarar o recurso `no_copts_tokenization`, a tokenização do shell do Bourne será aplicada apenas a strings que consistem em uma única variável "Make".
`defines`	`List of strings; optional` Lista de definições a serem adicionadas à linha de compilação. Sujeito à substituição da variável"Make" e à tokenização do shell do Bourne. Cada string, que precisa consistir em um único token de shell Bourne, é precedida por `-D` e adicionada à linha de comando de compilação dessa meta, bem como a todas as regras que dependem dela. Tenha muito cuidado, já que isso pode ter efeitos de longo alcance. Em caso de dúvida, adicione valores definidos a `local_defines`.
`includes`	`List of strings; optional` 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 dos 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 de que depende. Tenha muito cuidado, já que isso pode ter efeitos abrangentes. Em caso de dúvida, adicione as 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 for colocada em sandbox (o padrão).
`linkopts`	`List of strings; optional` Adicione essas sinalizações ao comando do vinculador C++. Sujeito à 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á relatado se o rótulo for inválido ou não for declarado em `deps`.
`linkshared`	`Boolean; optional; nonconfigurable; default is False` Crie uma biblioteca compartilhada. Para ativar esse atributo, inclua `linkshared=True` na sua regra. Por padrão, essa opção fica desativada. A presença dessa sinalização significa que a vinculação ocorre com a sinalização `-shared` para `gcc`, e a biblioteca compartilhada resultante é adequada para carregar, por exemplo, em um programa Java. No entanto, para fins de compilação, ele nunca será vinculado ao binário dependente, já que as bibliotecas compartilhadas criadas com uma regra cc_binary são carregadas manualmente apenas por outros programas. Portanto, ela não deve ser considerada uma alternativa à regra cc_library. Para fins de escalonabilidade, recomendamos evitar essa abordagem e simplesmente deixar que `java_library` dependa das regras `cc_library`. Se você especificar `linkopts=['-static']` e `linkshared=True`, receberá uma única unidade autossuficiente. Se você especificar `linkstatic=True` e `linkshared=True`, receberá uma única unidade predominantemente independente.
`linkstatic`	`Boolean; optional; default is True` Para `cc_binary` e `cc_test`: vincule o binário no modo estático. Para `cc_library.linkstatic`: veja abaixo. Por padrão, essa opção está ativada para `cc_binary` e desativada para o restante. Se ativada e for um binário ou teste, essa opção solicitará que a ferramenta de compilação seja vinculada a `.a` em vez de `.so` para bibliotecas de usuários sempre que possível. Algumas bibliotecas do sistema ainda podem ser vinculadas dinamicamente, assim como bibliotecas para as quais não há biblioteca estática. Portanto, o executável resultante ainda será vinculado de maneira dinâmica e, portanto, somente principalmente estático. Existem 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`. STATIC, em que todas as bibliotecas de usuário são vinculadas estaticamente (se uma versão estática estiver disponível), mas em que bibliotecas de sistema (exceto bibliotecas de tempo de execução C/C++) são vinculadas dinamicamente, por exemplo, "`gcc foo.o libfoo.a libbaz.a -lm`". Esse modo é ativado especificando `linkstatic=True`. DINÂMICO, 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 a vinculação estática é permitida. Portanto, nenhuma `.so` será produzida. 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 build vai criar symlinks para bibliotecas compartilhadas dependentes na área `*.runfiles`.
`local_defines`	`List of strings; optional` Lista de definições a serem adicionadas à linha de compilação. Sujeito à substituição da variável"Make" e à tokenização do shell do 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`	`Label; optional; default is @bazel_tools//tools/cpp:malloc` Modifica a dependência padrão no malloc. Por padrão, os binários C++ são vinculados ao `//tools/cpp:malloc`, que é uma biblioteca vazia. Portanto, o binário acaba usando o malloc libc. 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; optional` Remova as opções correspondentes do comando de compilação em C++. Sujeito à substituição da variável"Make". O valor desse atributo é interpretado como uma expressão regular. Qualquer `COPTS` preexistente que corresponda a essa expressão regular (incluindo valores explicitamente especificados no atributo copts da regra) será removido de `COPTS` para compilar essa regra. Esse atributo raramente é necessário.
`stamp`	`Integer; optional; default is -1` Se deve codificar informações de criação no binário. Valores possíveis: `stamp = 1`: sempre carimba as informações do build no binário, mesmo em builds `--nostamp` (link em inglês). Essa configuração precisa ser evitada, já que ela pode eliminar o armazenamento em cache remoto do binário e qualquer ação downstream que dependa dele. `stamp = 0`: sempre substitua as informações de build por valores constantes. Isso proporciona um bom armazenamento de resultados em cache. `stamp = -1`: a incorporação de informações do build é controlada pela sinalização `--[no]stamp`. Os binários carimbados não são recriados, a menos que as dependências mudem.
`win_def_file`	`Label; optional` O arquivo DEF do Windows a ser passado para o vinculador. Esse atributo só deve ser usado quando o Windows é a plataforma de destino. Ele pode ser usado para exportar símbolos durante a vinculação de uma biblioteca compartilhada.

importação_cc

Ver 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. Como vincular uma biblioteca estática

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

2. Como vincular uma biblioteca compartilhada (Unix)

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

3. 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 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. Como vincular a uma biblioteca estática ou compartilhada
No Unix:

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

# 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 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`	`Name; required` Um nome exclusivo para este destino.
`deps`	`List of labels; optional` A lista de outras bibliotecas de que o destino depende. Veja comentários gerais sobre `deps` em Atributos típicos definidos pela maioria das regras de compilação.
`hdrs`	`List of labels; optional` A lista de arquivos principais publicados por essa biblioteca pré-compilada para inclusão direta pelas origens nas regras dependentes.
`alwayslink`	`Boolean; optional; default is False` Se for 1, qualquer binário que dependa (direta ou indiretamente) dessa biblioteca pré-compilada do 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 será útil se seu código não for explicitamente chamado por código no binário, por exemplo, se ele for registrado para receber algum retorno de chamada fornecido por algum serviço. Se o Alwayslink não funcionar com o VS 2017 no Windows devido a um problema conhecido, faça upgrade do seu VS 2017 para a versão mais recente.
`interface_library`	`Label; optional` Uma única biblioteca de interface para vincular a biblioteca compartilhada. Tipos de arquivos permitidos: `.ifso`, `.tbd`, `.lib`, `.so` ou `.dylib`
`shared_library`	`Label; optional` 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`	`Label; optional` Uma única biblioteca estática pré-compilada. Tipos de arquivos permitidos: `.a`, `.pic.a` ou `.lib`
`system_provided`	`Boolean; optional; default is False` Se for 1, indica que a biblioteca compartilhada exigida no tempo de execução é fornecida pelo sistema. Nesse caso, `interface_library` precisa ser especificado e `shared_library` precisa estar vazio.

biblioteca cc

Ver origem da regra

cc_library(name, deps, srcs, data, hdrs, 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 de cabeçalho usados na compilação precisam ser declarados nas regras hdrs ou srcs de cc_*. Isso é obrigatório.

Para regras cc_library, os cabeçalhos em hdrs compreendem a interface pública 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 em 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 inserir um cabeçalho em hdrs ou srcs, pergunte se quer que os consumidores dessa biblioteca possam incluí-la diretamente. Essa é quase 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 e, portanto, também não têm um atributo hdrs. Todos os cabeçalhos que pertencem ao binário ou ao teste precisam ser listados diretamente no 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 pode incluir foo.h e bar.h diretamente, mas não baz.h.

Incluindo arquivo	Inclusões permitidas
foo.h	bar.h
foo.cc	foo.h bar.h
bar.h	bar-impl.h baz.h
bar-impl.h.	bar.h baz.h
bar.cc	bar.h bar-impl.h baz.h
Baz.h	baz-impl.h
baz-impl.h	Baz.h
baz.cc	baz.h baz-impl.h

As regras de verificação de inclusão 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 de cabeçalho em 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, é preciso adicionar baz 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 ser 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`	`Name; required` Um nome exclusivo para este destino.
`deps`	`List of labels; optional` A lista de outras bibliotecas a serem vinculadas à segmentação binária. Podem ser destinos `cc_library` ou `objc_library`.
`srcs`	`List of labels; optional` A lista de arquivos C e C++ processados para criar o destino. 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 gerados: se um arquivo nomeado estiver no `outs` de alguma outra regra, essa regra dependerá automaticamente dessa outra regra. Um arquivo `.h` não será compilado, mas estará disponível para inclusão por fontes nesta regra. Os arquivos `.cc` e `.h` podem incluir diretamente os cabeçalhos listados nessas `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` dos `cc_library()`s referenciados. O estilo recomendado é que os cabeçalhos associados a uma biblioteca sejam listados no atributo `hdrs` dessa biblioteca e os cabeçalhos restantes associados às origens desta regra a serem 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`, essa regra dependerá dela. 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. `srcs` tipos de arquivo 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 controle de versão ou sem controle de versão: `.so`, `.so.version` Arquivo de objeto: `.o`, `.pic.o` ...e qualquer regra que produza esses arquivos. Diferentes extensões indicam diferentes linguagens de programação de acordo com a convenção do GCC.
`hdrs`	`List of labels; optional` A lista de arquivos de cabeçalho publicados por essa biblioteca para serem incluídos diretamente por origens em regras dependentes. Esse é o local preferencial para declarar arquivos de cabeçalho que descrevem a interface da biblioteca. Esses cabeçalhos serão disponibilizados para inclusão por fontes nesta regra ou em regras dependentes. Os cabeçalhos que não podem ser incluídos por um cliente dessa biblioteca precisam ser listados no atributo `srcs`, mesmo que estejam incluídos em um cabeçalho publicado. Consulte Verificação de inclusão de cabeçalho para uma descrição mais detalhada.
`alwayslink`	`Boolean; optional; default is 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 será útil se seu código não for explicitamente chamado por código no binário, por exemplo, se ele for registrado para receber algum retorno de chamada fornecido por algum serviço. Se o Alwayslink não funcionar com o VS 2017 no Windows devido a um problema conhecido, faça upgrade do seu VS 2017 para a versão mais recente.
`copts`	`List of strings; optional` Adicione essas opções ao comando de compilação C++. Sujeito à substituição da "variável variável" e à tokenização do shell do Bourne. Cada string nesse atributo é adicionada à ordem especificada em `COPTS` antes da compilação do destino binário. As sinalizações só entram em vigor para compilar esse destino, não as dependências dele. Por isso, tenha cuidado com os arquivos principais incluídos em outros lugares. Todos os caminhos precisam estar relacionados ao espaço de trabalho, e não ao pacote atual. Se o pacote declarar o recurso `no_copts_tokenization`, a tokenização do shell do Bourne será aplicada apenas a strings que consistem em uma única variável "Make".
`defines`	`List of strings; optional` Lista de definições a serem adicionadas à linha de compilação. Sujeito à substituição da variável"Make" e à tokenização do shell do Bourne. Cada string, que precisa consistir em um único token de shell Bourne, é precedida por `-D` e adicionada à linha de comando de compilação dessa meta, bem como a todas as regras que dependem dela. Tenha muito cuidado, já que isso pode ter efeitos de longo alcance. Em caso de dúvida, adicione valores definidos a `local_defines`.
`implementation_deps`	`List of labels; optional` A lista de outras bibliotecas das quais a segmentação 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 a compilação dessa biblioteca, e não 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_libraries e protegido pela sinalização `--experimental_cc_implementation_deps`.
`include_prefix`	`String; optional` O prefixo a ser adicionado aos caminhos dos cabeçalhos desta regra. Quando configurados, os cabeçalhos no atributo `hdrs` dessa regra são acessíveis em é o valor desse atributo anexado ao caminho relativo ao repositório. O prefixo no atributo `strip_include_prefix` é removido antes de esse prefixo ser adicionado.
`includes`	`List of strings; optional` 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 dos 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 de que depende. Tenha muito cuidado, já que isso pode ter efeitos abrangentes. Em caso de dúvida, adicione as 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 for colocada em sandbox (o padrão).
`linkopts`	`List of strings; optional` Adicione essas sinalizações ao comando do vinculador C++. Sujeito à 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á relatado se o rótulo for inválido ou não for declarado em `deps`.
`linkstamp`	`Label; optional` Compila e vincula simultaneamente o arquivo de origem C++ especificado ao binário final. Isso é necessário para introduzir informações de carimbo de data/hora em binários. Se compilarmos o arquivo de origem para um arquivo de objeto da maneira habitual, o carimbo de data/hora estará incorreto. Uma compilação de linktamp pode não incluir nenhum conjunto específico de sinalizações de compilador e, portanto, não pode depender de nenhum cabeçalho, opção de compilador ou outra variável de compilação específica. Essa opção só é necessária no pacote `base`.
`linkstatic`	`Boolean; optional; default is False` Para `cc_binary` e `cc_test`: vincule o binário no modo estático. Para `cc_library.linkstatic`: veja abaixo. Por padrão, essa opção está ativada para `cc_binary` e desativada para o restante. Se ativada e for um binário ou teste, essa opção solicitará que a ferramenta de compilação seja vinculada a `.a` em vez de `.so` para bibliotecas de usuários sempre que possível. Algumas bibliotecas do sistema ainda podem ser vinculadas dinamicamente, assim como bibliotecas para as quais não há biblioteca estática. Portanto, o executável resultante ainda será vinculado de maneira dinâmica e, portanto, somente principalmente estático. Existem 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`. STATIC, em que todas as bibliotecas de usuário são vinculadas estaticamente (se uma versão estática estiver disponível), mas em que bibliotecas de sistema (exceto bibliotecas de tempo de execução C/C++) são vinculadas dinamicamente, por exemplo, "`gcc foo.o libfoo.a libbaz.a -lm`". Esse modo é ativado especificando `linkstatic=True`. DINÂMICO, 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 a vinculação estática é permitida. Portanto, nenhuma `.so` será produzida. 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 build vai criar symlinks para bibliotecas compartilhadas dependentes na área `*.runfiles`.
`local_defines`	`List of strings; optional` Lista de definições a serem adicionadas à linha de compilação. Sujeito à substituição da variável"Make" e à tokenização do shell do 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; optional` Remova as opções correspondentes do comando de compilação em C++. Sujeito à substituição da variável"Make". O valor desse atributo é interpretado como uma expressão regular. Qualquer `COPTS` preexistente que corresponda a essa expressão regular (incluindo valores explicitamente especificados no atributo copts da regra) será removido de `COPTS` para compilar essa regra. Esse atributo raramente é necessário.
`strip_include_prefix`	`String; optional` O prefixo que será removido dos caminhos dos cabeçalhos desta regra. Quando definidos, os cabeçalhos no atributo `hdrs` dessa regra são acessíveis no caminho deles com esse prefixo cortado. Se for um caminho relativo, ele será considerado relativo ao pacote. Se for absoluto, será entendido como um caminho relativo a repositório. O prefixo no atributo `include_prefix` é adicionado depois que esse prefixo é removido.
`textual_hdrs`	`List of labels; optional` A lista de arquivos de cabeçalho publicados por essa biblioteca para serem incluídos textualmente por origens 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`	`Label; optional` O arquivo DEF do Windows a ser passado para o vinculador. Esse atributo só deve ser usado quando o Windows é a plataforma de destino. Ele pode ser usado para exportar símbolos durante a vinculação de uma biblioteca compartilhada.

cc_proto_library

Ver 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

Name; required

Um nome exclusivo para este destino.

deps

List of labels; optional

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

biblioteca compartilhada_cc

Ver origem da regra

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

Ele produz uma biblioteca compartilhada.

Exemplo

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

No exemplo, foo_shared vincula estaticamente foo e baz, sendo esta última 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 de regra cc_shared_library não controla quais símbolos são exportados. Ela só usa o que é considerado exportado para dar erros durante a fase de análise se duas bibliotecas compartilhadas exportam os mesmos destinos.

Cada dependência direta de cc_shared_library é considerada exportada. 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 correspondentes ao exports_filter também são exportados.

Cada cc_library no exemplo aparecerá no máximo em uma cc_shared_library. Se quisermos vincular baz também a bar_shared, precisaremos adicionar tags = ["LINKABLE_MORE_THAN_ONCE"] a baz.

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

Erros

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

Isso acontecerá sempre que você 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 acontece sempre que você cria 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 é interromper a vinculação da biblioteca a uma das dependências cc_shared_library. Ao mesmo tempo, a que ainda está vinculada precisa exportar a biblioteca para que a que não estiver vinculada mantenha a visibilidade dos símbolos. Outra maneira é extrair uma terceira biblioteca que exporte o destino. Uma terceira maneira é marcar o cc_library de culpado com LINKABLE_MORE_THAN_ONCE, mas essa correção precisa ser rara, e você precisa absolutamente 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 no dynamic_deps e não é exportada.

A solução é exportá-la da dependência cc_shared_library ou extrair um terceiro cc_shared_library que a exporta.

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

Se você tem uma biblioteca dinâmica pré-compilada, isso não precisa e não pode ser vinculado estaticamente ao destino cc_shared_library atual que você está criando. Portanto, ele não pertence a deps da 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 exportando um destino que já está sendo exportado por uma das dependências dinâmicas.

Para corrigir isso, remova o destino de deps e apenas confie nele da dependência dinâmica ou verifique se o exports_filter não o detecta.

Argumentos

Atributos
`name`	`Name; required` Um nome exclusivo para este destino.
`deps`	`List of labels; optional` Bibliotecas de nível superior que serão vinculadas incondicionalmente à biblioteca compartilhada depois de serem arquivadas totalmente. Qualquer dependência de biblioteca transitiva dessas dependências diretas será vinculada a essa biblioteca compartilhada, desde que elas ainda não tenham sido vinculadas por um `cc_shared_library` em `dynamic_deps`. Durante a análise, a implementação da regra considerará qualquer destino listado em `deps` como exportado pela biblioteca compartilhada, a fim de gerar 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 precisa cuidar disso por meio de scripts do vinculador ou de 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 uma `cc_shared_library`. Isso pode ser evitado adicionando `"LINKABLE_MORE_THAN_ONCE"` ao `cc_library.tags` ou listando "cc_library" como uma exportação de uma das bibliotecas compartilhadas para que uma das `dynamic_dep` possa ser transformada em uma da outra.
`additional_linker_inputs`	`List of labels; optional` Qualquer arquivo adicional que você queira passar para o vinculador, por exemplo, scripts do vinculador. Você precisa transmitir separadamente todas as sinalizações do vinculador necessárias para que ele esteja ciente desse arquivo. Você pode fazer isso usando o atributo `user_link_flags`.
`dynamic_deps`	`List of labels; optional` Essas são outras dependências `cc_shared_library` de que o destino atual depende. A implementação de `cc_shared_library` usará a lista de `dynamic_deps` (temporariamente, ou seja, também o `dynamic_deps` do `dynamic_deps` do destino atual) para decidir a qual `cc_libraries` no `deps` transitivo não deve ser vinculado porque eles já são fornecidos por um `cc_shared_library` diferente.
`exports_filter`	`List of strings; optional` Esse atributo contém uma lista de destinos que foram exportados pela biblioteca compartilhada atual. Qualquer destino `deps` já foi entendido para ser exportado pela biblioteca compartilhada. Esse atributo deve ser usado para listar qualquer destino que seja exportado pela biblioteca compartilhada, mas que sejam dependências transitivas de `deps`. Observe que esse atributo não está realmente 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, de fato, informar ao vinculador 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; optional` 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 do C++ para Python, o prefixo padrão lib* não é desejado. Nesse caso, você pode usar esse atributo para escolher um nome personalizado.
`user_link_flags`	`List of strings; optional` Outras sinalizações que você queira passar para o vinculador. Por exemplo, para fazer com que o vinculador reconheça um script de vinculador transmitido via 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`	`Label; optional` O arquivo DEF do Windows a ser passado para o vinculador. Esse atributo só deve ser usado quando o Windows é a plataforma de destino. Ele pode ser usado para exportar símbolos durante a vinculação de uma biblioteca compartilhada.

fdo_prefetch_hints

Ver 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

Name; required

Um nome exclusivo para este destino.

profile

Label; optional

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.

perfil_fdo

Ver 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 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`	`Name; required` Um nome exclusivo para este destino.
`absolute_path_profile`	`String; optional` Caminho absoluto para o perfil FDO. O arquivo FDO só pode ter a extensão .afdo.
`profile`	`Label; optional` Marcador do perfil do FDO ou uma regra que o gere. 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 profVM de LLVM, .afdo para perfil AutoFDO, .xfdo para perfil XBinary. O marcador também pode apontar para uma regra fdo_absolute_path_profile.
`proto_profile`	`Label; optional` Rótulo do perfil protobuf.

propulsor_otimizar

Ver 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

Name; required

Um nome exclusivo para este destino.

ld_profile

Label; optional

Rótulo do perfil transmitido à ação do link. Este arquivo tem a extensão .txt.

teste_cc

Ver 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, 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`	`Name; required` Um nome exclusivo para este destino.
`deps`	`List of labels; optional` A lista de outras bibliotecas a serem vinculadas à segmentação binária. Podem ser destinos `cc_library` ou `objc_library`.
`srcs`	`List of labels; optional` A lista de arquivos C e C++ processados para criar o destino. 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 gerados: se um arquivo nomeado estiver no `outs` de alguma outra regra, essa regra dependerá automaticamente dessa outra regra. Um arquivo `.h` não será compilado, mas estará disponível para inclusão por fontes nesta regra. Os arquivos `.cc` e `.h` podem incluir diretamente os cabeçalhos listados nessas `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` dos `cc_library()`s referenciados. O estilo recomendado é que os cabeçalhos associados a uma biblioteca sejam listados no atributo `hdrs` dessa biblioteca e os cabeçalhos restantes associados às origens desta regra a serem 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`, essa regra dependerá dela. 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. `srcs` tipos de arquivo 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 controle de versão ou sem controle de versão: `.so`, `.so.version` Arquivo de objeto: `.o`, `.pic.o` ...e qualquer regra que produza esses arquivos. Diferentes extensões indicam diferentes linguagens de programação de acordo com a convenção do GCC.
`additional_linker_inputs`	`List of labels; optional` Transmita esses arquivos para o comando do vinculador C++. Por exemplo, arquivos compilados do Windows .res podem ser fornecidos aqui para serem incorporados ao destino binário.
`copts`	`List of strings; optional` Adicione essas opções ao comando de compilação C++. Sujeito à substituição da "variável variável" e à tokenização do shell do Bourne. Cada string nesse atributo é adicionada à ordem especificada em `COPTS` antes da compilação do destino binário. As sinalizações só entram em vigor para compilar esse destino, não as dependências dele. Por isso, tenha cuidado com os arquivos principais incluídos em outros lugares. Todos os caminhos precisam estar relacionados ao espaço de trabalho, e não ao pacote atual. Se o pacote declarar o recurso `no_copts_tokenization`, a tokenização do shell do Bourne será aplicada apenas a strings que consistem em uma única variável "Make".
`defines`	`List of strings; optional` Lista de definições a serem adicionadas à linha de compilação. Sujeito à substituição da variável"Make" e à tokenização do shell do Bourne. Cada string, que precisa consistir em um único token de shell Bourne, é precedida por `-D` e adicionada à linha de comando de compilação dessa meta, bem como a todas as regras que dependem dela. Tenha muito cuidado, já que isso pode ter efeitos de longo alcance. Em caso de dúvida, adicione valores definidos a `local_defines`.
`includes`	`List of strings; optional` 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 dos 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 de que depende. Tenha muito cuidado, já que isso pode ter efeitos abrangentes. Em caso de dúvida, adicione as 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 for colocada em sandbox (o padrão).
`linkopts`	`List of strings; optional` Adicione essas sinalizações ao comando do vinculador C++. Sujeito à 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á relatado se o rótulo for inválido ou não for declarado em `deps`.
`linkstatic`	`Boolean; optional; default is False` Para `cc_binary` e `cc_test`: vincule o binário no modo estático. Para `cc_library.linkstatic`: veja abaixo. Por padrão, essa opção está ativada para `cc_binary` e desativada para o restante. Se ativada e for um binário ou teste, essa opção solicitará que a ferramenta de compilação seja vinculada a `.a` em vez de `.so` para bibliotecas de usuários sempre que possível. Algumas bibliotecas do sistema ainda podem ser vinculadas dinamicamente, assim como bibliotecas para as quais não há biblioteca estática. Portanto, o executável resultante ainda será vinculado de maneira dinâmica e, portanto, somente principalmente estático. Existem 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`. STATIC, em que todas as bibliotecas de usuário são vinculadas estaticamente (se uma versão estática estiver disponível), mas em que bibliotecas de sistema (exceto bibliotecas de tempo de execução C/C++) são vinculadas dinamicamente, por exemplo, "`gcc foo.o libfoo.a libbaz.a -lm`". Esse modo é ativado especificando `linkstatic=True`. DINÂMICO, 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 a vinculação estática é permitida. Portanto, nenhuma `.so` será produzida. 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 build vai criar symlinks para bibliotecas compartilhadas dependentes na área `*.runfiles`.
`local_defines`	`List of strings; optional` Lista de definições a serem adicionadas à linha de compilação. Sujeito à substituição da variável"Make" e à tokenização do shell do 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`	`Label; optional; default is @bazel_tools//tools/cpp:malloc` Modifica a dependência padrão no malloc. Por padrão, os binários C++ são vinculados ao `//tools/cpp:malloc`, que é uma biblioteca vazia. Portanto, o binário acaba usando o malloc libc. 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; optional` Remova as opções correspondentes do comando de compilação em C++. Sujeito à substituição da variável"Make". O valor desse atributo é interpretado como uma expressão regular. Qualquer `COPTS` preexistente que corresponda a essa expressão regular (incluindo valores explicitamente especificados no atributo copts da regra) será removido de `COPTS` para compilar essa regra. Esse atributo raramente é necessário.
`stamp`	`Integer; optional; default is 0` Se deve codificar informações de criação no binário. Valores possíveis: `stamp = 1`: sempre carimba as informações do build no binário, mesmo em builds `--nostamp` (link em inglês). Essa configuração precisa ser evitada, já que ela pode eliminar o armazenamento em cache remoto do binário e qualquer ação downstream que dependa dele. `stamp = 0`: sempre substitua as informações de build por valores constantes. Isso proporciona um bom armazenamento de resultados em cache. `stamp = -1`: a incorporação de informações do build é controlada pela sinalização `--[no]stamp`. Os binários carimbados não são recriados, a menos que as dependências mudem.
`win_def_file`	`Label; optional` O arquivo DEF do Windows a ser passado para o vinculador. Esse atributo só deve ser usado quando o Windows é a plataforma de destino. Ele pode ser usado para exportar símbolos durante a vinculação de uma biblioteca compartilhada.

cc_toolchain

Ver origem da regra

cc_toolchain(name, all_files, ar_files, as_files, compatible_with, compiler, compiler_files, compiler_files_without_includes, coverage_files, cpu, 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 em C++.

Essa regra é responsável por:

Coletando 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. Esses são os grupos de arquivos que normalmente agrupam 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 em C++. Veja também esta página para configuração elaborada do conjunto de ferramentas do C++ e documentação de seleção do conjunto de ferramentas.

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

Argumentos

Atributos
`name`	`Name; required` Um nome exclusivo para este destino.
`all_files`	`Label; required` Coleção de todos os artefatos cc_toolchain. Esses artefatos serão adicionados como entradas para todas as ações relacionadas a rules_cc, exceto as que usam conjuntos de artefatos mais precisos dos atributos abaixo. O Bazel considera que `all_files` é um superconjunto de todos os outros atributos que fornecem artefatos (por exemplo, a compilação de linktamp precisa dos arquivos de compilação e de link, por isso é necessário usar `all_files`). Isso é o que `cc_toolchain.files` contém e é usado por todas as regras do Starlark que usam o conjunto de ferramentas do C++.
`ar_files`	`Label; optional` Coleção de todos os artefatos cc_toolchains necessários para ações de arquivamento.
`as_files`	`Label; optional` Coleção de todos os artefatos cc_toolchain necessários para ações de montagem.
`compiler`	`String; optional; nonconfigurable` Obsoleto. Use o atributo `toolchain_identifier`. Ele será um ambiente autônomo depois da migração do CROSSTOOL para o Starlark e será removido em #7075. Quando definido, ele será usado para executar a seleção de crosstool_config.toolchain. Ele terá precedência sobre a opção --cpu Bazel.
`compiler_files`	`Label; required` Coleção de todos os artefatos cc_toolchain necessários para ações de compilação.
`compiler_files_without_includes`	`Label; optional` Coleção de todos os artefatos cc_toolchain necessários para ações de compilação caso a descoberta de entrada seja compatível (atualmente apenas do Google).
`coverage_files`	`Label; optional` Coleção de todos os artefatos cc_toolchain necessários para ações de cobertura. Se não for especificado, todos os arquivos_são usados.
`cpu`	`String; optional; nonconfigurable` Obsoleto. Use o atributo toolchain_identifier. Ele será um ambiente autônomo após a migração do CROSSTOOL para o Starlark e será removido em #7075. Quando definido, ele será usado para executar a seleção de crosstool_config.toolchain. Ele terá precedência sobre a opção --cpu Bazel.
`dwp_files`	`Label; required` Coleção de todos os artefatos cc_toolchain necessários para ações de dwp.
`dynamic_runtime_lib`	`Label; optional` Artefato de biblioteca dinâmica para a biblioteca de tempo de execução C++ (por exemplo, libstdc++.so). Ele será usado quando o recurso "static_link_cpp_runtimes" estiver ativado e estivermos vinculando as dependências dinamicamente.
`exec_transition_for_inputs`	`Boolean; optional; default is True` Defina como "True" para criar todas as entradas de arquivo para cc_toolchain para a plataforma exec, em vez de não fazer a transição (ou seja, plataforma de destino por padrão).
`libc_top`	`Label; optional` Uma coleção de artefatos para libc passados como entradas para compilar/vincular ações.
`linker_files`	`Label; required` Coleção de todos os artefatos cc_toolchains necessários para ações de vinculação.
`module_map`	`Label; optional` Artefato de mapa de módulo a ser usado para versões modulares.
`objcopy_files`	`Label; required` Coleção de todos os artefatos cc_toolchain necessários para ações de objcopy.
`static_runtime_lib`	`Label; optional` Artefato de biblioteca estática para a biblioteca de tempo 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; required` Coleção de todos os artefatos cc_toolchain necessários para ações de remoção.
`supports_header_parsing`	`Boolean; optional; default is False` Definido como verdadeiro quando cc_toolchain oferece suporte a ações de análise do cabeçalho.
`supports_param_files`	`Boolean; optional; default is True` Definido como verdadeiro quando cc_toolchain oferece suporte ao uso de arquivos de parâmetros para ações de vinculação.
`toolchain_config`	`Label; required` O rótulo da regra que fornece `cc_toolchain_config_info`.
`toolchain_identifier`	`String; optional; nonconfigurable` O identificador usado para corresponder este cc_toolchain com o crosstool_config.toolchain 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

Ver origem da regra

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

Representa um conjunto de conjuntos de ferramentas do C++.

Essa regra é responsável por:

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

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

Argumentos

Atributos

name

Name; required

Um nome exclusivo para este destino.

toolchains

Dictionary mapping strings to labels; required; nonconfigurable

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