BazelCon 2024 登録の受け付けを開始しました。

このページは Cloud Translation API によって翻訳されました。

C / C++ ルール

ルール

cc_binary
cc_import
cc_library
cc_proto_library
cc_shared_library
fdo_prefetch_hints
fdo_profile
memprof_profile
propeller_optimize
cc_test
cc_ツールチェーン
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)

暗黙的な出力ターゲット

name.stripped（明示的にリクエストされた場合にのみビルドされる）: 削除されたバージョンのバイナリ。バイナリに対して strip -g が実行され、デバッグシンボルが削除されます。削除オプションを追加するには、コマンドラインで --stripopt=-foo を使用します。この出力は、明示的にリクエストされた場合にのみビルドされます。
name.dwp（明示的にリクエストされた場合にのみビルド）: Fission が有効な場合: リモートでデプロイされたバイナリのデバッグに適したデバッグ情報パッケージファイル。それ以外: 空のファイル。

引数

属性
`name`	名前: 必須このターゲットの一意の名前。
`deps`	ラベルのリスト。デフォルトは `[]` です。バイナリターゲットにリンクする他のライブラリのリスト。これらは、`cc_library` ターゲットまたは `objc_library` ターゲットです。
`srcs`	ラベルのリスト。デフォルトは `[]` です。ターゲットの作成時に処理される C ファイルと C++ ファイルのリスト。これらは、未生成（通常のソースコード）または生成された C/C++ ソースファイルとヘッダーファイルです。 `.cc`、`.c`、`.cpp` のすべてのファイルがコンパイルされます。これらは生成ファイルである可能性があります。名前付きファイルが他のルールの `outs` にある場合、このルールは自動的にその他のルールに依存します。 `.h` ファイルはコンパイルされませんが、このルールのソースによってインクルードできます。`.cc` ファイルと `.h` ファイルの両方で、これらの `srcs` にリストされているヘッダー、または `deps` 引数にリストされているルールの `hdrs` にヘッダーを直接含めることができます。すべての `#include`d ファイルは、このルールの `srcs` 属性、または参照される `cc_library()` の `hdrs` 属性に記述する必要があります。推奨されるスタイルでは、ライブラリに関連付けられたヘッダーをそのライブラリの `hdrs` 属性にリストし、このルールのソースに関連付けられた残りのヘッダーを `srcs` にリストします。詳細については、「ヘッダーの包含チェック」をご覧ください。ルールの名前が `srcs` にある場合、このルールはそのルールに自動的に依存します。指定されたルールの `outs` が C または C++ ソースファイルの場合は、このルールにコンパイルされ、ライブラリファイルの場合はリンクされます。許可される `srcs` ファイル形式: C ソースファイルと C++ ソースファイル: `.c`、`.cc`、`.cpp`、`.cxx`、`.c++`、`.C` C ヘッダーファイルと C++ ヘッダーファイル: `.h`、`.hh`、`.hpp`、`.hxx`、`.inc`、`.inl`、`.H` C プリプロセッサ付きアセンブラ: `.S` アーカイブ: `.a`、`.pic.a` 「常にリンク」ライブラリ: `.lo`、`.pic.lo` 共有ライブラリ（バージョニングありまたはバージョニングなし）: `.so`、`.so.version` オブジェクトファイル: `.o`、`.pic.o` そのファイルを生成するルールも確認できます。拡張子はそれぞれ、gcc の規則に従って異なるプログラミング言語を表します。
`additional_linker_inputs`	ラベルのリスト。デフォルトは `[]` です。各ファイルを C++ リンカーコマンドに渡します。たとえば、コンパイルされた Windows .res ファイルを指定して、バイナリターゲットに埋め込むことができます。
`copts`	文字列のリスト。デフォルトは `[]` です。これらのオプションを C++ コンパイルコマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化の対象となります。この属性の各文字列は、バイナリターゲットをコンパイルする前に、指定された順序で `COPTS` に追加されます。これらのフラグは、このターゲットのコンパイルに対してのみ有効で、その依存関係では有効にならないため、他の場所に含まれているヘッダーファイルには注意してください。すべてのパスは、現在のパッケージではなくワークスペースを基準とした相対パスにする必要があります。パッケージで機能 `no_copts_tokenization` が宣言されている場合、Bourne シェルのトークン化は、単一の「Make」変数で構成される文字列にのみ適用されます。
`defines`	文字列のリスト。デフォルトは `[]` です。コンパイル行に追加する定義のリスト。「Make」変数の置換と Bourne シェルのトークン化の対象となります。各文字列は 1 つの Bourne シェルトークンで構成する必要があり、先頭に `-D` が付加され、このターゲットおよびそのターゲットに依存するすべてのルールのコンパイルコマンドラインに追加されます。影響が広範囲に及ぶ可能性があるため、十分に注意してください。不明な場合は、代わりに `local_defines` に定義値を追加します。
`includes`	文字列のリスト。デフォルトは `[]` です。コンパイル行に追加するインクルードディレクトリのリスト。「変数を作成」の置換が適用されます。各文字列の前に `-isystem` が付加され、`COPTS` に追加されます。COPTS とは異なり、これらのフラグは、このルールと、このルールに依存するすべてのルールに追加されます。（注: コンテナが依存するルールではありません）。広範囲の影響が及ぶ可能性があるため、細心の注意を払ってください。判断に迷う場合は、代わりに「-I」フラグを COPTS に追加してください。ヘッダーは srcs または hdrs に追加する必要があります。追加しないと、コンパイルがサンドボックス化されている場合（デフォルト）、依存関係のあるルールで使用できなくなります。
`link_extra_lib`	ラベル（デフォルトは `"@bazel_tools//tools/cpp:link_extra_lib"`）追加ライブラリのリンクを制御します。デフォルトでは、C++ バイナリは `//tools/cpp:link_extra_lib` に対してリンクされます。これはデフォルトでラベルフラグ `//tools/cpp:link_extra_libs` に依存します。このフラグを設定しない場合、このライブラリはデフォルトで空になります。ラベルフラグを設定すると、弱いシンボルのオーバーライド、共有ライブラリ関数のインターセプタ、特別なランタイムライブラリ（malloc の置換には `malloc` または `--custom_malloc` を優先する）など、オプションの依存関係をリンクできます。この属性を `None` に設定すると、この動作が無効になります。
`linkopts`	文字列のリスト。デフォルトは `[]` です。これらのフラグを C++ リンカーコマンドに追加します。「Make」変数の置換、 Bourne シェルのトークン化、ラベルの展開が適用されます。この属性の各文字列は、バイナリターゲットをリンクする前に `LINKOPTS` に追加されます。このリストで、`$` または `-` で始まらない各要素は、`deps` 内のターゲットのラベルとみなされます。そのターゲットによって生成されたファイルのリストは、リンカーオプションに追加されます。ラベルが無効な場合、または `deps` で宣言されていない場合は、エラーが報告されます。
`linkshared`	ブール値。構成不可。デフォルトは `False` です。共有ライブラリを作成します。この属性を有効にするには、ルールに `linkshared=True` を含めます。デフォルトでは、このオプションはオフになっています。このフラグが存在する場合は、`-shared` フラグを使用して `gcc` にリンクされ、生成される共有ライブラリが Java プログラムなどに読み込むのに適していることを意味します。ただし、ビルド目的では、依存するバイナリにリンクされることはありません。これは、cc_binary ルールでビルドされた共有ライブラリは、他のプログラムによって手動でのみ読み込まれると想定されているためです。したがって、cc_library ルールの代用と見なされるべきではありません。スケーラビリティのため、このアプローチを完全に回避し、代わりに `java_library` を `cc_library` ルールに依存させることをおすすめします。 `linkopts=['-static']` と `linkshared=True` の両方を指定すると、完全に自己完結した単一のユニットが作成されます。`linkstatic=True` と `linkshared=True` の両方を指定すると、1 つの、ほぼ自己完結型のユニットになります。
`linkstatic`	ブール値。デフォルトは `True` です。 `cc_binary` と `cc_test` の場合: 静的モードでバイナリをリンクします。`cc_library.linkstatic` の場合: 以下をご覧ください。このオプションはデフォルトで `cc_binary` でオンになり、それ以外ではオフになります。有効にするとバイナリまたはテストの場合、可能であればユーザーライブラリを `.so` ではなく `.a` でリンクするようビルドツールに指示します。静的ライブラリがないライブラリと同様に、一部のシステムライブラリは引き続き動的にリンクされる場合があります。したがって、生成された実行可能ファイルは依然として動的にリンクされるため、ほとんど静的となります。実行可能ファイルをリンクする方法は 3 つあります。すべてが静的にリンクされる full_static_link 機能を持つ STATIC（例: 「`gcc -static foo.o libbar.a libbaz.a -lm`」）。このモードを有効にするには、`features` 属性で `fully_static_link` を指定します。 STATIC: すべてのユーザーライブラリが静的にリンクされます（静的バージョンが利用可能な場合）。ただし、システムライブラリ（C/C++ ランタイムライブラリを除く）は動的にリンクされます（例: `gcc foo.o libfoo.a libbaz.a -lm`）。このモードは、`linkstatic=True` を指定して有効にします。 DYNAMIC: すべてのライブラリが動的にリンクされます（動的バージョンが利用可能な場合）。例: 「`gcc foo.o libfoo.so libbaz.so -lm`」。このモードを有効にするには、`linkstatic=False` を指定します。 `linkstatic` 属性は、`cc_library()` ルールで使用する場合、意味が異なります。C++ ライブラリの場合、`linkstatic=True` は静的リンクのみが許可されることを示します。そのため、`.so` は生成されません。linkstatic=False で静的ライブラリの作成が妨げられることはありません。この属性は、動的ライブラリの作成を制御することを目的としています。 `linkstatic=False` の場合、ビルドツールは、依存する共有ライブラリへのシンボリックリンクを `*.runfiles` 領域に作成します。
`local_defines`	文字列のリスト。デフォルトは `[]` です。コンパイル行に追加する定義のリスト。 Make 変数の置換と Bourne シェルのトークン化の対象となります。各文字列（単一の Bourne シェルトークンで構成する必要があります）は、先頭に `-D` が付加され、このターゲットのコンパイルコマンドラインに追加されますが、その依存関係には追加されません。
`malloc`	ラベル: デフォルトは `"@bazel_tools//tools/cpp:malloc"` Maloc のデフォルトの依存関係をオーバーライドします。デフォルトでは、C++ バイナリは `//tools/cpp:malloc` にリンクされます。これは空のライブラリであるため、バイナリは最終的に libc malloc を使用します。このラベルは `cc_library` を参照する必要があります。コンパイルが C++ 以外のルールの場合、このオプションは効果がありません。`linkshared=True` が指定されている場合、この属性の値は無視されます。
`nocopts`	文字列。デフォルトは `""` C++ コンパイルコマンドから一致するオプションを削除します。「Make」変数の置換が適用されます。この属性の値は正規表現として解釈されます。この正規表現（ルールの copts 属性で明示的に指定された値を含む）に一致する既存の `COPTS` は、このルールをコンパイルするために `COPTS` から削除されます。この属性が必要になることはほとんどありません。
`stamp`	整数。デフォルトは `-1` ビルド情報をバイナリにエンコードするかどうか。有効な値は次のとおりです。 `stamp = 1`: `--nostamp` ビルドでも、常にビルド情報をバイナリにスタンプします。バイナリとそれに依存するダウンストリームアクションのリモートキャッシュが破棄される可能性があるため、この設定は避けるべきです。 `stamp = 0`: ビルド情報を常に定数値に置き換えます。これにより、ビルド結果のキャッシュが適切に保存されます。 `stamp = -1`: ビルド情報の埋め込みは `--[no]stamp` フラグで制御されます。スタンプされたバイナリは、依存関係が変更されない限り再ビルドされません。
`win_def_file`	ラベル（デフォルトは `None`）リンカーに渡される Windows DEF ファイル。この属性は、ターゲットプラットフォームが Windows の場合にのみ使用してください。共有ライブラリのリンク中にシンボルをエクスポートするために使用できます。

cc_import

ルールソースを表示

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)

cc_import ルールを使用すると、事前コンパイル済みの C/C++ ライブラリをインポートできます。

一般的なユースケースは次のとおりです。
1. 静的ライブラリのリンク

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. 共有ライブラリのリンク（Unix）

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

3. 共有ライブラリとインターフェースライブラリのリンク（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. 共有ライブラリを 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. 静的ライブラリまたは共有ライブラリ
へのリンク 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,
)

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 は include 属性をサポートしています。次に例を示します。

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

引数

属性
`name`	名前: 必須このターゲットの名前。
`deps`	ラベルのリスト。デフォルトは `[]` です。ターゲットが依存する他のライブラリのリスト。`deps` に関する一般的なコメントについては、ほとんどのビルドルールで定義される一般的な属性をご覧ください。
`hdrs`	ラベルのリスト。デフォルトは `[]` です。このプリコンパイルされたライブラリによってパブリッシュされ、依存ルールのソースによって直接インクルードされるヘッダーファイルのリスト。
`alwayslink`	ブール値。デフォルトは `False` です。 1 の場合、この C++ のプリコンパイルされたライブラリに（直接的または間接的に）依存するバイナリは、静的ライブラリにアーカイブされているすべてのオブジェクトファイルにリンクします。これには、バイナリによって参照されるシンボルが含まれていないファイルも含まれます。これは、コードがバイナリ内のコードによって明示的に呼び出されない場合（コードがサービスから提供されるコールバックを受け取るように登録されている場合など）に便利です。既知の問題が原因で、Alwayslink が Windows 上の VS 2017 で機能しない場合は、VS 2017 を最新バージョンにアップグレードしてください。
`interface_library`	ラベル: デフォルトは `None` 共有ライブラリをリンクするための単一のインターフェースライブラリ。許可されるファイル形式: `.ifso`、`.tbd`、`.lib`、`.so`、`.dylib`
`shared_library`	ラベル: デフォルトは `None` 単一のプリコンパイル済み共有ライブラリ。Bazel は、実行時に依存するバイナリで使用できるようにします。許可されるファイル形式: `.so`、`.dll`、または `.dylib`
`static_library`	ラベル（デフォルトは `None`）プリコンパイルされた単一の静的ライブラリ。使用できるファイル形式: `.a`、 `.pic.a`、または `.lib`
`system_provided`	ブール値。デフォルトは `False` です。 1 の場合、実行時に必要な共有ライブラリがシステムによって提供されることを示します。この場合は、`interface_library` を指定し、`shared_library` は空にする必要があります。

cc_library

ルールソースを表示

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)

ヘッダー包含チェック

ビルドで使用されるヘッダーファイルはすべて、cc_* ルールの hdrs または srcs で宣言する必要があります。これは適用されます。

cc_library ルールの場合、hdrs のヘッダーはライブラリのパブリックインターフェースを構成し、ライブラリ自体の hdrs と srcs のファイルの両方から、および deps にライブラリを一覧表示する cc_* ルールの hdrs と srcs のファイルの両方から直接含めることができます。srcs のヘッダーは、ライブラリ自体の hdrs と srcs のファイルからのみ直接含める必要があります。ヘッダーを hdrs と srcs のどちらに挿入するかを決定するときは、このライブラリのコンシューマがヘッダーを直接インクルードできるようにするかどうかを尋ねる必要があります。これは、プログラミング言語の public と private の可視性に関する決定とほぼ同じです。

cc_binary ルールと cc_test ルールにはエクスポートされたインターフェースがないため、hdrs 属性もありません。バイナリまたはテストに直接関連するすべてのヘッダーを srcs にリストする必要があります。

これらのルールを説明するために、次の例をご覧ください。

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"],
)

この例で許可される直接包含を次の表に示します。たとえば、foo.cc には foo.h と bar.h を直接含めることができますが、baz.h を含めることはできません。

ファイルを追加しています	許可される掲載情報
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

包含チェックルールは、直接包含にのみ適用されます。上記の例では、foo.cc に bar.h を含めることができ、さらに baz.h を含めることができます。さらに、baz-impl.h を含めることができます。技術的には、.cc ファイルのコンパイルでは、hdrs または srcs 内のヘッダーファイルを推移的 deps クロージャ内の cc_library に推移的に組み込むことができます。この場合、コンパイラは foo.cc のコンパイル時に baz.h と baz-impl.h を読み取ることができますが、foo.cc に #include "baz.h" を含めることはできません。これを許可するには、baz を foo の deps に追加する必要があります。

Bazel は、ツールチェーンのサポートに依存して包含チェックルールを適用します。layering_check 機能は、ツールチェーンでサポートされており、--features=layering_check コマンドラインフラグや package 関数の features パラメータなどを使用して明示的にリクエストする必要があります。Bazel が提供する toolchain は、Unix と macOS で clang を使用する場合にのみ、この機能をサポートしています。

引数

属性
`name`	名前（必須）このターゲットの一意の名前。
`deps`	ラベルのリスト。デフォルトは `[]` です。バイナリターゲットにリンクする他のライブラリのリスト。 `cc_library` または `objc_library` のターゲットを指定できます。
`srcs`	ラベルのリスト。デフォルトは `[]` です。ターゲットの作成時に処理される C ファイルと C++ ファイルのリスト。これらは、未生成（通常のソースコード）または生成された C/C++ ソースファイルとヘッダーファイルです。 `.cc`、`.c`、`.cpp` のすべてのファイルがコンパイルされます。これらは生成ファイルである可能性があります。名前付きファイルが他のルールの `outs` にある場合、このルールは自動的にその他のルールに依存します。 `.h` ファイルはコンパイルされませんが、このルールのソースによってインクルードできます。`.cc` ファイルと `.h` ファイルの両方で、これらの `srcs` にリストされているヘッダー、または `deps` 引数にリストされているルールの `hdrs` にヘッダーを直接含めることができます。すべての `#include`d ファイルは、このルールの `srcs` 属性、または参照される `cc_library()` の `hdrs` 属性に記述する必要があります。推奨されるスタイルは、ライブラリに関連付けられているヘッダーをライブラリの `hdrs` 属性にリストし、このルールのソースに関連付けられた残りのヘッダーを `srcs` にリストすることです。詳細については、「ヘッダーの包含チェック」をご覧ください。ルールの名前が `srcs` にある場合、このルールはそのルールに自動的に依存します。名前付きルールの `outs` が C または C++ ソースファイルの場合、このルールにコンパイルされます。ライブラリファイルの場合は、リンクされます。許可される `srcs` ファイル形式: C ソースファイルと C++ ソースファイル: `.c`、`.cc`、`.cpp`、`.cxx`、`.c++`、`.C` C ヘッダーファイルと C++ ヘッダーファイル: `.h`、`.hh`、`.hpp`、`.hxx`、`.inc`、`.inl`、`.H` C プリプロセッサ付きアセンブラ: `.S` アーカイブ: `.a`、`.pic.a` 「常にリンク」ライブラリ: `.lo`、`.pic.lo` 共有ライブラリ（バージョニングありまたはバージョニングなし）: `.so`、`.so.version` オブジェクトファイル: `.o`、`.pic.o` それらのファイルを生成するルールも確認できます。拡張子が異なると、gcc の規則に従って異なるプログラミング言語が示されます。
`hdrs`	ラベルのリスト。デフォルトは `[]` です。このライブラリによって公開され、依存関係のあるルールのソースによって直接組み込まれるヘッダーファイルのリスト。これは、ライブラリのインターフェースを記述するヘッダーファイルを宣言する場所として強く推奨されます。これらのヘッダーは、このルールまたは依存ルールのソースによってインクルードできるようになります。このライブラリのクライアントが含める必要のないヘッダーは、公開済みのヘッダーに含まれている場合でも、代わりに `srcs` 属性に含める必要があります。詳細については、「ヘッダーの包含チェック」をご覧ください。
`additional_compiler_inputs`	ラベルのリスト。デフォルトは `[]` です。コンパイラのコマンドラインに渡す必要がある追加のファイル（サニタイザーの無視リストなど）。ここで指定したファイルは、$(location) 関数で copt で使用できます。
`additional_linker_inputs`	ラベルのリスト。デフォルトは `[]` です。これらのファイルを C++ リンカーコマンドに渡します。たとえば、コンパイル済みの Windows .res ファイルをここで提供して、バイナリターゲットに埋め込むことができます。
`alwayslink`	ブール値。デフォルトは `False` です。 1 の場合、この C++ ライブラリに（直接または間接的に）依存するバイナリは、`srcs` にリストされているファイルのすべてのオブジェクトファイルをリンクします。バイナリによって参照されるシンボルが含まれていない場合でも同様です。これは、バイナリ内のコードによってコードが明示的に呼び出されていない場合（たとえば、なんらかのサービスから提供されるコールバックを受け取るようにコードが登録されている場合）に役立ちます。既知の問題が原因で、Alwayslink が Windows 上の VS 2017 で機能しない場合は、VS 2017 を最新バージョンにアップグレードしてください。
`copts`	文字列のリスト。デフォルトは `[]` です。これらのオプションを C++ コンパイルコマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化が適用されます。この属性の各文字列は、バイナリターゲットをコンパイルする前に、指定された順序で `COPTS` に追加されます。このフラグは、このターゲットのコンパイルにのみ適用され、その依存関係には適用されません。そのため、他の場所に含まれているヘッダーファイルには注意してください。すべてのパスは、現在のパッケージではなくワークスペースからの相対パスにする必要があります。パッケージが機能 `no_copts_tokenization` を宣言している場合、Bourne シェルのトークン化は、単一の「Make」変数で構成される文字列にのみ適用されます。
`defines`	文字列のリスト。デフォルトは `[]` です。コンパイル行に追加する定義のリスト。Make 変数の置換と Bourne シェルのトークン化の対象となります。各文字列（1 つの Bourne シェルトークンで構成されている必要があります）の前に `-D` が追加され、このターゲットへのコンパイルコマンドライン、およびそれに依存するすべてのルールに追加されます。影響が広範囲に及ぶ可能性があるため、十分に注意してください。判断に迷う場合は、代わりに `local_defines` に値の定義を追加してください。
`implementation_deps`	ラベルのリスト。デフォルトは `[]` です。ライブラリのターゲットが依存する他のライブラリのリスト。`deps` とは異なり、これらのライブラリのヘッダーとインクルードパス（およびそのすべての推移的依存関係）は、このライブラリのコンパイルにのみ使用され、ライブラリに依存するライブラリには使用されません。`implementation_deps` で指定されたライブラリは、このライブラリに依存するバイナリターゲットでも引き続きリンクされます。現時点では、使用は cc_libraries に限定され、`--experimental_cc_implementation_deps` フラグによって保護されています。
`include_prefix`	文字列。デフォルトは `""` です。このルールのヘッダーのパスに追加する接頭辞。設定すると、このルールの `hdrs` 属性のヘッダーに、リポジトリ相対パスの前にこの属性の値が付加されたパスでアクセスできます。 `strip_include_prefix` 属性の接頭辞は、この接頭辞が追加される前に削除されます。
`includes`	文字列のリスト。デフォルトは `[]` です。コンパイル行に追加するインクルードディレクトリのリスト。「変数を作成」による置換が適用されます。各文字列の前に `-isystem` が付加され、`COPTS` に追加されます。COPTS とは異なり、これらのフラグは、このルールと、このルールに依存するすべてのルールに追加されます。（注: 依存するルールではありません）。影響が広範囲に及ぶ可能性があるため、十分に注意してください。不明な場合は、代わりに COPTS に「-I」フラグを追加します。ヘッダーは srcs または hdrs に追加する必要があります。追加しない場合、コンパイルがサンドボックス化されるときに、依存するルールでヘッダーを使用できません（デフォルト）。
`linkopts`	文字列のリスト。デフォルトは `[]` です。これらのフラグを C++ リンカーコマンドに追加します。「Make」変数の置換、Bourne シェルのトークン化、ラベル展開の対象となります。この属性の各文字列は、バイナリターゲットをリンクする前に `LINKOPTS` に追加されます。このリストで、`$` または `-` で始まらない各要素は、`deps` 内のターゲットのラベルとみなされます。そのターゲットによって生成されたファイルのリストは、リンカーオプションに追加されます。ラベルが無効な場合、または `deps` で宣言されていない場合は、エラーが報告されます。
`linkstamp`	ラベル（デフォルトは `None`）指定された C++ ソースファイルをコンパイルしてリンクし、最終的なバイナリに同時に作成します。この手法は、タイムスタンプ情報をバイナリに導入するために必要です。通常の方法でソースファイルをオブジェクトファイルにコンパイルすると、タイムスタンプが不正確になります。リンクスタンプのコンパイルには、特定のコンパイラフラグのセットを含めることはできないため、特定のヘッダー、コンパイラオプション、その他のビルド変数に依存しないでください。このオプションは、`base` パッケージでのみ必要です。
`linkstatic`	ブール値。デフォルトは `False` `cc_binary` と `cc_test` の場合: 静的モードでバイナリをリンクします。`cc_library.linkstatic` については、以下をご覧ください。このオプションはデフォルトで `cc_binary` でオンになり、それ以外ではオフになります。有効にするとバイナリまたはテストの場合、可能であればユーザーライブラリを `.so` ではなく `.a` でリンクするようビルドツールに指示します。静的ライブラリがないライブラリと同様に、一部のシステムライブラリは引き続き動的にリンクされる場合があります。したがって、生成された実行可能ファイルは依然として動的にリンクされるため、ほとんど静的となります。実行可能ファイルをリンクする方法は 3 つあります。すべてのものを静的にリンクできる full_static_link 機能を持つ STATIC（例: 「`gcc -static foo.o libbar.a libbaz.a -lm`」）。このモードを有効にするには、`features` 属性で `fully_static_link` を指定します。 STATIC: すべてのユーザーライブラリが静的にリンクされます（静的バージョンが利用可能な場合）。ただし、システムライブラリ（C/C++ ランタイムライブラリを除く）は動的にリンクされます（例: `gcc foo.o libfoo.a libbaz.a -lm`）。このモードは、`linkstatic=True` を指定して有効にします。 DYNAMIC: すべてのライブラリが動的にリンクされます（動的バージョンが使用可能な場合）。例: `gcc foo.o libfoo.so libbaz.so -lm`。このモードは、`linkstatic=False` を指定して有効にします。 `linkstatic` 属性は、`cc_library()` ルールで使用する場合、別の意味を持ちます。C++ ライブラリの場合、`linkstatic=True` は静的リンクのみが許可されることを示します。そのため、`.so` は生成されません。linkstatic=False で静的ライブラリの作成が妨げられることはありません。この属性は、動的ライブラリの作成を制御するためのものです。 `linkstatic=False` の場合、ビルドツールは、依存する共有ライブラリへのシンボリックリンクを `*.runfiles` 領域に作成します。
`local_defines`	文字列のリスト。デフォルトは `[]` です。コンパイル行に追加する定義のリスト。 Make 変数の置換と Bourne シェルのトークン化の対象となります。各文字列は 1 つの Bourne シェルトークンで構成する必要があり、先頭に `-D` が付加され、このターゲットのコンパイルコマンドラインに追加されますが、依存関係には追加されません。
`nocopts`	文字列。デフォルトは `""` です。 C++ コンパイルコマンドからマッチングオプションを削除します。「Make」変数の置換が適用されます。この属性の値は正規表現として解釈されます。この正規表現に一致する既存の `COPTS`（ルールの copts 属性で明示的に指定された値を含む）は、このルールのコンパイルの目的で `COPTS` から削除されます。この属性が必要になることはほとんどありません。
`strip_include_prefix`	文字列。デフォルトは `""` このルールのヘッダーのパスから削除する接頭辞。設定すると、このルールの `hdrs` 属性のヘッダーには、この接頭辞が削除されたパスでアクセスできます。相対パスの場合は、パッケージ相対パスとして扱われます。絶対パスの場合は、リポジトリ相対パスとみなされます。 `include_prefix` 属性の接頭辞は、この接頭辞が削除された後に追加されます。
`textual_hdrs`	ラベルのリスト。デフォルトは `[]` です。このライブラリによって公開され、依存関係のあるルールのソースによってテキストで含められるヘッダーファイルのリスト。これは、単独でコンパイルできないヘッダーファイルを宣言する場所です。つまり、有効なコードをビルドするには、他のソースファイルで常にテキストとして含める必要があります。
`win_def_file`	ラベル: デフォルトは `None` リンカーに渡される Windows DEF ファイル。この属性は、ターゲットプラットフォームが Windows の場合にのみ使用してください。共有ライブラリのリンク中にシンボルをエクスポートするために使用できます。

cc_proto_library

ルールソースを表示

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 は、.proto ファイルから C++ コードを生成します。

deps は proto_library ルールを指す必要があります。

例:

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

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

proto_library(
    name = "foo_proto",
)

引数

属性

name

名前: 必須

このターゲットの一意の名前。

deps

ラベルのリスト。デフォルトは [] です。

C++ コードを生成する proto_library ルールのリスト。

cc_shared_library

ルールのソースを表示

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

共有ライブラリを生成します。

例

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"],
)

foo_shared の例では、foo と baz が静的にリンクされています。後者は推移的依存関係です。bar は dynamic_dep bar_shared によってすでに動的に提供されているため、リンクされません。

foo_shared は、リンカースクリプト *.lds ファイルを使用して、エクスポートするシンボルを制御します。cc_shared_library ルールのロジックは、エクスポートされるシンボルを制御しません。2 つの共有ライブラリが同じターゲットをエクスポートする場合、分析フェーズでエラーを発生させるために、エクスポートが想定されているもののみを使用します。

cc_shared_library のすべての直接依存関係は、エクスポートされていると見なされます。したがって、Bazel は分析中に、foo が foo_shared によってエクスポートされていると想定します。baz は foo_shared によってエクスポートされるとは想定されません。exports_filter で一致したターゲットもすべてエクスポートされます。

この例のすべての cc_library は、最大で 1 つの cc_shared_library に含まれます。baz を bar_shared にもリンクする場合は、tags = ["LINKABLE_MORE_THAN_ONCE"] を baz に追加する必要があります。

shared_lib_name 属性により、bar_shared によって生成されるファイルの名前は、Linux のデフォルト名 libbar.so ではなく bar.so になります。

エラー

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

これは、同じターゲットをエクスポートする 2 つの異なる cc_shared_library 依存関係を持つターゲットを作成するたびに発生します。この問題を解決するには、いずれかの cc_shared_library 依存関係でライブラリのエクスポートを停止する必要があります。

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

これは、同じターゲットを静的にリンクする 2 つの異なる cc_shared_library 依存関係を持つ新しい cc_shared_library を作成するたびに発生します。エクスポートのエラーに似ています。

これを修正する 1 つの方法は、ライブラリを cc_shared_library 依存関係のいずれかにリンクしないようにすることです。同時に、まだリンクしているライブラリは、ライブラリをエクスポートして、リンクしていないライブラリがシンボルの可視性を維持できるようにする必要があります。もう 1 つの方法は、ターゲットをエクスポートする 3 つ目のライブラリを抽出することです。3 つ目の方法は、問題の cc_library に LINKABLE_MORE_THAN_ONCE のタグを付ける方法ですが、この修正はまれにしか行わず、cc_library を複数回リンクしても安全であることを必ず確認してください。

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

つまり、deps の推移閉包内のライブラリは、cc_shared_library の依存関係のいずれかを経由せずに到達できますが、dynamic_deps の別の cc_shared_library にすでにリンクされており、エクスポートされていません。

解決策は、cc_shared_library 依存関係からエクスポートするか、エクスポートするサードパーティの cc_shared_library を引き出すことです。

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

事前コンパイルされた動的ライブラリがある場合は、現在作成している現在の cc_shared_library ターゲットに静的にリンクする必要はありません。また、リンクすることもできません。したがって、cc_shared_library の deps に属しません。この事前コンパイルされた動的ライブラリが cc_libraries の依存関係である場合、cc_library はそれに直接依存する必要があります。

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

このエラーは、現在のルールで、動的依存関係の 1 つによってすでにエクスポートされているターゲットのエクスポートを要求している場合に表示されます。

これを修正するには、deps からターゲットを削除し、動的依存関係からそのターゲットを利用するか、exports_filter がこのターゲットをキャッチしないようにします。

引数

属性
`name`	名前（必須）このターゲットの一意の名前。
`deps`	ラベルのリスト。デフォルトは `[]` です。完全アーカイブされた後、無条件で共有ライブラリに静的にリンクされるトップレベルライブラリ。これらの直接依存関係の推移的ライブラリ依存関係は、`dynamic_deps` の `cc_shared_library` によってまだリンクされていない限り、この共有ライブラリにリンクされます。分析中、ルールの実装では、複数の `cc_shared_libraries` が同じターゲットをエクスポートしている場合にエラーを出すために、`deps` にリストされているターゲットは共有ライブラリによってエクスポートされていると見なされます。ルールの実装では、共有オブジェクトによってエクスポートされるシンボルをリンカーに通知しません。ユーザーは、リンカースクリプトまたはソースコードの可視性宣言を使用して、この問題に対処する必要があります。また、同じライブラリが複数の `cc_shared_library` に静的にリンクされている場合、実装でエラーがトリガーされます。これは、`"LINKABLE_MORE_THAN_ONCE"` を `cc_library.tags` に追加するか、一方を他方の `dynamic_dep` にできるように、いずれかの共有ライブラリのエクスポートとして「cc_library」をリストすることで回避できます。
`additional_linker_inputs`	ラベルのリスト。デフォルトは `[]` です。リンカースクリプトなど、リンカーに渡す追加のファイル。このファイルを認識するためにリンカーが必要とするリンカーフラグは、個別に渡す必要があります。これは `user_link_flags` 属性で指定できます。
`dynamic_deps`	ラベルのリスト。デフォルトは `[]` です。これらは、現在のターゲットが依存している他の `cc_shared_library` 依存関係です。 `cc_shared_library` 実装は `dynamic_deps` のリスト（推移的、つまり現在のターゲットの `dynamic_deps` の `dynamic_deps`）を使用して、別の `cc_shared_library` によってすでに提供されているため、推移的 `deps` のどの `cc_libraries` をリンクしないかを決定します。
`exports_filter`	文字列のリスト。デフォルトは `[]` です。この属性には、現在の共有ライブラリによってエクスポートされていると宣言されているターゲットのリストが含まれます。ターゲット `deps` は、共有ライブラリによるエクスポートをすでに認識しています。この属性は、共有ライブラリによってエクスポートされるが、`deps` の推移的依存関係であるターゲットをリストするために使用します。この属性は、実際にはターゲットに依存関係エッジを追加しません。依存関係エッジは `deps` によって作成する必要があります。この属性のエントリは単なる文字列です。この属性にターゲットを配置すると、共有ライブラリがそのターゲットからシンボルをエクスポートするという主張と見なされます。`cc_shared_library` ロジックは、エクスポートするシンボルをリンカーに伝える処理を実際に行うわけではありません。次の構文を使用できます。 `//foo:__package__`: foo/BUILD 内の任意のターゲットを考慮 `//foo:__subpackages__`: foo/BUILD 内のターゲット、または foo/ の下の他のパッケージ（foo/bar/BUILD など）に対応します。
`shared_lib_name`	文字列。デフォルトは `""` です。デフォルトでは、cc_shared_library は、ターゲットの名前とプラットフォームに基づいて、共有ライブラリ出力ファイルの名前を使用します。これには、拡張子と接頭辞が含まれます。デフォルト名が不要な場合もあります。たとえば、Python 用の C++ 共有ライブラリを読み込む場合、デフォルトの lib* 接頭辞は多くの場合望ましくない場合があります。そのような場合は、この属性を使用してカスタム名を選択できます。
`user_link_flags`	文字列のリスト。デフォルトは `[]` です。リンカーに渡す追加のフラグ。たとえば、additional_linker_inputs を介して渡されるリンカースクリプトをリンカーが認識できるようにするには、次のようにします。 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`	ラベル（デフォルトは `None`）リンカーに渡される Windows DEF ファイル。この属性は、Windows がターゲットプラットフォームである場合にのみ使用してください。共有ライブラリのリンク中にシンボルをエクスポートするために使用できます。

fdo_prefetch_hints

ルールソースを表示

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

ワークスペースまたは指定された絶対パスにある FDO プリフェッチヒントプロファイルを表します。例:

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

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

引数

属性

name

名前（必須）

このターゲットの名前。

profile

ラベル（デフォルトは None）

ヒントのプロファイルのラベル。ヒントファイルの拡張子は .afdo です。ラベルは fdo_absolute_path_profile ルールを参照することもできます。

fdo_profile

ルールソースを表示

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

ワークスペース内または指定された絶対パスにある FDO プロファイルを表します。例:

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

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

引数

属性
`name`	名前（必須）このターゲットの名前。
`absolute_path_profile`	文字列。デフォルトは `""` です。 FDO プロファイルの絶対パス。FDO ファイルの拡張子は .afdo のみです。
`profile`	ラベル（デフォルトは `None`） FDO プロファイルのラベル、またはそのプロファイルを生成するルール。FDO ファイルの拡張子は、.profraw（インデックスなし LLVM プロファイルの場合）、.profdata（インデックス付き LLVM プロファイルの場合）、.profdata（インデックス付き LLVM プロファイルの場合）、.zip（LLVM profraw プロファイルを保持する場合）、.afdo（AutoFDO プロファイルの場合）、.xfdo（XBinary プロファイルの場合）のいずれかです。ラベルは、fdo_absolute_path_profile ルールを参照することもできます。
`proto_profile`	ラベル（デフォルトは `None`） protobuf プロファイルのラベル。

memprof_profile

ルールのソースを表示

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

ワークスペースまたは指定された絶対パスにある MEMPROF プロファイルを表します。例:

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

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

引数

属性

name

名前（必須）

このターゲットの一意の名前。

absolute_path_profile

文字列。デフォルトは "" です。

MEMPROF プロファイルの絶対パス。ファイルの拡張子は .profdata または .zip のみにできます（zip ファイルには memprof.profdata ファイルが含まれている必要があります）。

profile

ラベル（デフォルトは None）

MEMPROF プロファイルのラベル。プロファイルには、.profdata 拡張子（インデックス付き / シンボル化された memprof プロファイルの場合）または .zip 拡張子（memprof.profdata ファイルを含む zip ファイルの場合）が付いています。ラベルで fdo_exact_path_profile ルールを参照することもできます。

propeller_optimize

ルールのソースを表示

propeller_optimize(name, compatible_with, deprecation, distribs, features, ld_profile, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

ワークスペース内の Propeller 最適化プロファイルを表します。例:

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"
)

引数

属性

name

名前（必須）

このターゲットの一意の名前。

ld_profile

ラベル: デフォルトは None

リンクアクションに渡されるプロフィールのラベル。このファイルの拡張子は .txt です。

cc_test

ルールのソースを表示

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)

引数

属性
`name`	名前: 必須このターゲットの一意の名前。
`deps`	ラベルのリスト。デフォルトは `[]` です。バイナリターゲットにリンクする他のライブラリのリスト。 `cc_library` または `objc_library` のターゲットを指定できます。
`srcs`	ラベルのリスト。デフォルトは `[]` です。ターゲットを作成するために処理される C および C++ ファイルのリスト。これらは、未生成（通常のソースコード）または生成された C/C++ ソースファイルとヘッダーファイルです。 `.cc`、`.c`、`.cpp` のすべてのファイルがコンパイルされます。これらは生成ファイルである可能性があります。名前付きファイルが他のルールの `outs` にある場合、このルールは自動的にその他のルールに依存します。 `.h` ファイルはコンパイルされませんが、このルールのソースによってインクルードできます。`.cc` ファイルと `.h` ファイルの両方で、これらの `srcs` にリストされているヘッダー、または `deps` 引数にリストされているルールの `hdrs` にヘッダーを直接含めることができます。 `#include` されたすべてのファイルは、このルールの `srcs` 属性または参照される `cc_library()` の `hdrs` 属性で指定する必要があります。推奨されるスタイルでは、ライブラリに関連付けられたヘッダーをそのライブラリの `hdrs` 属性にリストし、このルールのソースに関連付けられた残りのヘッダーを `srcs` にリストします。詳しくは、ヘッダーの包含チェックをご覧ください。ルールの名前が `srcs` にある場合、このルールはそのルールに自動的に依存します。指定されたルールの `outs` が C または C++ ソースファイルの場合は、このルールにコンパイルされ、ライブラリファイルの場合はリンクされます。許可される `srcs` ファイル形式: C ソースファイルと C++ ソースファイル: `.c`、`.cc`、`.cpp`、`.cxx`、`.c++`、`.C` C ヘッダーファイルと C++ ヘッダーファイル: `.h`、`.hh`、`.hpp`、`.hxx`、`.inc`、`.inl`、`.H` C プリプロセッサ付きアセンブラ: `.S` アーカイブ: `.a`、`.pic.a` 「常にリンク」ライブラリ: `.lo`、`.pic.lo` 共有ライブラリ（バージョニングありまたはバージョニングなし）: `.so`、`.so.version` オブジェクトファイル: `.o`、`.pic.o` および、それらのファイルを生成するルール。拡張子はそれぞれ、gcc の規則に従って異なるプログラミング言語を表します。
`additional_linker_inputs`	ラベルのリスト。デフォルトは `[]` です。これらのファイルを C++ リンカーコマンドに渡します。たとえば、コンパイルされた Windows .res ファイルを指定して、バイナリターゲットに埋め込むことができます。
`copts`	文字列のリスト。デフォルトは `[]` です。これらのオプションを C++ コンパイルコマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化の対象となります。この属性の各文字列は、バイナリターゲットをコンパイルする前に、指定された順序で `COPTS` に追加されます。このフラグは、このターゲットのコンパイルにのみ適用され、その依存関係には適用されません。そのため、他の場所に含まれているヘッダーファイルには注意してください。すべてのパスは、現在のパッケージではなくワークスペースからの相対パスにする必要があります。パッケージで機能 `no_copts_tokenization` が宣言されている場合、Bourne シェルのトークン化は、単一の「Make」変数で構成される文字列にのみ適用されます。
`defines`	文字列のリスト。デフォルトは `[]` です。コンパイル行に追加する定義のリスト。Make 変数の置換と Bourne シェルのトークン化の対象となります。各文字列（1 つの Bourne シェルトークンで構成されている必要があります）の前に `-D` が追加され、このターゲットへのコンパイルコマンドライン、およびそれに依存するすべてのルールに追加されます。広範囲の影響が及ぶ可能性があるため、細心の注意を払ってください。不明な場合は、代わりに `local_defines` に定義値を追加します。
`includes`	文字列のリスト。デフォルトは `[]` です。コンパイル行に追加するインクルードディレクトリのリスト。「変数を作成」の置換が適用されます。各文字列の前に `-isystem` が付加され、`COPTS` に追加されます。COPTS とは異なり、これらのフラグは、このルールと、このルールに依存するすべてのルールに追加されます。（注: 依存するルールではありません）。広範囲の影響が及ぶ可能性があるため、細心の注意を払ってください。判断に迷う場合は、代わりに「-I」フラグを COPTS に追加してください。ヘッダーは srcs または hdrs に追加する必要があります。追加しない場合、コンパイルがサンドボックス化されるときに、依存するルールでヘッダーを使用できません（デフォルト）。
`link_extra_lib`	ラベル（デフォルトは `"@bazel_tools//tools/cpp:link_extra_lib"`）追加ライブラリのリンクを制御します。デフォルトでは、C++ バイナリは `//tools/cpp:link_extra_lib` に対してリンクされます。これはデフォルトでラベルフラグ `//tools/cpp:link_extra_libs` に依存します。このフラグを設定しない場合、このライブラリはデフォルトで空になります。ラベルフラグを設定すると、弱いシンボルのオーバーライド、共有ライブラリ関数のインターセプタ、特別なランタイムライブラリ（malloc の置換には `malloc` または `--custom_malloc` を優先する）など、オプションの依存関係をリンクできます。この属性を `None` に設定すると、この動作が無効になります。
`linkopts`	文字列のリスト。デフォルトは `[]` です。これらのフラグを C++ リンカーコマンドに追加します。「Make」変数の置換、Bourne シェルのトークン化、ラベル展開の対象となります。この属性の各文字列は、バイナリターゲットをリンクする前に `LINKOPTS` に追加されます。このリストで、`$` または `-` で始まらない各要素は、`deps` 内のターゲットのラベルとみなされます。そのターゲットによって生成されたファイルのリストが、リンカーオプションに追加されます。ラベルが無効であるか、`deps` で宣言されていない場合、エラーが報告されます。
`linkstatic`	ブール値。デフォルトは `False` です。 `cc_binary` と `cc_test` の場合: 静的モードでバイナリをリンクします。`cc_library.linkstatic` の場合: 以下をご覧ください。このオプションはデフォルトで `cc_binary` でオンになり、それ以外ではオフになります。有効にするとバイナリまたはテストの場合、可能であればユーザーライブラリを `.so` ではなく `.a` でリンクするようビルドツールに指示します。静的ライブラリがないライブラリと同様に、一部のシステムライブラリは引き続き動的にリンクされる場合があります。したがって、生成された実行可能ファイルは依然として動的にリンクされるため、ほとんど静的となります。実行可能ファイルをリンクする方法は 3 つあります。すべてのものを静的にリンクできる full_static_link 機能を持つ STATIC（例: 「`gcc -static foo.o libbar.a libbaz.a -lm`」）。このモードを有効にするには、`features` 属性で `fully_static_link` を指定します。 STATIC: すべてのユーザーライブラリが静的にリンクされます（静的バージョンが利用可能な場合）。ただし、システムライブラリ（C/C++ ランタイムライブラリを除く）は動的にリンクされます（例: `gcc foo.o libfoo.a libbaz.a -lm`）。このモードは、`linkstatic=True` を指定して有効にします。 DYNAMIC: すべてのライブラリが動的にリンクされます（動的バージョンが使用可能な場合）。例: `gcc foo.o libfoo.so libbaz.so -lm`。このモードは、`linkstatic=False` を指定して有効にします。 `linkstatic` 属性は、`cc_library()` ルールで使用する場合と意味が異なります。C++ ライブラリの場合、`linkstatic=True` は静的リンクのみが許可されるため、`.so` は生成されないことを示します。linkstatic=False は、静的ライブラリの作成を妨げることはありません。この属性は、動的ライブラリの作成を制御するためのものです。 `linkstatic=False` の場合、ビルドツールは、依存する共有ライブラリへのシンボリックリンクを `*.runfiles` 領域に作成します。
`local_defines`	文字列のリスト。デフォルトは `[]` です。コンパイル行に追加する定義のリスト。Make 変数の置換と Bourne シェルのトークン化の対象となります。各文字列は 1 つの Bourne シェルトークンで構成する必要があり、先頭に `-D` が付加され、このターゲットのコンパイルコマンドラインに追加されますが、依存関係には追加されません。
`malloc`	ラベル: デフォルトは `"@bazel_tools//tools/cpp:malloc"` malloc に対するデフォルトの依存関係をオーバーライドします。デフォルトでは、C++ バイナリは `//tools/cpp:malloc` にリンクされます。これは空のライブラリであるため、バイナリは最終的に libc malloc を使用します。このラベルは `cc_library` を参照する必要があります。コンパイルが C++ 以外のルールの場合、このオプションは効果がありません。`linkshared=True` が指定されている場合、この属性の値は無視されます。
`nocopts`	文字列。デフォルトは `""` C++ コンパイルコマンドから一致するオプションを削除します。「Make」変数の置換が適用されます。この属性の値は正規表現として解釈されます。この正規表現（ルールの copts 属性で明示的に指定された値を含む）に一致する既存の `COPTS` は、このルールをコンパイルするために `COPTS` から削除されます。この属性はほとんど必要ありません。
`stamp`	整数。デフォルトは `0` です。ビルド情報をバイナリにエンコードするかどうか。可能な値: `stamp = 1`: `--nostamp` ビルドでも、常にビルド情報をバイナリにスタンプします。この設定はおすすめしません。バイナリとそれに依存するダウンストリームアクションのリモートキャッシュが強制終了される可能性があるためです。 `stamp = 0`: ビルド情報を常に定数値に置き換えます。これにより、ビルド結果のキャッシュが適切に保存されます。 `stamp = -1`: ビルド情報のエンベディングは、`--[no]stamp` フラグによって制御されます。スタンプされたバイナリは、依存関係が変更されない限り再ビルドされません。
`win_def_file`	ラベル（デフォルトは `None`）リンカーに渡される Windows DEF ファイル。この属性は、Windows がターゲットプラットフォームである場合にのみ使用してください。共有ライブラリのリンク時にシンボルをエクスポートするために使用できます。

cc_toolchain

ルールソースを表示

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)

C++ ツールチェーンを表します。

このルールにより、以下の処理が行われます。

C++ アクションの実行に必要なすべてのアーティファクトを収集します。これは、all_files、compiler_files、linker_files などの属性、または _files で終わるその他の属性によって行われます。これらは、ほとんどの場合、必要なすべてのファイルをグルーピングするファイルグループです。
C++ アクションの正しいコマンドラインを生成する。これは、CcToolchainConfigInfo プロバイダを使用して行われます（詳しくは下記をご覧ください）。

C++ ツールチェーンを構成するには、toolchain_config 属性を使用します。C++ ツールチェーンの構成とツールチェーンの選択について詳しくは、こちらのページをご覧ください。

bazel build //... を呼び出すときに、不要にツールチェーンがビルドおよび構成されないようにするには、tags = ["manual"] を使用します。

引数

属性
`name`	名前（必須）このターゲットの一意の名前。
`all_files`	ラベル: 必須すべての cc_ツールチェーンアーティファクトの収集。これらのアーティファクトは、rules_cc 関連のすべてのアクションへの入力として追加されます（以下の属性からより正確なアーティファクトセットを使用しているアクションを除く）。Bazel では、`all_files` が他のすべてのアーティファクト指定属性のスーパーセットであることを前提としています（たとえば、リンクスタンプのコンパイルにはコンパイルファイルとリンクファイルの両方が必要であるため、`all_files` が必要です）。これは `cc_toolchain.files` に含まれるもので、C++ ツールチェーンを使用するすべての Starlark ルールで使用されます。
`ar_files`	ラベル: デフォルトは `None` アーカイブアクションに必要なすべての cc_toolchain アーティファクトのコレクション。
`as_files`	ラベル（デフォルトは `None`）アセンブルアクションに必要なすべての cc_toolchain アーティファクトのコレクション。
`compiler_files`	ラベル: 必須コンパイルアクションに必要なすべての cc_toolchain アーティファクトのコレクション。
`compiler_files_without_includes`	ラベル: デフォルトは `None` 入力検出がサポートされている場合の、コンパイルアクションに必要なすべての cc_ツールチェーンアーティファクトの収集（現在は Google のみ）。
`coverage_files`	ラベル（デフォルトは `None`）カバレッジアクションに必要なすべての cc_toolchain アーティファクトのコレクション。指定しない場合、all_files が使用されます。
`dwp_files`	ラベル（必須） dwp アクションに必要なすべての cc_toolchain アーティファクトのコレクション。
`dynamic_runtime_lib`	ラベル: デフォルトは `None` C++ ランタイムライブラリの動的ライブラリアーティファクト（libstdc++.so など）。これは、「static_link_cpp_runtimes」機能が有効で、依存関係を動的にリンクしている場合に使用されます。
`exec_transition_for_inputs`	ブール値。デフォルトは `True` です。遷移なし（デフォルトではターゲットプラットフォーム）ではなく、実行プラットフォームの cc_toolchain にすべてのファイル入力をビルドするには、True に設定します。
`libc_top`	ラベル: デフォルトは `None` コンパイルアクションやリンクアクションへの入力として渡される libc のアーティファクトのコレクション。
`linker_files`	ラベル: 必須リンクアクションに必要なすべての cc_toolchain アーティファクトのコレクション。
`module_map`	ラベル: デフォルトは `None` モジュラービルドに使用するモジュールマップアーティファクト。
`objcopy_files`	ラベル（必須） objcopy アクションに必要なすべての cc_ツールチェーンアーティファクトのコレクション。
`static_runtime_lib`	ラベル（デフォルトは `None`） C++ ランタイムライブラリの静的ライブラリアーティファクト（libstdc++.a など）。これは、「static_link_cpp_runtimes」機能が有効で、依存関係を静的にリンクしている場合に使用されます。
`strip_files`	ラベル: 必須ストリップアクションに必要なすべての cc_toolchain アーティファクトのコレクション。
`supports_header_parsing`	ブール値。デフォルトは `False` です。 cc_ツールチェーンがヘッダー解析アクションをサポートしている場合は、True に設定します。
`supports_param_files`	ブール値。デフォルトは `True` cc_toolchain がリンクアクションにパラメータファイルの使用をサポートしている場合は True に設定します。
`toolchain_config`	ラベル（必須） `cc_toolchain_config_info` を提供するルールのラベル。
`toolchain_identifier`	文字列、設定不可、デフォルトは `""` この cc_ツールチェーンと、対応する crosstool_config.ツールチェーンを照合するために使用される識別子。問題 #5380 が修正されるまでは、この方法で `cc_toolchain` を `CROSSTOOL.toolchain` に関連付けることをおすすめします。`toolchain_config` 属性（#5380）に置き換えられます。

cc_toolchain_suite

ルールのソースを表示

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

C++ ツールチェーンのコレクションを表します。

このルールにより、以下の処理が行われます。

関連するすべての C++ ツールチェーンを収集します。
Bazel に渡される --cpu オプションと --compiler オプションに応じて、1 つのツールチェーンを選択する。

C++ ツールチェーンの構成とツールチェーンの選択について詳しくは、こちらのページをご覧ください。

引数

属性

name

名前（必須）

このターゲットの名前。

toolchains

文字列をラベルにマッピングするディクショナリ。構成不可。必須

「<cpu>」または「<cpu>|<compiler>」文字列から cc_toolchain ラベルへのマップ。「<cpu>」は、--cpu のみが Bazel に渡された場合は「<cpu>|<compiler>」を使用し、--cpu と --compiler の両方が Bazel に渡された場合は「<cpu>|<compiler>」を使用します。例:

          cc_toolchain_suite(
            name = "toolchain",
            toolchains = {
              "piii|gcc": ":my_cc_toolchain_for_piii_using_gcc",
              "piii": ":my_cc_toolchain_for_piii_using_default_compiler",
            },
          )