安定版リリースのドキュメントについては、[バージョニングされたドキュメント] プルダウンを使用してください。デフォルトのビューには HEAD の最新バージョンが表示されます。

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

C / C++ ルール

ルール

cc_binary
cc_import
cc_library
cc_proto_library
cc_shared_library
fdo_prefetch_hints
fdo_profile
propeller_optimize
cc_test
cc_ツールチェーン
cc_ツールチェーン_スイート

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, 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`	`Name; required` このターゲットの一意の名前。
`deps`	`List of labels; optional` バイナリターゲットにリンクするその他のライブラリのリスト。 `cc_library` ターゲットまたは `objc_library` ターゲットを指定できます。
`srcs`	`List of labels; optional` ターゲットを作成するために処理される 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`	`List of labels; optional` これらのファイルは C++ リンカーコマンドに渡します。たとえば、コンパイルされた Windows .res ファイルをここで指定すると、バイナリターゲットに埋め込むことができます。
`copts`	`List of strings; optional` 以下のオプションを C++ コンパイルコマンドに追加します。「変数を作成」置換とボーンシェルトークン化が適用されます。この属性の各文字列は、バイナリターゲットをコンパイルする前に `COPTS` に指定された順序で追加されます。フラグは、このターゲットの依存関係をコンパイルするためにのみ有効になります。そのため、他の場所に含まれているヘッダーファイルには注意してください。すべてのパスは、現在のパッケージではなくワークスペースへの相対パスである必要があります。パッケージが機能 `no_copts_tokenization` を宣言している場合、Bourne シェルのトークン化は、単一の「Make」変数で構成される文字列にのみ適用されます。
`defines`	`List of strings; optional` コンパイル行に追加する定義のリスト。「Make」変数の置換とボーンシェルトークン化が適用されます。各文字列は単一の Bourne シェルトークンで構成しなければならず、先頭に `-D` がコンパイルターゲットに追加されます。コンパイルコマンドラインは、この依存関係に依存するすべてのルールに追加されます。広範囲にわたる影響を及ぼす可能性があるため、十分に注意してください。判断に迷う場合は、代わりに `local_defines` に定義値を追加してください。
`includes`	`List of strings; optional` コンパイル行に追加するインクルディレクトリのリスト。 [変数を作成] による置換の対象となります。各文字列の先頭に `-isystem` が付加され、`COPTS` に追加されます。これらのフラグは、COPTS とは異なり、このルールとそれに依存するすべてのルールに追加されます。（注: ルールに依存しません）。広範囲にわたる影響が生じる可能性があるため、注意が必要です。判断に迷う場合は、代わりに COPTS に「-I」フラグを追加してください。ヘッダーは src または HDR に追加する必要があります。追加しないと、コンパイルがサンドボックス化されている（デフォルト）場合、依存ルールでヘッダーを使用できなくなります。
`linkopts`	`List of strings; optional` これらのフラグを C++ リンカーコマンドに追加します。「Make」変数の置換、 Bourne シェルトークン化、ラベル展開に従います。この属性の各文字列は、バイナリターゲットをリンクする前に `LINKOPTS` に追加されます。このリストの `$` または `-` で始まらない要素が、`deps` 内のターゲットのラベルであるとみなされます。ターゲットが生成したファイルのリストが、リンカーオプションに追加されます。ラベルが無効であるか、`deps` で宣言されていない場合、エラーが報告されます。
`linkshared`	`Boolean; optional; nonconfigurable; default is False` 共有ライブラリを作成します。この属性を有効にするには、ルールに `linkshared=True` を含めます。デフォルトでは、このオプションはオフになっています。このフラグが存在する場合、`-shared` フラグで `gcc` にリンクが行われ、生成される共有ライブラリは Java プログラムなどへの読み込みに適しています。ただし、ビルド上、cc_binary ルールでビルドされた共有ライブラリが他のプログラムによってのみ手動で読み込まれると想定されているため、ビルド時に依存関係のバイナリにリンクされることはありません。そのため、cc_library ルールの代替とは見なされません。スケーラビリティを高めるため、このアプローチは使用せず、代わりに `java_library` に `cc_library` ルールを適用させることをおすすめします。 `linkopts=['-static']` と `linkshared=True` を両方とも指定すると、完全に自己完結型の単位が 1 つになります。`linkstatic=True` と `linkshared=True` を両方指定すると、主に自己完結型の単一のユニットが得られます。
`linkstatic`	`Boolean; optional; default is 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` を指定します。静的バージョン（すべてのユーザーは静的バージョンを利用できる場合）でリンクを行いますが、システムライブラリ（C/C++ ランタイムライブラリを除く）は動的にリンクします。例: `gcc foo.o libfoo.a libbaz.a -lm`。このモードは、`linkstatic=True` を指定することで有効になります。すべてのライブラリを動的にリンクする動的バージョン（動的バージョンを利用できる場合）。例: `gcc foo.o libfoo.so libbaz.so -lm`。このモードを有効にするには、`linkstatic=False` を指定します。 `linkstatic` 属性は、`cc_library()` ルールで使用する場合、異なる意味を持ちます。C++ ライブラリの場合、`linkstatic=True` は静的リンクのみを許可することを示し、`.so` は生成されません。linkstatic=False は静的ライブラリの作成を禁止しません。この属性は、動的ライブラリの作成を制御することを目的としています。 `linkstatic=False` の場合、ビルドツールが `*.runfiles` 領域に、依存する共有ライブラリへのシンボリックリンクを作成します。
`local_defines`	`List of strings; optional` コンパイル行に追加する定義のリスト。「Make」変数の置換とボーンシェルトークン化が適用されます。各文字列は単一の Bourne シェルトークンで構成され、先頭に `-D` が付加され、このターゲットのコンパイルコマンドラインに追加されますが、依存関係には追加されません。
`malloc`	`Label; optional; default is @bazel_tools//tools/cpp:malloc` malloc のデフォルトの依存関係をオーバーライドします。デフォルトでは、C++ バイナリは空のライブラリである `//tools/cpp:malloc` に対してリンクされるため、最終的に libc malloc を使用してバイナリが作成されます。このラベルは `cc_library` を参照する必要があります。C++ 以外のルールのコンパイルの場合、このオプションは無視されます。`linkshared=True` が指定されている場合、この属性の値は無視されます。
`nocopts`	`String; optional` 一致するオプションを C++ コンパイルコマンドから削除します。「Make」変数の置換が適用されます。この属性の値は、正規表現として解釈されます。このルールをコンパイルする目的で、この正規表現に一致する既存の `COPTS`（ルールの copts 属性で明示的に指定された値を含む）が `COPTS` から削除されます。この属性が必要になることはほとんどありません。
`stamp`	`Integer; optional; default is -1` ビルド情報をバイナリにエンコードするかどうか。考えられる値は次のとおりです。 `stamp = 1`: `--nostamp` ビルドの場合でも、ビルド情報を常にバイナリにスタンプします。この設定は避けてください。この設定により、バイナリおよびそれに依存するすべてのダウンストリームアクションのリモートキャッシュが強制終了される可能性があるためです。 `stamp = 0`: ビルド情報を常に定数値に置き換えます。これにより、ビルド結果を適切にキャッシュに保存できます。 `stamp = -1`: ビルド情報の埋め込みは、`--[no]stamp` フラグで制御されます。スタンプされたバイナリは、依存関係が変更されない限り、再ビルドされません。
`win_def_file`	`Label; optional` リンカーに渡す 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 は、インクルード属性をサポートします。次に例を示します。

  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`	`Name; required` このターゲットの一意の名前。
`deps`	`List of labels; optional` ターゲットが依存する他のライブラリのリスト。`deps` に関する一般的なコメントについては、ほとんどのビルドルールで定義されている一般的な属性をご覧ください。
`hdrs`	`List of labels; optional` プリコンパイルされたライブラリが公開し、依存ルールのソースに直接含まれるヘッダーファイルのリスト。
`alwayslink`	`Boolean; optional; default is False` 1 の場合、この C++ プリコンパイル済みライブラリに依存するバイナリ（直接的または間接的）は、静的ライブラリでアーカイブされたすべてのオブジェクトファイルにリンクされます。この中に、バイナリで参照されるシンボルが含まれていなくても構いません。これは、バイナリ内のコードによってコードを明示的に呼び出さない場合（たとえば、サービスが提供するコールバックを受け取るようにコードを登録する場合）に便利です。既知の問題が原因で、Windows の VS 2017 で alwayslink が動作しない場合は、VS 2017 を最新バージョンにアップグレードしてください。
`interface_library`	`Label; optional` 共有ライブラリをリンクするための単一のインターフェースライブラリ。使用できるファイル形式: `.ifso`、`.tbd`、`.lib`、`.so`、`.dylib`
`shared_library`	`Label; optional` 単一のプリコンパイルされた共有ライブラリ。Bazel は、ランタイムに依存するバイナリを Bazel が使用できるようにします。使用できるファイル形式: `.so`、`.dll`、または `.dylib`
`static_library`	`Label; optional` 単一のプリコンパイルされた静的ライブラリ。使用できるファイル形式: `.a`、`.pic.a`、または `.lib`
`system_provided`	`Boolean; optional; default is False` 1 の場合は、実行時に必要な共有ライブラリがシステムによって提供されていることを示します。この場合は、`interface_library` を指定し、`shared_library` を空にする必要があります。

cc_library

ルールのソースを表示

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)

ヘッダーの包含チェック

ビルドで使用されるすべてのヘッダーファイルは、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" を含めることはできません。そのためには、foo の deps に baz を追加する必要があります。

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

引数

属性
`name`	`Name; required` このターゲットの一意の名前。
`deps`	`List of labels; optional` バイナリターゲットにリンクするその他のライブラリのリスト。 `cc_library` ターゲットまたは `objc_library` ターゲットを指定できます。
`srcs`	`List of labels; optional` ターゲットを作成するために処理される 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 規則に従って異なるプログラミング言語を示します。
`hdrs`	`List of labels; optional` このライブラリによって公開され、依存ルールのソースに直接含まれるヘッダーファイルのリスト。これは、ライブラリのインターフェースを記述するヘッダーファイルを宣言する場合に強く推奨されます。これらのヘッダーは、このルールまたはソースの依存関係に含まれるソースに含まれていることが必要になります。このライブラリのクライアントに含まれていないヘッダーは、公開済みのヘッダーに含まれていても、`srcs` 属性に含める必要があります。詳しくは、ヘッダー包含チェックをご覧ください。
`alwayslink`	`Boolean; optional; default is False` 1 の場合、この C++ ライブラリに直接的または間接的に依存するバイナリは、バイナリで参照されているシンボルがない場合でも、`srcs` にリストされているファイルのすべてのオブジェクトファイル内でリンクされます。これは、バイナリ内のコードによってコードを明示的に呼び出さない場合（たとえば、サービスが提供するコールバックを受け取るようにコードを登録する場合）に便利です。既知の問題が原因で、Windows の VS 2017 で alwayslink が動作しない場合は、VS 2017 を最新バージョンにアップグレードしてください。
`copts`	`List of strings; optional` 以下のオプションを C++ コンパイルコマンドに追加します。「変数を作成」置換とボーンシェルトークン化が適用されます。この属性の各文字列は、バイナリターゲットをコンパイルする前に `COPTS` に指定された順序で追加されます。フラグは、このターゲットの依存関係をコンパイルするためにのみ有効になります。そのため、他の場所に含まれているヘッダーファイルには注意してください。すべてのパスは、現在のパッケージではなくワークスペースへの相対パスである必要があります。パッケージが機能 `no_copts_tokenization` を宣言している場合、Bourne シェルのトークン化は、単一の「Make」変数で構成される文字列にのみ適用されます。
`defines`	`List of strings; optional` コンパイル行に追加する定義のリスト。「Make」変数の置換とボーンシェルトークン化が適用されます。各文字列は単一の Bourne シェルトークンで構成しなければならず、先頭に `-D` がコンパイルターゲットに追加されます。コンパイルコマンドラインは、この依存関係に依存するすべてのルールに追加されます。広範囲にわたる影響を及ぼす可能性があるため、十分に注意してください。判断に迷う場合は、代わりに `local_defines` に定義値を追加してください。
`implementation_deps`	`List of labels; optional` ライブラリターゲットが依存している他のライブラリのリスト。`deps` と異なり、これらのライブラリのヘッダーとインクルードパス（およびこれらのすべての推移的な依存関係）は、このライブラリのコンパイルにのみ使用され、依存するライブラリには使用されません。`implementation_deps` で指定されたライブラリは、このライブラリに依存するバイナリターゲットで引き続きリンクされます。現在のところ、使用は cc_libraries に制限され、フラグ `--experimental_cc_implementation_deps` によって保護されています。
`include_prefix`	`String; optional` このルールのヘッダーのパスに追加する接頭辞。設定すると、このルールの `hdrs` 属性内のヘッダーは、この属性の値として、リポジトリの相対パスの先頭に付加されます。 `strip_include_prefix` 属性の接頭辞は、この接頭辞が追加される前に削除されます。
`includes`	`List of strings; optional` コンパイル行に追加するインクルディレクトリのリスト。 [変数を作成] による置換の対象となります。各文字列の先頭に `-isystem` が付加され、`COPTS` に追加されます。これらのフラグは、COPTS とは異なり、このルールとそれに依存するすべてのルールに追加されます。（注: ルールに依存しません）。広範囲にわたる影響が生じる可能性があるため、注意が必要です。判断に迷う場合は、代わりに COPTS に「-I」フラグを追加してください。ヘッダーは src または HDR に追加する必要があります。追加しないと、コンパイルがサンドボックス化されている（デフォルト）場合、依存ルールでヘッダーを使用できなくなります。
`linkopts`	`List of strings; optional` これらのフラグを C++ リンカーコマンドに追加します。「Make」変数の置換、 Bourne シェルトークン化、ラベル展開に従います。この属性の各文字列は、バイナリターゲットをリンクする前に `LINKOPTS` に追加されます。このリストの `$` または `-` で始まらない要素が、`deps` 内のターゲットのラベルであるとみなされます。ターゲットが生成したファイルのリストが、リンカーオプションに追加されます。ラベルが無効であるか、`deps` で宣言されていない場合、エラーが報告されます。
`linkstamp`	`Label; optional` 指定された C++ ソースファイルをコンパイルして、最終バイナリに同時にリンクします。この方法は、タイムスタンプ情報をバイナリに導入するために必要です。ソースファイルを通常の方法でオブジェクトファイルにコンパイルすると、タイムスタンプが不正確になります。linksamp コンパイルには、特定のコンパイラフラグのセットを含めることはできません。そのため、特定のヘッダー、コンパイラオプション、その他のビルド変数には依存しないでください。このオプションは、`base` パッケージでのみ必要です。
`linkstatic`	`Boolean; optional; default is 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` を指定します。静的バージョン（すべてのユーザーは静的バージョンを利用できる場合）でリンクを行いますが、システムライブラリ（C/C++ ランタイムライブラリを除く）は動的にリンクします。例: `gcc foo.o libfoo.a libbaz.a -lm`。このモードは、`linkstatic=True` を指定することで有効になります。すべてのライブラリを動的にリンクする動的バージョン（動的バージョンを利用できる場合）。例: `gcc foo.o libfoo.so libbaz.so -lm`。このモードを有効にするには、`linkstatic=False` を指定します。 `linkstatic` 属性は、`cc_library()` ルールで使用する場合、異なる意味を持ちます。C++ ライブラリの場合、`linkstatic=True` は静的リンクのみを許可することを示し、`.so` は生成されません。linkstatic=False は静的ライブラリの作成を禁止しません。この属性は、動的ライブラリの作成を制御することを目的としています。 `linkstatic=False` の場合、ビルドツールが `*.runfiles` 領域に、依存する共有ライブラリへのシンボリックリンクを作成します。
`local_defines`	`List of strings; optional` コンパイル行に追加する定義のリスト。「Make」変数の置換とボーンシェルトークン化が適用されます。各文字列は単一の Bourne シェルトークンで構成され、先頭に `-D` が付加され、このターゲットのコンパイルコマンドラインに追加されますが、依存関係には追加されません。
`nocopts`	`String; optional` 一致するオプションを C++ コンパイルコマンドから削除します。「Make」変数の置換が適用されます。この属性の値は、正規表現として解釈されます。このルールをコンパイルする目的で、この正規表現に一致する既存の `COPTS`（ルールの copts 属性で明示的に指定された値を含む）が `COPTS` から削除されます。この属性が必要になることはほとんどありません。
`strip_include_prefix`	`String; optional` このルールのヘッダーのパスから除去する接頭辞。設定すると、このルールの `hdrs` 属性内のヘッダーには、この接頭辞がカットされたパスでアクセスできます。相対パスの場合は、パッケージからの相対パスになります。絶対パスの場合は、リポジトリの相対パスとして認識されます。 `include_prefix` 属性の接頭辞は、この接頭辞が削除された後に追加されます。
`textual_hdrs`	`List of labels; optional` 依存ルールのソースによってテキストで含まれる、このライブラリによって公開されるヘッダーファイルのリスト。これは、単独ではコンパイルできないヘッダーファイルを宣言する場所です。つまり、有効なコードを構築するには、常に他のソースファイルにテキストに含める必要があります。
`win_def_file`	`Label; optional` リンカーに渡す 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

Name; required

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

deps

List of labels; optional

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 を作成すると発生します。エクスポート時のエラーに似ています。

この問題の解決策の一つは、cc_shared_library 依存関係のいずれかへのライブラリのリンクを停止することです。同時に、まだリンク中のライブラリはシンボルをエクスポートできるよう、ライブラリをエクスポートする必要があります。もう一つの方法は、ターゲットをエクスポートする 3 つ目のライブラリを抽出することです。3 つ目の方法は、LINKABLE_MORE_THAN_ONCE で問題の原因の cc_library にタグ付けすることですが、この修正はまれです。cc_library が実際にリンクが安全になるように、複数回行う必要があります。

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

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

この問題を解決するには、cc_shared_library 依存関係からエクスポートするか、3 つ目の 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`

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

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

引数

属性
`name`	`Name; required` このターゲットの一意の名前。
`deps`	`List of labels; optional` 完全にアーカイブされた後に、共有ライブラリに無条件にリンクされるトップレベルのライブラリ。直接依存関係の一時的なライブラリ依存関係は、`dynamic_deps` の `cc_shared_library` によってリンクされていない限り、この共有ライブラリにリンクされます。分析中、複数の `cc_shared_libraries` が同じターゲットをエクスポートするときにエラーが発生するように、ルールの実装では `deps` にリストされているターゲットが共有ライブラリによってエクスポートされているとみなされます。ルールの実装により、どのシンボルが共有オブジェクトによってエクスポートされるかについてリンカーから情報が伝えられることはありません。ユーザーは、リンカースクリプトまたはソースコードでの可視性の宣言を使用して対処する必要があります。また、同じライブラリが複数の `cc_shared_library` に静的にリンクされている場合は、実装時にエラーがトリガーされます。これを避けるには、`"LINKABLE_MORE_THAN_ONCE"` を `cc_library.tags` に追加するか、共有ライブラリの 1 つをエクスポートとして cc_library をリストして、一方を他方の`dynamic_dep`にすることができます。
`additional_linker_inputs`	`List of labels; optional` リンカースクリプトに渡す必要がある追加のファイル（リンカースクリプトなど）。このファイルを認識するために、リンカーが必要とするフラグは別途渡す必要があります。そのためには、`user_link_flags` 属性を使用します。
`dynamic_deps`	`List of labels; optional` これらは、現在のターゲットが依存する他の `cc_shared_library` 依存関係です。 `cc_shared_library` の実装では、`dynamic_deps` のリスト（推移的、つまり現在のターゲットの `dynamic_deps` の `dynamic_deps`）を使用して、推移的な `deps` のどの `cc_libraries` が別の `cc_shared_library` によってすでに指定されているため、リンクしないかを決定します。
`exports_filter`	`List of strings; optional` この属性には、現在の共有ライブラリによってエクスポートされたとされるターゲットのリストが含まれます。ターゲット `deps` は、すでに共有ライブラリによってエクスポートされていると認識されています。この属性は、共有ライブラリによってエクスポートされるが `deps` の推移的な依存関係であるターゲットを一覧表示する場合に使用します。この属性が実際にターゲットに依存関係エッジを追加していないため、依存関係エッジは `deps` によって作成する必要があります。この属性のエントリは文字列のみです。この属性にターゲットを配置すると、共有ライブラリがそのターゲットからシンボルをエクスポートするというクレームとみなされます。実際には、`cc_shared_library` ロジックは、エクスポートするシンボルをリンカーに伝える処理は行いません。次の構文を使用できます。 foo/BUILD の任意のターゲットを考慮する `//foo:__package__` `//foo:__subpackages__` は、foo/BUILD に含まれるターゲット、または foo/bar/BUILD などの foo の下にある他のパッケージを考慮します。
`shared_lib_name`	`String; optional` デフォルトでは、cc_shared_library はターゲットの名前とプラットフォームに基づいて共有ライブラリの出力ファイルの名前を使用します。これには、拡張機能と場合によってはプレフィックスが含まれます。デフォルト名が必要ない場合もあります。たとえば、Python 用の C++ 共有ライブラリを読み込むときに、デフォルトの lib* プレフィックスが必要ないこともあります。その場合は、この属性を使用してカスタム名を選択できます。
`user_link_flags`	`List of strings; optional` リンカーに渡す必要がある追加のフラグ。たとえば、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`	`Label; optional` リンカーに渡す 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

Name; required

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

profile

Label; optional

ヒントプロファイルのラベル。ヒントファイルの拡張子は .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`	`Name; required` このターゲットの一意の名前。
`absolute_path_profile`	`String; optional` FDO プロファイルへの絶対パス。FDO ファイルの拡張子は .afdo のみです。
`profile`	`Label; optional` FDO プロファイルまたはそれを生成するルールのラベル。FDO ファイルの拡張子は、インデックスなしの LLVM プロファイルの場合は .profraw、LLVM プロファイルのプロファイルの場合は .profdata、AutoFDO プロファイルの .afdo、XBinary プロファイルの場合は .xfdo のいずれかです。ラベルに fdo_absolute_path_profile ルールを指す場合もあります。
`proto_profile`	`Label; optional` protobuf プロファイルのラベル。

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

Name; required

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

ld_profile

Label; optional

リンクアクションに渡されるプロフィールのラベル。このファイルの拡張子は .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, 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`	`Name; required` このターゲットの一意の名前。
`deps`	`List of labels; optional` バイナリターゲットにリンクするその他のライブラリのリスト。 `cc_library` ターゲットまたは `objc_library` ターゲットを指定できます。
`srcs`	`List of labels; optional` ターゲットを作成するために処理される 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`	`List of labels; optional` これらのファイルは C++ リンカーコマンドに渡します。たとえば、コンパイルされた Windows .res ファイルをここで指定すると、バイナリターゲットに埋め込むことができます。
`copts`	`List of strings; optional` 以下のオプションを C++ コンパイルコマンドに追加します。「変数を作成」置換とボーンシェルトークン化が適用されます。この属性の各文字列は、バイナリターゲットをコンパイルする前に `COPTS` に指定された順序で追加されます。フラグは、このターゲットの依存関係をコンパイルするためにのみ有効になります。そのため、他の場所に含まれているヘッダーファイルには注意してください。すべてのパスは、現在のパッケージではなくワークスペースへの相対パスである必要があります。パッケージが機能 `no_copts_tokenization` を宣言している場合、Bourne シェルのトークン化は、単一の「Make」変数で構成される文字列にのみ適用されます。
`defines`	`List of strings; optional` コンパイル行に追加する定義のリスト。「Make」変数の置換とボーンシェルトークン化が適用されます。各文字列は単一の Bourne シェルトークンで構成しなければならず、先頭に `-D` がコンパイルターゲットに追加されます。コンパイルコマンドラインは、この依存関係に依存するすべてのルールに追加されます。広範囲にわたる影響を及ぼす可能性があるため、十分に注意してください。判断に迷う場合は、代わりに `local_defines` に定義値を追加してください。
`includes`	`List of strings; optional` コンパイル行に追加するインクルディレクトリのリスト。 [変数を作成] による置換の対象となります。各文字列の先頭に `-isystem` が付加され、`COPTS` に追加されます。これらのフラグは、COPTS とは異なり、このルールとそれに依存するすべてのルールに追加されます。（注: ルールに依存しません）。広範囲にわたる影響が生じる可能性があるため、注意が必要です。判断に迷う場合は、代わりに COPTS に「-I」フラグを追加してください。ヘッダーは src または HDR に追加する必要があります。追加しないと、コンパイルがサンドボックス化されている（デフォルト）場合、依存ルールでヘッダーを使用できなくなります。
`linkopts`	`List of strings; optional` これらのフラグを C++ リンカーコマンドに追加します。「Make」変数の置換、 Bourne シェルトークン化、ラベル展開に従います。この属性の各文字列は、バイナリターゲットをリンクする前に `LINKOPTS` に追加されます。このリストの `$` または `-` で始まらない要素が、`deps` 内のターゲットのラベルであるとみなされます。ターゲットが生成したファイルのリストが、リンカーオプションに追加されます。ラベルが無効であるか、`deps` で宣言されていない場合、エラーが報告されます。
`linkstatic`	`Boolean; optional; default is 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` を指定します。静的バージョン（すべてのユーザーは静的バージョンを利用できる場合）でリンクを行いますが、システムライブラリ（C/C++ ランタイムライブラリを除く）は動的にリンクします。例: `gcc foo.o libfoo.a libbaz.a -lm`。このモードは、`linkstatic=True` を指定することで有効になります。すべてのライブラリを動的にリンクする動的バージョン（動的バージョンを利用できる場合）。例: `gcc foo.o libfoo.so libbaz.so -lm`。このモードを有効にするには、`linkstatic=False` を指定します。 `linkstatic` 属性は、`cc_library()` ルールで使用する場合、異なる意味を持ちます。C++ ライブラリの場合、`linkstatic=True` は静的リンクのみを許可することを示し、`.so` は生成されません。linkstatic=False は静的ライブラリの作成を禁止しません。この属性は、動的ライブラリの作成を制御することを目的としています。 `linkstatic=False` の場合、ビルドツールが `*.runfiles` 領域に、依存する共有ライブラリへのシンボリックリンクを作成します。
`local_defines`	`List of strings; optional` コンパイル行に追加する定義のリスト。「Make」変数の置換とボーンシェルトークン化が適用されます。各文字列は単一の Bourne シェルトークンで構成され、先頭に `-D` が付加され、このターゲットのコンパイルコマンドラインに追加されますが、依存関係には追加されません。
`malloc`	`Label; optional; default is @bazel_tools//tools/cpp:malloc` malloc のデフォルトの依存関係をオーバーライドします。デフォルトでは、C++ バイナリは空のライブラリである `//tools/cpp:malloc` に対してリンクされるため、最終的に libc malloc を使用してバイナリが作成されます。このラベルは `cc_library` を参照する必要があります。C++ 以外のルールのコンパイルの場合、このオプションは無視されます。`linkshared=True` が指定されている場合、この属性の値は無視されます。
`nocopts`	`String; optional` 一致するオプションを C++ コンパイルコマンドから削除します。「Make」変数の置換が適用されます。この属性の値は、正規表現として解釈されます。このルールをコンパイルする目的で、この正規表現に一致する既存の `COPTS`（ルールの copts 属性で明示的に指定された値を含む）が `COPTS` から削除されます。この属性が必要になることはほとんどありません。
`stamp`	`Integer; optional; default is 0` ビルド情報をバイナリにエンコードするかどうか。考えられる値は次のとおりです。 `stamp = 1`: `--nostamp` ビルドの場合でも、ビルド情報を常にバイナリにスタンプします。この設定は避けてください。この設定により、バイナリおよびそれに依存するすべてのダウンストリームアクションのリモートキャッシュが強制終了される可能性があるためです。 `stamp = 0`: ビルド情報を常に定数値に置き換えます。これにより、ビルド結果を適切にキャッシュに保存できます。 `stamp = -1`: ビルド情報の埋め込みは、`--[no]stamp` フラグで制御されます。スタンプされたバイナリは、依存関係が変更されない限り、再ビルドされません。
`win_def_file`	`Label; optional` リンカーに渡す Windows DEF ファイル。この属性は、Windows がターゲットプラットフォームである場合にのみ使用してください。共有ライブラリをリンクする際に、シンボルをエクスポートできます。

cc_ツールチェーン

ルールのソースを表示

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)

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

このルールによって行われる処理は次のとおりです。

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

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

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

引数

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

cc_ツールチェーン_スイート

ルールのソースを表示

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

Name; required

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

toolchains

Dictionary mapping strings to labels; required; nonconfigurable

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

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