C / C++ ルール

問題を報告する ソースを表示

Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.7

ルール

• cc_binary
• cc_import
• cc_library
• cc_shared_library
• cc_static_library
• cc_test
• cc_toolchain
• fdo_prefetch_hints
• fdo_profile
• memprof_profile
• propeller_optimize

cc_binary

ルールソースを表示

cc_binary(name, deps, srcs, data, additional_linker_inputs, args, aspect_hints, compatible_with, conlyopts, copts, cxxopts, defines, deprecation, dynamic_deps, env, exec_compatible_with, exec_group_compatible_with, exec_properties, features, hdrs_check, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local_defines, malloc, module_interfaces, nocopts, output_licenses, package_metadata, reexport_deps, restricted_to, stamp, tags, target_compatible_with, testonly, toolchains, visibility, win_def_file)

実行可能なバイナリが生成されます。

ターゲットの name は、アプリケーションのメイン エントリ ポイントであるソースファイルの名前（拡張子を除く）と同じである必要があります。たとえば、エントリ ポイントが main.cc にある場合、名前は main になります。

暗黙的な出力ターゲット

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

引数

属性
name	名前（必須） このターゲットの一意の名前。
deps	ラベルのリスト。デフォルトは [] バイナリ ターゲットにリンクされる他のライブラリのリスト。 これらは cc_library ターゲットまたは objc_library ターゲットにできます。 リンカ スクリプト（.lds）を deps に配置し、linkopts で参照することもできますが、そのユースケースでは additional_linker_inputs を検討してください。
srcs	ラベルのリスト。デフォルトは [] ライブラリ ターゲットを作成するために処理される C ファイルと C++ ファイルのリスト。これらは、生成されていない（通常のソースコード）または生成された C/C++ ソースファイルとヘッダー ファイルです。 .cc、.c、.cpp の各ファイルがすべてコンパイルされます。生成されたファイルの場合、名前付きファイルが他のルールの outs にあると、この cc_library は自動的にそのルールに依存します。 純粋なアセンブラ ファイル（.s、.asm）はプリプロセスされず、通常はアセンブラを使用してビルドされます。プリプロセスされたアセンブリ ファイル（.S）はプリプロセスされ、通常は C/C++ コンパイラを使用してビルドされます。 .h ファイルはコンパイルされませんが、このルールのソースでインクルードできます。.cc ファイルと .h ファイルの両方で、これらの srcs にリストされているヘッダー、このルールの hdrs、または deps 引数にリストされている任意のルールを直接含めることができます。 すべての #included ファイルは、このルールまたは参照される cc_library ルールの hdrs 属性で言及されるか、このライブラリにプライベートな場合は srcs にリストされる必要があります。詳しくは、「ヘッダーのインクルード チェック」をご覧ください。 .so、.lo、.a ファイルは、事前コンパイルされたファイルです。ソースコードのないサードパーティ コードを使用している場合、ライブラリに srcs が含まれている可能性があります。 srcs 属性に別のルールのラベルが含まれている場合、cc_library はそのルールの出力ファイルをコンパイルするソースファイルとして使用します。これは、ソースコードの 1 回限りの生成に役立ちます（頻繁に使用する場合は、Starlark ルールクラスを実装して cc_common API を使用することをおすすめします）。 許可されている 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 ... およびそれらのファイルを生成するルール（cc_embed_data など）。 異なる拡張子は、gcc の慣例に従って異なるプログラミング言語を示します。
data	ラベルのリスト。デフォルトは [] このライブラリが実行時に必要とするファイルのリスト。data に関する一般的なコメントについては、ほとんどのビルドルールで定義される一般的な属性をご覧ください。 data が生成されたファイルの名前である場合、この cc_library ルールは生成ルールに自動的に依存します。 data がルール名の場合、この cc_library ルールはそのルールに自動的に依存し、そのルールの outs はこの cc_library のデータファイルに自動的に追加されます。 C++ コードでこれらのデータファイルにアクセスするには、次のようにします。 const std::string path = devtools_build::GetDataDependencyFilepath( "my/test/data/file");
additional_linker_inputs	ラベルのリスト。デフォルトは [] C++ リンカー コマンドでのみ使用できる依存関係。 コンパイルとリンクの両方の依存関係を概念的に対象とする deps とは異なり、additional_linker_inputs は後者のみを対象としており、リンクにのみ必要な依存関係（linkopts で参照されるファイルなど）を示します。 たとえば、コンパイル済みの Windows .res ファイルをここに指定して、バイナリ ターゲットに埋め込むことができます。
conlyopts	文字列のリスト。デフォルトは [] これらのオプションを C コンパイル コマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化の対象となります。
copts	文字列のリスト。デフォルトは [] これらのオプションを C/C++ コンパイル コマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化の対象となります。 この属性の各文字列は、バイナリ ターゲットをコンパイルする前に、指定された順序で COPTS に追加されます。フラグは、このターゲットのコンパイルにのみ有効で、依存関係には有効ではありません。そのため、他の場所に含まれるヘッダー ファイルには注意してください。すべてのパスは、現在のパッケージではなく、ワークスペースを基準とした相対パスにする必要があります。この属性は third_party の外部では必要ありません。 パッケージが機能 no_copts_tokenization を宣言している場合、Bourne シェルのトークン化は、単一の「Make」変数で構成される文字列にのみ適用されます。
cxxopts	文字列のリスト。デフォルトは [] これらのオプションを C++ コンパイル コマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化の対象となります。
defines	文字列のリスト。デフォルトは [] このターゲットとすべての依存ターゲットのコンパイル行に追加する定義のリスト。「Make」変数の置換と Bourne シェルのトークン化の対象となります。各文字列（単一の Bourne シェル トークンで構成されている必要があります）の先頭に -D が付加され、このターゲットのコンパイル コマンドラインと、このターゲットに依存するすべてのルールに追加されます。このターゲットに依存するすべてのターゲットに定義が追加されるため、広範囲に影響する可能性があります。十分注意してください。不明な場合は、代わりに local_defines に定義値を追加します。
dynamic_deps	ラベルのリスト。デフォルトは [] これらは、現在のターゲットが依存する他の cc_shared_library 依存関係です。 cc_shared_library の実装では、dynamic_deps のリスト（推移的、つまり現在のターゲットの dynamic_deps の dynamic_deps も含む）を使用して、推移的な deps のどの cc_libraries をリンクしないかを決定します。これは、別の cc_shared_library によってすでに提供されているためです。
hdrs_check	文字列。デフォルトは "" です。 非推奨、無演算。
includes	文字列のリスト。デフォルトは [] コンパイル行に追加するインクルード ディレクトリのリスト。「変数を作成」の置換の対象となります。各文字列の先頭にパッケージ パスが追加され、CROSSTOOL 機能の include_paths を介して C++ ツールチェーンに渡されて展開されます。一般的な機能定義を含む POSIX システムで実行されるツールチェーンは、-isystem path_to_package/include_entry を生成します。これは、Google の #include ステートメントの記述スタイルに準拠していないサードパーティ ライブラリでのみ使用してください。COPTS とは異なり、これらのフラグはこのルールと、このルールに依存するすべてのルールに追加されます。（注: 依存するルールではありません）。この操作は広範囲に影響する可能性があるため、慎重に行ってください。不明な場合は、代わりに COPTS に「-I」フラグを追加します。 追加された include パスには、生成されたファイルとソースツリー内のファイルが含まれます。
link_extra_lib	ラベル。デフォルトは "@bazel_tools//tools/cpp:link_extra_lib" 追加ライブラリのリンクを制御します。 デフォルトでは、C++ バイナリは @bazel_tools//tools/cpp:link_extra_lib に対してリンクされます。これはデフォルトでラベルフラグ @bazel_tools//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 の両方を指定すると、ほぼ自己完結型の単一ユニットが取得されます。
linkstatic	ブール値。デフォルトは True です。 cc_binary と cc_test の場合: バイナリを静的モードでリンクします。cc_library.link_static: 以下をご覧ください。 デフォルトでは、このオプションは cc_binary ではオン、それ以外ではオフになっています。 有効で、これがバイナリまたはテストの場合、このオプションは、可能な限りユーザー ライブラリの .so ではなく .a をリンクするようにビルドツールに指示します。libc などのシステム ライブラリ（ただし、C/C++ ランタイム ライブラリは除く。下記を参照）は、静的ライブラリがないライブラリと同様に、動的にリンクされます。したがって、結果の実行可能ファイルは引き続き動的にリンクされるため、静的であるのはほとんどの場合のみです。 実行可能ファイルをリンクする方法は、実際には 3 つあります。 すべてが静的にリンクされる fully_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 を指定することで有効になります。 features の linkstatic 属性または fully_static_link が //third_party の外部で使用されている場合は、その理由を説明するコメントをルールの近くに含めてください。 linkstatic 属性は、cc_library() ルールで使用される場合、意味が異なります。C++ ライブラリの場合、linkstatic=True は静的リンクのみが許可されていることを示します。そのため、.so は生成されません。linkstatic=False は、静的ライブラリの作成を妨げません。この属性は、動的ライブラリの作成を制御するためのものです。 本番環境で linkstatic=False を使用してビルドされたコードはほとんどありません。linkstatic=False の場合、ビルドツールは *.runfiles 領域に依存する共有ライブラリへのシンボリック リンクを作成します。
local_defines	文字列のリスト。デフォルトは [] コンパイル行に追加する定義のリスト。「Make」変数の置換と Bourne シェルのトークン化の対象となります。各文字列は単一の Bourne シェル トークンで構成されている必要があり、-D が先頭に付加され、このターゲットのコンパイル コマンドラインに追加されますが、依存関係には追加されません。defines とは異なり、このターゲットのコンパイル コマンドラインにのみ定義が追加されます。
malloc	ラベル。デフォルトは "@bazel_tools//tools/cpp:malloc" malloc のデフォルトの依存関係をオーバーライドします。 デフォルトでは、C++ バイナリは //tools/cpp:malloc に対してリンクされます。これは空のライブラリであるため、バイナリは libc malloc を使用することになります。このラベルは cc_library を参照する必要があります。コンパイルが C++ 以外のルールの場合、このオプションは効果がありません。linkshared=True が指定されている場合、この属性の値は無視されます。
module_interfaces	ラベルのリスト。デフォルトは [] ファイルのリストは C++20 モジュール インターフェースとみなされます。 C++ 標準にはモジュール インターフェース ファイル拡張子に関する制限はありません Clang で cppm を使用する GCC は任意のソースファイル拡張子を使用できます MSVC で ixx を使用する この使用は --experimental_cpp_modules フラグによって保護されています。
nocopts	文字列。デフォルトは "" です。 C++ コンパイル コマンドから一致するオプションを削除します。「Make」変数の置換の対象となります。この属性の値は正規表現として解釈されます。この正規表現に一致する既存の COPTS（ルールの copts 属性で明示的に指定された値を含む）は、このルールをコンパイルする目的で COPTS から削除されます。この属性は third_party の外部では必要とされず、使用もされません。値は、「Make」変数の置換以外の方法で前処理されません。
reexport_deps	ラベルのリスト。デフォルトは []
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, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, includes, interface_library, linkopts, objects, package_metadata, pic_objects, pic_static_library, restricted_to, shared_library, static_library, strip_include_prefix, system_provided, tags, target_compatible_with, testonly, toolchains, 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 = True,
)

2. 共有ライブラリをリンクする（Unix）

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

3. インターフェース ライブラリと共有ライブラリをリンクする

Unix の場合:

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

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 を使用した共有ライブラリのリンク

Unix の場合:

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  interface_library = "libmylib.ifso", # Or we can also use libmylib.so as its own interface library
  # libmylib.so is provided by system environment, for example it can be found in LD_LIBRARY_PATH.
  # This indicates that Bazel is not responsible for making libmylib.so available.
  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 = True,
)

5. 静的ライブラリまたは共有ライブラリへのリンク

Unix の場合:

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

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

残りの部分は Unix と Windows で同じです。

# first will link to libmylib.a (or libmylib.lib)
cc_binary(
  name = "first",
  srcs = ["first.cc"],
  deps = [":mylib"],
  linkstatic = True, # default value
)

# second will link to libmylib.so (or libmylib.lib)
cc_binary(
  name = "second",
  srcs = ["second.cc"],
  deps = [":mylib"],
  linkstatic = False,
)

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 です。 有効にすると、この C++ プリコンパイル済みライブラリに（直接的または間接的に）依存するバイナリは、静的ライブラリにアーカイブされたすべてのオブジェクト ファイルをリンクします。バイナリで参照されるシンボルが含まれていないオブジェクト ファイルもリンクされます。これは、コードがバイナリ内のコードによって明示的に呼び出されない場合に便利です。たとえば、コードが登録されて、サービスから提供されたコールバックを受け取る場合などです。 Windows で alwayslink が VS 2017 で動作しない場合は、既知の問題が原因です。VS 2017 を最新バージョンにアップグレードしてください。
includes	文字列のリスト。デフォルトは [] コンパイル行に追加するインクルード ディレクトリのリスト。「変数を作成」の置換の対象となります。各文字列の先頭にパッケージ パスが追加され、CROSSTOOL 機能の include_paths を介して C++ ツールチェーンに渡されて展開されます。一般的な機能定義を含む POSIX システムで実行されるツールチェーンは、-isystem path_to_package/include_entry を生成します。これは、Google の #include ステートメントの記述スタイルに準拠していないサードパーティ ライブラリでのみ使用してください。COPTS とは異なり、これらのフラグはこのルールと、このルールに依存するすべてのルールに追加されます。（注: 依存するルールではありません）。この操作は広範囲に影響する可能性があるため、慎重に行ってください。不明な場合は、代わりに COPTS に「-I」フラグを追加します。 デフォルトの include パスには、生成されたファイルは含まれません。生成されたヘッダー ファイルを #include する必要がある場合は、srcs にリストします。
interface_library	ラベル。デフォルトは None 共有ライブラリをリンクするための単一のインターフェース ライブラリ。 許可されるファイル形式: .ifso、.tbd、.lib、.so、.dylib
linkopts	文字列のリスト。デフォルトは [] これらのフラグを C++ リンカー コマンドに追加します。「Make」変数の置換、 Bourne シェルのトークン化、ラベルの展開の対象となります。この属性の各文字列は、バイナリ ターゲットをリンクする前に LINKOPTS に追加されます。 $ または - で始まらないこのリストの各要素は、deps のターゲットのラベルと見なされます。そのターゲットによって生成されたファイルのリストが、リンカー オプションに追加されます。ラベルが無効であるか、deps で宣言されていない場合は、エラーが報告されます。
objects	ラベルのリスト。デフォルトは []
pic_objects	ラベルのリスト。デフォルトは []
pic_static_library	ラベル。デフォルトは None
shared_library	ラベル。デフォルトは None 単一の事前コンパイル済み共有ライブラリ。Bazel は、実行時に依存するバイナリで使用できるようにします。 使用可能なファイル形式: .so、 .dll、 .dylib
static_library	ラベル。デフォルトは None 単一のプリコンパイル済み静的ライブラリ。 使用可能なファイル形式: .a、 .pic.a、 .lib
strip_include_prefix	文字列。デフォルトは "" です。 このルールのヘッダーのパスから削除する接頭辞。 設定すると、このルールの hdrs 属性のヘッダーは、この接頭辞が切り捨てられたパスでアクセス可能になります。 相対パスの場合、パッケージ相対パスとして扱われます。絶対パスの場合は、リポジトリ相対パスとして解釈されます。 include_prefix 属性の接頭辞は、この接頭辞が削除された後に追加されます。 この属性は third_party の下でのみ有効です。
system_provided	ブール値。デフォルトは False です。 有効になっている場合、ランタイムに必要な共有ライブラリがシステムによって提供されることを示します。この場合、interface_library を指定し、shared_library を空にする必要があります。

cc_library

ルールソースを表示

cc_library(name, deps, srcs, data, hdrs, additional_compiler_inputs, additional_linker_inputs, alwayslink, aspect_hints, compatible_with, conlyopts, copts, cxxopts, defines, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, hdrs_check, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, module_interfaces, package_metadata, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)

C++ コンパイル ライブラリには cc_library() を使用します。結果は、必要に応じて .so、.lo、.a のいずれかになります。

cc_library に依存する静的リンクで何かをビルドする場合、依存するライブラリ ルールの出力は .a ファイルです。alwayslink=True を指定すると、.lo ファイルが返されます。

共有ライブラリの実際の出力ファイル名は libfoo.so です。ここで、foo はルールの名前です。他の種類のライブラリは、それぞれ .lo と .a で終わります。たとえば、Python モジュールを定義するために特定の共有ライブラリ名が必要な場合は、genrule を使用してライブラリを目的の名前にコピーします。

ヘッダーの包含チェック

ビルドで使用されるすべてのヘッダー ファイルは、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 を含めることができ、bar.h は baz.h を含めることができ、baz.h は baz-impl.h を含めることができます。技術的には、.cc ファイルのコンパイルでは、推移的な deps クロージャ内の任意の cc_library の hdrs または srcs の任意のヘッダー ファイルを推移的に含めることができます。この場合、コンパイラは foo.cc のコンパイル時に baz.h と baz-impl.h を読み取る可能性がありますが、foo.cc に #include "baz.h" を含めることはできません。これを許可するには、baz を foo の deps に追加する必要があります。

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

例

alwayslink フラグを使用して、メインのバイナリコードが参照していない場合でも、リンカーにこのコードをリンクさせます。

cc_library(
    name = "ast_inspector_lib",
    srcs = ["ast_inspector_lib.cc"],
    hdrs = ["ast_inspector_lib.h"],
    visibility = ["//visibility:public"],
    deps = ["//third_party/llvm/llvm/tools/clang:frontend"],
    # alwayslink as we want to be able to call things in this library at
    # debug time, even if they aren't used anywhere in the code.
    alwayslink = True,
)

次の例は third_party/python2_4_3/BUILD からのものです。コードの一部で dl ライブラリ（別の動的ライブラリを読み込むため）を使用しているため、このルールでは dl ライブラリをリンクする -ldl リンク オプションを指定しています。

cc_library(
    name = "python2_4_3",
    linkopts = [
        "-ldl",
        "-lutil",
    ],
    deps = ["//third_party/expat"],
)

次の例は third_party/kde/BUILD からのものです。事前にビルドされた .so ファイルはデポに保存されます。ヘッダー ファイルは include という名前のサブディレクトリにあります。

cc_library(
    name = "kde",
    srcs = [
        "lib/libDCOP.so",
        "lib/libkdesu.so",
        "lib/libkhtml.so",
        "lib/libkparts.so",
        ...more .so files...,
    ],
    includes = ["include"],
    deps = ["//third_party/X11"],
)

次の例は third_party/gles/BUILD からのものです。サードパーティ コードでは、defines と linkopts が必要になることがよくあります。

cc_library(
    name = "gles",
    srcs = [
        "GLES/egl.h",
        "GLES/gl.h",
        "ddx.c",
        "egl.c",
    ],
    defines = [
        "USE_FLOAT",
        "__GL_FLOAT",
        "__GL_COMMON",
    ],
    linkopts = ["-ldl"],  # uses dlopen(), dl library
    deps = [
        "es",
        "//third_party/X11",
    ],
)

引数

属性
name	名前（必須） このターゲットの一意の名前。
deps	ラベルのリスト。デフォルトは [] ライブラリ ターゲットが依存する他のライブラリのリスト。 cc_library ターゲットまたは objc_library ターゲットを指定できます。 deps に関する一般的なコメントについては、ほとんどのビルドルールで定義される一般的な属性をご覧ください。 これらは C++ ライブラリ ルールの名前である必要があります。このルールのライブラリをリンクするバイナリをビルドすると、deps のライブラリもリンクされます。 「deps」という名前ですが、このライブラリのすべてのクライアントがここに属するわけではありません。実行時のデータ依存関係は data に属します。他のルールによって生成されたソースファイルは srcs に属します。 プリコンパイル済みのサードパーティ ライブラリをリンクするには、代わりに srcs に名前を追加します。 このライブラリにリンクせずに何かに依存するには、代わりにその名前を data に追加します。
srcs	ラベルのリスト。デフォルトは [] ライブラリ ターゲットを作成するために処理される C ファイルと C++ ファイルのリスト。これらは、生成されていない（通常のソースコード）または生成された C/C++ ソースファイルとヘッダー ファイルです。 .cc、.c、.cpp の各ファイルがすべてコンパイルされます。生成されたファイルの場合、名前付きファイルが他のルールの outs にあると、この cc_library は自動的にそのルールに依存します。 純粋なアセンブラ ファイル（.s、.asm）はプリプロセスされず、通常はアセンブラを使用してビルドされます。プリプロセスされたアセンブリ ファイル（.S）はプリプロセスされ、通常は C/C++ コンパイラを使用してビルドされます。 .h ファイルはコンパイルされませんが、このルールのソースでインクルードできます。.cc ファイルと .h ファイルの両方で、これらの srcs にリストされているヘッダー、このルールの hdrs、または deps 引数にリストされている任意のルールを直接含めることができます。 すべての #included ファイルは、このルールまたは参照される cc_library ルールの hdrs 属性で言及されるか、このライブラリにプライベートな場合は srcs にリストされる必要があります。詳しくは、「ヘッダーのインクルード チェック」をご覧ください。 .so、.lo、.a ファイルは、事前コンパイルされたファイルです。ソースコードのないサードパーティ コードを使用している場合、ライブラリに srcs が含まれている可能性があります。 srcs 属性に別のルールのラベルが含まれている場合、cc_library はそのルールの出力ファイルをコンパイルするソースファイルとして使用します。これは、ソースコードの 1 回限りの生成に役立ちます（頻繁に使用する場合は、Starlark ルールクラスを実装して cc_common API を使用することをおすすめします）。 許可されている 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 ... およびそれらのファイルを生成するルール（cc_embed_data など）。 異なる拡張子は、gcc の慣例に従って異なるプログラミング言語を示します。
data	ラベルのリスト。デフォルトは [] このライブラリが実行時に必要とするファイルのリスト。data に関する一般的なコメントについては、ほとんどのビルドルールで定義される一般的な属性をご覧ください。 data が生成されたファイルの名前である場合、この cc_library ルールは生成ルールに自動的に依存します。 data がルール名の場合、この cc_library ルールはそのルールに自動的に依存し、そのルールの outs はこの cc_library のデータファイルに自動的に追加されます。 C++ コードでこれらのデータファイルにアクセスするには、次のようにします。 const std::string path = devtools_build::GetDataDependencyFilepath( "my/test/data/file");
hdrs	ラベルのリスト。デフォルトは [] このライブラリによって公開され、依存ルールのソースによって直接インクルードされるヘッダー ファイルのリスト。 ライブラリのインターフェースを記述するヘッダー ファイルを宣言する場所として、この場所が強く推奨されます。これらのヘッダーは、このルールまたは依存ルールのソースで含めることができます。このライブラリのクライアントが含めることを意図していないヘッダーは、公開されたヘッダーに含まれている場合でも、代わりに srcs 属性にリストする必要があります。詳しくは、「ヘッダーの包含チェック」をご覧ください。 許可されている headers ファイル形式: .h、 .hh、 .hpp、 .hxx。
additional_compiler_inputs	ラベルのリスト。デフォルトは [] サニタイザーの無視リストなど、コンパイラのコマンドラインに渡す追加のファイル。ここで指定されたファイルは、$(location) 関数を使用して copts で使用できます。
additional_linker_inputs	ラベルのリスト。デフォルトは [] C++ リンカー コマンドでのみ使用できる依存関係。 コンパイルとリンクの両方の依存関係を概念的に対象とする deps とは異なり、additional_linker_inputs は後者のみを対象としており、リンクにのみ必要な依存関係（linkopts で参照されるファイルなど）を示します。 たとえば、コンパイル済みの Windows .res ファイルをここに指定して、バイナリ ターゲットに埋め込むことができます。
alwayslink	ブール値。デフォルトは False です。 1 の場合、この C++ ライブラリに（直接的または間接的に）依存するバイナリは、srcs にリストされているファイルのすべてのオブジェクト ファイルをリンクします。バイナリで参照されるシンボルが含まれていないファイルもリンクされます。これは、コードがバイナリ内のコードによって明示的に呼び出されない場合に便利です。たとえば、コードが登録されて、サービスから提供されたコールバックを受け取る場合などです。 Windows で VS 2017 で alwayslink が動作しない場合は、既知の問題が原因です。VS 2017 を最新バージョンにアップグレードしてください。
conlyopts	文字列のリスト。デフォルトは [] これらのオプションを C コンパイル コマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化の対象となります。
copts	文字列のリスト。デフォルトは [] これらのオプションを C/C++ コンパイル コマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化の対象となります。 この属性の各文字列は、バイナリ ターゲットをコンパイルする前に、指定された順序で COPTS に追加されます。フラグは、このターゲットのコンパイルにのみ有効で、依存関係には有効ではありません。そのため、他の場所でインクルードされているヘッダー ファイルには注意してください。すべてのパスは、現在のパッケージではなく、ワークスペースを基準とした相対パスにする必要があります。この属性は third_party の外部では必要ありません。 パッケージが機能 no_copts_tokenization を宣言している場合、Bourne シェルのトークン化は、単一の「Make」変数で構成される文字列にのみ適用されます。
cxxopts	文字列のリスト。デフォルトは [] これらのオプションを C++ コンパイル コマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化の対象となります。
defines	文字列のリスト。デフォルトは [] このターゲットとすべての依存ターゲットのコンパイル行に追加する定義のリスト。「Make」変数の置換と Bourne シェルのトークン化の対象となります。各文字列（単一の Bourne シェル トークンで構成されている必要があります）の先頭に -D が付加され、このターゲットのコンパイル コマンドラインと、このターゲットに依存するすべてのルールに追加されます。このターゲットに依存するすべてのターゲットに定義が追加されるため、広範囲に影響する可能性があります。十分注意してください。不明な場合は、代わりに local_defines に定義値を追加します。
hdrs_check	文字列。デフォルトは "" です。 非推奨、無演算。
implementation_deps	ラベルのリスト。デフォルトは [] ライブラリ ターゲットが依存する他のライブラリのリスト。deps とは異なり、これらのライブラリのヘッダーとインクルード パス（およびすべての推移的依存関係）は、このライブラリのコンパイルにのみ使用され、それに依存するライブラリには使用されません。implementation_deps で指定されたライブラリは、このライブラリに依存するバイナリ ターゲットに引き続きリンクされます。
include_prefix	文字列。デフォルトは "" です。 このルールのヘッダーのパスに追加する接頭辞。 設定すると、このルールの hdrs 属性のヘッダーは、この属性の値がリポジトリ相対パスに付加された値でアクセスできます。 strip_include_prefix 属性の接頭辞は、この接頭辞が追加される前に削除されます。 この属性は third_party の下でのみ有効です。
includes	文字列のリスト。デフォルトは [] コンパイル行に追加するインクルード ディレクトリのリスト。「変数を作成」の置換の対象となります。各文字列の先頭にパッケージ パスが追加され、CROSSTOOL 機能の include_paths を介して C++ ツールチェーンに渡されて展開されます。一般的な機能定義を含む POSIX システムで実行されるツールチェーンは、-isystem path_to_package/include_entry を生成します。これは、Google の #include ステートメントの記述スタイルに準拠していないサードパーティ ライブラリでのみ使用してください。COPTS とは異なり、これらのフラグはこのルールと、このルールに依存するすべてのルールに追加されます。（注: 依存するルールではありません）。この操作は広範囲に影響する可能性があるため、慎重に行ってください。不明な場合は、代わりに COPTS に「-I」フラグを追加します。 追加された include パスには、生成されたファイルとソースツリー内のファイルが含まれます。
linkopts	文字列のリスト。デフォルトは [] 詳細については、cc_binary.linkopts をご覧ください。 linkopts 属性は、deps 属性（または同様に扱われる他の属性: cc_binary の malloc 属性）を介してこのライブラリに直接的または間接的に依存するすべてのターゲットにも適用されます。依存関係の linkopts は、依存先の linkopts よりも優先されます（つまり、依存関係の linkopts はコマンドラインで後に出現します）。--linkopt で指定された Linkopts は、ルール Linkopts よりも優先されます。 linkopts 属性は、.a ファイルや .lo ファイルの作成時ではなく、.so ファイルや実行可能ファイルの作成時にのみ適用されます。したがって、linkstatic=True 属性が設定されている場合、linkopts 属性はこのライブラリの作成には影響せず、このライブラリに依存する他のターゲットにのみ影響します。 また、「-Wl,-soname」または「-Xlinker -soname」オプションはサポートされておらず、この属性で指定することはできません。 cc_library ルールで生成された .so ファイルは、依存するライブラリに対してリンクされません。メイン リポジトリの外部で使用する共有ライブラリ（dlopen() または LD_PRELOAD での手動使用など）を作成する場合は、linkshared=True 属性を持つ cc_binary ルールを使用する方がよい場合があります。cc_binary.linkshared をご覧ください。
linkstamp	ラベル。デフォルトは None 指定された C++ ソースファイルを同時にコンパイルして、最終的なバイナリにリンクします。このトリックは、バイナリにタイムスタンプ情報を導入するために必要です。通常の方法でソースファイルをオブジェクト ファイルにコンパイルすると、タイムスタンプが正しくなくなります。リンクスタンプ コンパイルには特定のコンパイラ フラグのセットが含まれない場合があるため、特定のヘッダー、コンパイラ オプション、その他のビルド変数に依存しないようにする必要があります。このオプションは base パッケージでのみ必要です。
linkstatic	ブール値。デフォルトは False です。 cc_binary と cc_test の場合: バイナリを静的モードでリンクします。cc_library.link_static: 以下をご覧ください。 デフォルトでは、このオプションは cc_binary ではオン、それ以外ではオフになっています。 有効で、これがバイナリまたはテストの場合、このオプションは、可能な限りユーザー ライブラリの .so ではなく .a をリンクするようにビルドツールに指示します。libc などのシステム ライブラリ（ただし、C/C++ ランタイム ライブラリは除く。下記を参照）は、静的ライブラリがないライブラリと同様に、動的にリンクされます。したがって、結果の実行可能ファイルは引き続き動的にリンクされるため、静的であるのはほとんどの場合のみです。 実行可能ファイルをリンクする方法は、実際には 3 つあります。 すべてが静的にリンクされる fully_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 を指定することで有効になります。 features の linkstatic 属性または fully_static_link が //third_party の外部で使用されている場合は、その理由を説明するコメントをルールの近くに含めてください。 linkstatic 属性は、cc_library() ルールで使用される場合、意味が異なります。C++ ライブラリの場合、linkstatic=True は静的リンクのみが許可されていることを示します。そのため、.so は生成されません。linkstatic=False は、静的ライブラリの作成を妨げません。この属性は、動的ライブラリの作成を制御するためのものです。 本番環境で linkstatic=False を使用してビルドされたコードはほとんどありません。linkstatic=False の場合、ビルドツールは *.runfiles 領域に依存する共有ライブラリへのシンボリック リンクを作成します。
local_defines	文字列のリスト。デフォルトは [] コンパイル行に追加する定義のリスト。「Make」変数の置換と Bourne シェルのトークン化の対象となります。各文字列は単一の Bourne シェル トークンで構成されている必要があり、-D が先頭に付加され、このターゲットのコンパイル コマンドラインに追加されますが、依存関係には追加されません。defines とは異なり、このターゲットのコンパイル コマンドラインにのみ定義が追加されます。
module_interfaces	ラベルのリスト。デフォルトは [] ファイルのリストは C++20 モジュール インターフェースとみなされます。 C++ 標準にはモジュール インターフェース ファイル拡張子に関する制限はありません Clang で cppm を使用する GCC は任意のソースファイル拡張子を使用できます MSVC で ixx を使用する この使用は --experimental_cpp_modules フラグによって保護されています。
strip_include_prefix	文字列。デフォルトは "" です。 このルールのヘッダーのパスから削除する接頭辞。 設定すると、このルールの hdrs 属性のヘッダーは、この接頭辞が切り捨てられたパスでアクセス可能になります。 相対パスの場合、パッケージ相対パスとして扱われます。絶対パスの場合は、リポジトリ相対パスとして解釈されます。 include_prefix 属性の接頭辞は、この接頭辞が削除された後に追加されます。 この属性は third_party の下でのみ有効です。
textual_hdrs	ラベルのリスト。デフォルトは [] このライブラリによって公開され、依存ルールのソースによってテキストでインクルードされるヘッダー ファイルのリスト。 これは、単独でコンパイルできないヘッダー ファイルを宣言する場所です。つまり、有効なコードをビルドするには、常に他のソースファイルによってテキストでインクルードされる必要があります。
win_def_file	ラベル。デフォルトは None リンカーに渡される Windows DEF ファイル。 この属性は、Windows がターゲット プラットフォームの場合にのみ使用してください。共有ライブラリのリンク時に シンボルをエクスポートするために使用できます。

cc_shared_library

ルールソースを表示

cc_shared_library(name, deps, additional_linker_inputs, aspect_hints, compatible_with, deprecation, dynamic_deps, exec_compatible_with, exec_group_compatible_with, exec_properties, exports_filter, features, package_metadata, restricted_to, roots, shared_lib_name, static_deps, tags, target_compatible_with, testonly, toolchains, user_link_flags, visibility, 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 にもリンクする場合は、baz に tags = ["LINKABLE_MORE_THAN_ONCE"] を追加する必要があります。

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

cc_static_library

ルールソースを表示

cc_static_library(name, deps, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

ターゲットとその推移的依存関係のリストから静的ライブラリを生成します。

結果の静的ライブラリには、deps にリストされているターゲットのオブジェクト ファイルと、それらの推移的依存関係が含まれます。PIC オブジェクトが優先されます。

出力グループ

linkdeps

deps にリストされているターゲットの推移的依存関係のうち、静的ライブラリにオブジェクト ファイルを提供していないが、少なくとも 1 つの静的ライブラリ、動的ライブラリ、インターフェース ライブラリを提供しているもののラベルを含むテキスト ファイル。生成された静的ライブラリでは、リンク時にこれらのライブラリが利用可能であることが必要になる場合があります。

linkopts

deps にリストされているターゲットのすべての推移的依存関係のユーザー指定の linkopts を含むテキスト ファイル。

記号が重複している

デフォルトでは、cc_static_library ルールは、結果の静的ライブラリに重複するシンボルが含まれていないことを確認します。重複している場合、ビルドは失敗し、重複しているシンボルとそれらを含むオブジェクト ファイルを一覧表示するエラー メッセージが表示されます。

このチェックは、features = ["-symbol_check"] を設定してターゲットごとまたはパッケージごとに無効にするか、--features=-symbol_check を使用してグローバルに無効にできます。

symbol_check のツールチェーンのサポート

Bazel に付属する自動構成された C++ ツールチェーンは、すべてのプラットフォームで symbol_check 機能をサポートしています。カスタム ツールチェーンは、次の 2 つの方法のいずれかでサポートを追加できます。

• ACTION_NAMES.validate_static_library アクションを実装し、symbol_check 機能で有効にします。アクションで設定されたツールは、重複するシンボルをチェックする静的ライブラリと、チェックに合格した場合に作成する必要があるファイルのパスの 2 つの引数で呼び出されます。
• symbol_check 機能により、静的ライブラリを作成するアクションが重複するシンボルで失敗するアーカイバ フラグが追加されます。

引数

属性
name	名前（必須） このターゲットの一意の名前。
deps	ラベルのリスト。デフォルトは [] 静的ライブラリに結合するターゲットのリスト。すべての推移的依存関係を含む。 オブジェクト ファイルを提供しない依存関係は静的ライブラリには含まれませんが、そのラベルは linkdeps 出力グループによって提供されるファイルに収集されます。

cc_test

ルールソースを表示

cc_test(name, deps, srcs, data, additional_linker_inputs, args, aspect_hints, compatible_with, conlyopts, copts, cxxopts, defines, deprecation, dynamic_deps, env, env_inherit, exec_compatible_with, exec_group_compatible_with, exec_properties, features, flaky, hdrs_check, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local, local_defines, malloc, module_interfaces, nocopts, package_metadata, reexport_deps, restricted_to, shard_count, size, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility, win_def_file)

cc_test() ルールはテストをコンパイルします。ここで、テストはテストコードのバイナリ ラッパーです。

デフォルトでは、C++ テストは動的にリンクされます。
単体テストを静的にリンクするには、linkstatic=True を指定します。テストで linkstatic が必要な理由をコメントしておくとよいでしょう。おそらく、その理由は明らかではないでしょう。

暗黙的な出力ターゲット

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

cc_binary() の引数をご覧ください。ただし、テストでは stamp 引数はデフォルトで 0 に設定され、cc_test にはすべてのテストルール（*_test）に共通の追加の 属性があります。

引数

属性
name	名前（必須） このターゲットの一意の名前。
deps	ラベルのリスト。デフォルトは [] バイナリ ターゲットにリンクされる他のライブラリのリスト。 これらは cc_library ターゲットまたは objc_library ターゲットにできます。 リンカ スクリプト（.lds）を deps に配置し、linkopts で参照することもできますが、そのユースケースでは additional_linker_inputs を検討してください。
srcs	ラベルのリスト。デフォルトは [] ライブラリ ターゲットを作成するために処理される C ファイルと C++ ファイルのリスト。これらは、生成されていない（通常のソースコード）または生成された C/C++ ソースファイルとヘッダー ファイルです。 .cc、.c、.cpp の各ファイルがすべてコンパイルされます。生成されたファイルの場合、名前付きファイルが他のルールの outs にあると、この cc_library は自動的にそのルールに依存します。 純粋なアセンブラ ファイル（.s、.asm）はプリプロセスされず、通常はアセンブラを使用してビルドされます。プリプロセスされたアセンブリ ファイル（.S）はプリプロセスされ、通常は C/C++ コンパイラを使用してビルドされます。 .h ファイルはコンパイルされませんが、このルールのソースでインクルードできます。.cc ファイルと .h ファイルの両方で、これらの srcs にリストされているヘッダー、このルールの hdrs、または deps 引数にリストされている任意のルールを直接含めることができます。 すべての #included ファイルは、このルールまたは参照される cc_library ルールの hdrs 属性で言及されるか、このライブラリにプライベートな場合は srcs にリストされる必要があります。詳しくは、「ヘッダーのインクルード チェック」をご覧ください。 .so、.lo、.a ファイルは、事前コンパイルされたファイルです。ソースコードのないサードパーティ コードを使用している場合、ライブラリに srcs が含まれている可能性があります。 srcs 属性に別のルールのラベルが含まれている場合、cc_library はそのルールの出力ファイルをコンパイルするソースファイルとして使用します。これは、ソースコードの 1 回限りの生成に役立ちます（頻繁に使用する場合は、Starlark ルールクラスを実装して cc_common API を使用することをおすすめします）。 許可されている 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 ... およびそれらのファイルを生成するルール（cc_embed_data など）。 異なる拡張子は、gcc の慣例に従って異なるプログラミング言語を示します。
data	ラベルのリスト。デフォルトは [] このライブラリが実行時に必要とするファイルのリスト。data に関する一般的なコメントについては、ほとんどのビルドルールで定義される一般的な属性をご覧ください。 data が生成されたファイルの名前である場合、この cc_library ルールは生成ルールに自動的に依存します。 data がルール名の場合、この cc_library ルールはそのルールに自動的に依存し、そのルールの outs はこの cc_library のデータファイルに自動的に追加されます。 C++ コードでこれらのデータファイルにアクセスするには、次のようにします。 const std::string path = devtools_build::GetDataDependencyFilepath( "my/test/data/file");
additional_linker_inputs	ラベルのリスト。デフォルトは [] C++ リンカー コマンドでのみ使用できる依存関係。 コンパイルとリンクの両方の依存関係を概念的に対象とする deps とは異なり、additional_linker_inputs は後者のみを対象としており、リンクにのみ必要な依存関係（linkopts で参照されるファイルなど）を示します。 たとえば、コンパイル済みの Windows .res ファイルをここに指定して、バイナリ ターゲットに埋め込むことができます。
conlyopts	文字列のリスト。デフォルトは [] これらのオプションを C コンパイル コマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化の対象となります。
copts	文字列のリスト。デフォルトは [] これらのオプションを C/C++ コンパイル コマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化の対象となります。 この属性の各文字列は、バイナリ ターゲットをコンパイルする前に、指定された順序で COPTS に追加されます。フラグは、このターゲットのコンパイルにのみ有効で、依存関係には有効ではありません。そのため、他の場所でインクルードされているヘッダー ファイルには注意してください。すべてのパスは、現在のパッケージではなく、ワークスペースを基準とした相対パスにする必要があります。この属性は third_party の外部では必要ありません。 パッケージが機能 no_copts_tokenization を宣言している場合、Bourne シェルのトークン化は、単一の「Make」変数で構成される文字列にのみ適用されます。
cxxopts	文字列のリスト。デフォルトは [] これらのオプションを C++ コンパイル コマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化の対象となります。
defines	文字列のリスト。デフォルトは [] このターゲットとすべての依存ターゲットのコンパイル行に追加する定義のリスト。「Make」変数の置換と Bourne シェルのトークン化の対象となります。各文字列（単一の Bourne シェル トークンで構成されている必要があります）の先頭に -D が付加され、このターゲットのコンパイル コマンドラインと、このターゲットに依存するすべてのルールに追加されます。このターゲットに依存するすべてのターゲットに定義が追加されるため、広範囲に影響する可能性があります。十分注意してください。不明な場合は、代わりに local_defines に定義値を追加します。
dynamic_deps	ラベルのリスト。デフォルトは [] これらは、現在のターゲットが依存する他の cc_shared_library 依存関係です。 cc_shared_library の実装では、dynamic_deps のリスト（推移的、つまり現在のターゲットの dynamic_deps の dynamic_deps も含む）を使用して、推移的な deps のどの cc_libraries をリンクしないかを決定します。これは、別の cc_shared_library によってすでに提供されているためです。
hdrs_check	文字列。デフォルトは "" です。 非推奨、無演算。
includes	文字列のリスト。デフォルトは [] コンパイル行に追加するインクルード ディレクトリのリスト。「変数を作成」の置換の対象となります。各文字列の先頭にパッケージ パスが追加され、CROSSTOOL 機能の include_paths を介して C++ ツールチェーンに渡されて展開されます。一般的な機能定義を含む POSIX システムで実行されるツールチェーンは、-isystem path_to_package/include_entry を生成します。これは、Google の #include ステートメントの記述スタイルに準拠していないサードパーティ ライブラリでのみ使用してください。COPTS とは異なり、これらのフラグはこのルールと、このルールに依存するすべてのルールに追加されます。（注: 依存するルールではありません）。この操作は広範囲に影響する可能性があるため、慎重に行ってください。不明な場合は、代わりに COPTS に「-I」フラグを追加します。 追加された include パスには、生成されたファイルとソースツリー内のファイルが含まれます。
link_extra_lib	ラベル。デフォルトは "@bazel_tools//tools/cpp:link_extra_lib" 追加ライブラリのリンクを制御します。 デフォルトでは、C++ バイナリは @bazel_tools//tools/cpp:link_extra_lib に対してリンクされます。これはデフォルトでラベルフラグ @bazel_tools//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 の両方を指定すると、ほぼ自己完結型の単一ユニットが取得されます。
linkstatic	ブール値。デフォルトは False です。 cc_binary と cc_test の場合: バイナリを静的モードでリンクします。cc_library.link_static: 以下をご覧ください。 デフォルトでは、このオプションは cc_binary ではオン、それ以外ではオフになっています。 有効で、これがバイナリまたはテストの場合、このオプションは、可能な限りユーザー ライブラリの .so ではなく .a をリンクするようにビルドツールに指示します。libc などのシステム ライブラリ（ただし、C/C++ ランタイム ライブラリは除く。下記を参照）は、静的ライブラリがないライブラリと同様に、動的にリンクされます。したがって、結果の実行可能ファイルは引き続き動的にリンクされるため、静的であるのはほとんどの場合のみです。 実行可能ファイルをリンクする方法は、実際には 3 つあります。 すべてが静的にリンクされる fully_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 を指定することで有効になります。 features の linkstatic 属性または fully_static_link が //third_party の外部で使用されている場合は、その理由を説明するコメントをルールの近くに含めてください。 linkstatic 属性は、cc_library() ルールで使用される場合、意味が異なります。C++ ライブラリの場合、linkstatic=True は静的リンクのみが許可されていることを示します。そのため、.so は生成されません。linkstatic=False は、静的ライブラリの作成を妨げません。この属性は、動的ライブラリの作成を制御するためのものです。 本番環境で linkstatic=False を使用してビルドされたコードはほとんどありません。linkstatic=False の場合、ビルドツールは *.runfiles 領域に依存する共有ライブラリへのシンボリック リンクを作成します。
local_defines	文字列のリスト。デフォルトは [] コンパイル行に追加する定義のリスト。「Make」変数の置換と Bourne シェルのトークン化の対象となります。各文字列は単一の Bourne シェル トークンで構成されている必要があり、-D が先頭に付加され、このターゲットのコンパイル コマンドラインに追加されますが、依存関係には追加されません。defines とは異なり、このターゲットのコンパイル コマンドラインにのみ定義が追加されます。
malloc	ラベル。デフォルトは "@bazel_tools//tools/cpp:malloc" malloc のデフォルトの依存関係をオーバーライドします。 デフォルトでは、C++ バイナリは //tools/cpp:malloc に対してリンクされます。これは空のライブラリであるため、バイナリは libc malloc を使用することになります。このラベルは cc_library を参照する必要があります。コンパイルが C++ 以外のルールの場合、このオプションは効果がありません。linkshared=True が指定されている場合、この属性の値は無視されます。
module_interfaces	ラベルのリスト。デフォルトは [] ファイルのリストは C++20 モジュール インターフェースとみなされます。 C++ 標準にはモジュール インターフェース ファイル拡張子に関する制限はありません Clang で cppm を使用する GCC は任意のソースファイル拡張子を使用できます MSVC で ixx を使用する この使用は --experimental_cpp_modules フラグによって保護されています。
nocopts	文字列。デフォルトは "" です。 C++ コンパイル コマンドから一致するオプションを削除します。「Make」変数の置換の対象となります。この属性の値は正規表現として解釈されます。この正規表現に一致する既存の COPTS（ルールの copts 属性で明示的に指定された値を含む）は、このルールをコンパイルする目的で COPTS から削除されます。この属性は third_party の外部では必要とされず、使用もされません。値は、「Make」変数の置換以外の方法で前処理されません。
reexport_deps	ラベルのリスト。デフォルトは []
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, aspect_hints, compatible_with, compiler_files, compiler_files_without_includes, coverage_files, deprecation, dwp_files, dynamic_runtime_lib, exec_compatible_with, exec_group_compatible_with, exec_properties, exec_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, output_licenses, package_metadata, restricted_to, static_runtime_lib, strip_files, supports_header_parsing, supports_param_files, tags, target_compatible_with, testonly, toolchain_config, toolchain_identifier, toolchains, visibility)

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

このルールは次の処理を行います。

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

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

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

引数

属性
name	名前（必須） このターゲットの一意の名前。
all_files	ラベル（必須） すべての cc_toolchain アーティファクトのコレクション。これらのアーティファクトは、すべての 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 入力検出がサポートされている場合（現在は Google のみ）、コンパイル アクションに必要なすべての cc_toolchain アーティファクトのコレクション。
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	ブール値。デフォルトは False です。 非推奨です。No-op。
libc_top	ラベル。デフォルトは None コンパイル/リンク アクションへの入力として渡される libc のアーティファクトのコレクション。
linker_files	ラベル（必須） リンク アクションに必要なすべての cc_toolchain アーティファクトのコレクション。
module_map	ラベル。デフォルトは None モジュール ビルドに使用されるモジュール マップ アーティファクト。
objcopy_files	ラベル（必須） objcopy アクションに必要なすべての cc_toolchain アーティファクトのコレクション。
output_licenses	文字列のリスト。デフォルトは []
static_runtime_lib	ラベル。デフォルトは None C++ ランタイム ライブラリの静的ライブラリ アーティファクト（libstdc++.a など）。 これは、'static_link_cpp_runtimes' 機能が有効で、依存関係を静的にリンクしている場合に使用されます。
strip_files	ラベル（必須） ストリップ アクションに必要なすべての cc_toolchain アーティファクトのコレクション。
supports_header_parsing	ブール値。デフォルトは False です。 cc_toolchain がヘッダー解析アクションをサポートしている場合は True に設定します。
supports_param_files	ブール値。デフォルトは True です。 cc_toolchain がリンク アクションにパラメータ ファイルを使用することをサポートしている場合は True に設定します。
toolchain_config	ラベル（必須） cc_toolchain_config_info を提供するルールのラベル。
toolchain_identifier	文字列。デフォルトは "" です。 この cc_toolchain を対応する crosstool_config.toolchain と照合するために使用される識別子。 問題 #5380 が修正されるまでは、cc_toolchain を CROSSTOOL.toolchain に関連付けるには、この方法をおすすめします。toolchain_config 属性（#5380）に置き換えられます。

fdo_prefetch_hints

ルールソースを表示

fdo_prefetch_hints(name, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, package_metadata, profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

ワークスペースにある FDO プリフェッチ ヒント プロファイルを表します。例:

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

引数

属性
name	名前（必須） このターゲットの一意の名前。
profile	ラベル（必須） ヒント プロファイルのラベル。ヒント ファイルの拡張子は .afdo です。ラベルは fdo_absolute_path_profile ルールを指すこともできます。

fdo_profile

ルールソースを表示

fdo_profile(name, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, memprof_profile, package_metadata, profile, proto_profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

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

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

引数

属性
name	名前（必須） このターゲットの一意の名前。
memprof_profile	ラベル。デフォルトは None MemProf プロファイルのラベル。プロファイルには、.profdata 拡張子（インデックス付き/シンボル化された memprof プロファイルの場合）または memprof.profdata ファイルを含む zip ファイルの .zip 拡張子が必要です。
profile	ラベル（必須） FDO プロファイルのラベル、またはそれを生成するルールのラベル。FDO ファイルの拡張子は、インデックスなしの LLVM プロファイルの場合は .profraw、インデックス付きの LLVM プロファイルの場合は .profdata、LLVM profraw プロファイルを含む場合は .zip、AutoFDO プロファイルの場合は .afdo、XBinary プロファイルの場合は .xfdo のいずれかになります。ラベルは fdo_absolute_path_profile ルールを指すこともできます。
proto_profile	ラベル。デフォルトは None protobuf プロファイルのラベル。

memprof_profile

ルールソースを表示

memprof_profile(name, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, package_metadata, profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

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

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

引数

属性
name	名前（必須） このターゲットの一意の名前。
profile	ラベル（必須） MEMPROF プロファイルのラベル。プロファイルには、.profdata 拡張子（インデックス付き/シンボル化された memprof プロファイルの場合）または memprof.profdata ファイルを含む zip ファイルの .zip 拡張子が必要です。ラベルは fdo_absolute_path_profile ルールを指すこともできます。

propeller_optimize

ルールソースを表示

propeller_optimize(name, aspect_hints, cc_profile, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, ld_profile, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

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

propeller_optimize(
    name = "layout",
    cc_profile = "//path:cc_profile.txt",
    ld_profile = "//path:ld_profile.txt"
)

引数

属性
name	名前（必須） このターゲットの一意の名前。
cc_profile	ラベル（必須） さまざまなコンパイル アクションに渡されるプロファイルのラベル。このファイルの拡張子は .txt です。
ld_profile	ラベル（必須） リンク アクションに渡されるプロファイルのラベル。このファイルの拡張子は .txt です。